docs(compliance): update operational procedures for encryption disclosure

Update incident response, data subject request, and DPIA procedures to
accurately reflect that database encryption at rest is NOT implemented
for non-E2EE users.

Changes:
- INCIDENT-RESPONSE-PLAYBOOK.md: Clarify E2EE is optional throughout,
  add physical server compromise scenarios, update risk assessments to
  differentiate E2EE vs non-E2EE users, document encryption gap in
  prevention measures
- DATA-SUBJECT-REQUEST-PROCEDURES.md: Add encryption status disclosure
  to access responses, clarify data export formats, add security notice
  about unencrypted storage for non-E2EE users
- DPIA-SCREENING-DECISION.md: Document encryption gap as additional
  consideration, update risk level to LOW-MEDIUM, add encryption gap
  to conclusion and re-assessment triggers

All procedures now consistently acknowledge 85% compliance score and
risk variance based on E2EE usage, while maintaining that DPIA is not
required per Art. 35.

packages/super-sync-server/docs/compliance/DATA-SUBJECT-REQUEST-PROCEDURES.md

@@ -229,6 +229,12 @@ Create document containing:
 - E2EE enabled: Yes/No
 - Storage used: [X MB]
 
+**Encryption Status:**
+
+- Your account uses E2EE: ✅ Yes / ❌ No
+- Data stored encrypted on server: [Yes if E2EE enabled, No otherwise]
+- Note: Without E2EE enabled, your data is stored unencrypted in our PostgreSQL database
+
 ### Sync Data
 
 - Number of operations: [count]
@@ -236,6 +242,12 @@ Create document containing:
 - Latest snapshot date: [date]
   [Attached: sync-data-export.json]
 
+**Note on Data Export:**
+
+- E2EE users: Data exported in encrypted form (you must decrypt with your key)
+- Non-E2EE users: Data exported in plaintext JSON format
+- Exported data includes all sync operations and snapshots
+
 ### Server Logs (if still retained)
 
 - Recent access times
@@ -277,6 +289,9 @@ Create document containing:
 - Object: Contact us to object to processing
 - Complain: Sächsischer Datenschutzbeauftragter (saechsdsb@slt.sachsen.de)
 
+**Security Disclosure:**
+Users should be informed that without E2EE enabled, their data is stored unencrypted in our PostgreSQL database. We recommend enabling E2EE for sensitive data.
+
 ## 3. Attachments
 
 - sync-data-export.json (your productivity data)

packages/super-sync-server/docs/compliance/DPIA-SCREENING-DECISION.md

@@ -124,6 +124,32 @@ Users _may_ choose to store sensitive information (e.g., "doctor appointment" no
 
 ---
 
+### Additional Consideration: Encryption at Rest
+
+**Current State:** ⚠️ Database encryption at rest NOT implemented
+
+**Analysis:**
+
+- PostgreSQL data files stored unencrypted on disk
+- Compensating control: Optional E2EE available (user choice)
+- Risk: Users who don't enable E2EE have unencrypted data at rest
+
+**Impact on DPIA Decision:**
+
+- Does NOT change DPIA requirement (still not required per Art. 35)
+- Encryption gap increases risk severity but doesn't trigger DPIA thresholds
+- Risk is addressed through:
+  - Optional E2EE offering
+  - Physical security at hosting provider (Alfahosting)
+  - Access controls (JWT authentication, rate limiting)
+  - Transparent disclosure in privacy policy
+
+**Conclusion:**
+The lack of database encryption at rest is documented as a compliance gap (85% vs 92%),
+but does not meet the "high risk" threshold requiring a full DPIA under Art. 35.
+
+---
+
 ## 3. WP248 Criteria Assessment
 
 Evaluating against all 9 criteria from WP248 Rev.01:
@@ -150,7 +176,13 @@ Evaluating against all 9 criteria from WP248 Rev.01:
 
 ## 4. Risk Assessment
 
-### Risk Level: LOW
+### Risk Level: LOW-MEDIUM
+
+**Overall Risk Assessment:**
+
+- E2EE users: LOW risk (zero-knowledge encryption)
+- Non-E2EE users: MEDIUM risk (unencrypted data at rest)
+- Mitigations: Physical security, access controls, optional E2EE
 
 | Risk Factor           | Assessment | Justification                                                       |
 | --------------------- | ---------- | ------------------------------------------------------------------- |
@@ -165,16 +197,16 @@ Evaluating against all 9 criteria from WP248 Rev.01:
 
 ### User Harm Scenarios (Hypothetical)
 
-| Scenario                     | Likelihood | Impact | Risk Level                     |
-| ---------------------------- | ---------- | ------ | ------------------------------ |
-| Data breach (unencrypted)    | Low        | Medium | Low-Medium                     |
-| Data breach (E2EE enabled)   | Low        | Low    | Very Low                       |
-| Unauthorized account access  | Low        | Medium | Low-Medium                     |
-| Service unavailability       | Medium     | Low    | Low                            |
-| Accidental data loss         | Low        | Medium | Low-Medium                     |
-| Privacy violation (tracking) | None       | N/A    | None (no tracking implemented) |
+| Scenario                     | Likelihood | Impact | Risk Level                             |
+| ---------------------------- | ---------- | ------ | -------------------------------------- |
+| Data breach (unencrypted)    | Low        | Medium | Low-Medium (MEDIUM for non-E2EE users) |
+| Data breach (E2EE enabled)   | Low        | Low    | Very Low                               |
+| Unauthorized account access  | Low        | Medium | Low-Medium                             |
+| Service unavailability       | Medium     | Low    | Low                                    |
+| Accidental data loss         | Low        | Medium | Low-Medium                             |
+| Privacy violation (tracking) | None       | N/A    | None (no tracking implemented)         |
 
-**Overall Risk to Rights and Freedoms:** LOW
+**Overall Risk to Rights and Freedoms:** LOW-MEDIUM (varies by E2EE usage)
 
 ---
 
@@ -245,10 +277,17 @@ Super Productivity Sync implements multiple safeguards that reduce risk:
 
 1. Does not meet GDPR Article 35(3) mandatory DPIA scenarios
 2. Meets fewer than 2 WP248 criteria (threshold for likely DPIA requirement)
-3. Processing poses low risk to data subjects' rights and freedoms
+3. Processing poses low-medium risk to data subjects' rights and freedoms
 4. Extensive mitigating factors in place (privacy by design, security, user control)
 5. Comparable to other productivity/sync services that do not require DPIA
 
+**Encryption Gap Consideration:**
+While database encryption at rest is not currently implemented, this does not elevate
+the processing to "high risk" requiring a DPIA. The service offers optional E2EE
+as a compensating control, maintains transparent disclosure, and processes data on
+a relatively small scale with strong access controls. Users requiring maximum security
+are advised to enable E2EE.
+
 **Documented Screening:** This document serves as evidence of DPIA screening for accountability purposes (Art. 5(2) GDPR).
 
 ---
@@ -283,6 +322,8 @@ A full DPIA **must** be conducted if processing changes significantly, such as:
 - [ ] Performance optimizations
 - [ ] Bug fixes
 - [ ] Additional sync providers (similar to existing)
+- [ ] Implementation of mandatory encryption (would reduce risk, strengthen compliance)
+- [ ] Removal of E2EE option (would increase risk, may trigger DPIA need)
 
 **Process:**
 

packages/super-sync-server/docs/compliance/INCIDENT-RESPONSE-PLAYBOOK.md

@@ -60,7 +60,8 @@ A personal data breach is:
 - ✅ Ransomware encrypting user data
 - ✅ Accidental deletion of user data
 - ✅ Data sent to wrong recipient
-- ✅ Lost/stolen device containing unencrypted user data
+- ✅ Lost/stolen device or server disk containing unencrypted user data
+- ✅ Physical server compromise or disk theft (data stored unencrypted for non-E2EE users)
 - ✅ Successful SQL injection or XSS attack exposing user data
 - ✅ Compromised credentials allowing unauthorized database access
 
@@ -143,7 +144,10 @@ Anyone who suspects a breach should immediately:
 - [ ] Is this a confirmed breach or suspected breach?
 - [ ] What data is potentially affected?
 - [ ] How many users potentially affected?
-- [ ] Is data encrypted (E2EE)?
+- [ ] Is data encrypted?
+  - ✅ E2EE enabled: Data encrypted client-side (low risk)
+  - ❌ E2EE disabled: Data stored unencrypted in PostgreSQL (high risk)
+  - ⚠️ IMPORTANT: E2EE is optional, not mandatory - verify per user
 - [ ] Is breach ongoing or contained?
 
 ---
@@ -167,8 +171,9 @@ Answer these questions:
 
 - [ ] Email addresses
 - [ ] Password hashes
-- [ ] Sync operations (encrypted or plaintext?)
-- [ ] Snapshots (encrypted or plaintext?)
+- [ ] Sync operations (encrypted if E2EE enabled, otherwise plaintext)
+- [ ] Snapshots (encrypted if E2EE enabled, otherwise plaintext)
+- [ ] Database files (always unencrypted at disk level)
 - [ ] User content (tasks, projects, notes)
 - [ ] IP addresses / logs
 - [ ] Authentication tokens
@@ -199,7 +204,8 @@ Answer these questions:
 
 **High Risk to Users' Rights** (MUST notify users):
 
-- Unencrypted sensitive data exposed (tasks containing personal info)
+- Unencrypted sensitive data exposed (tasks/notes of non-E2EE users containing personal info)
+- Database backup stolen/exposed (non-E2EE user data readable in plaintext)
 - Credentials compromised (password hashes stolen)
 - Financial data exposed (payment info)
 - Identity theft risk
@@ -207,7 +213,8 @@ Answer these questions:
 
 **Low Risk to Users' Rights** (May not require user notification):
 
-- Data already encrypted (E2EE users)
+- Data already encrypted with E2EE (server compromise doesn't expose plaintext)
+- Note: Only applies to users who enabled E2EE (optional, not default)
 - Only metadata exposed (IP addresses, timestamps)
 - Already publicly available information
 - Highly unlikely to cause harm
@@ -216,7 +223,7 @@ Answer these questions:
 | Factor | High Risk | Low Risk |
 |--------|-----------|----------|
 | Data Type | Personal/financial | Technical metadata |
-| Encryption | Plaintext | Encrypted (E2EE) |
+| Encryption | E2EE Disabled (Unencrypted in PostgreSQL) | E2EE Enabled (Encrypted client-side) |
 | User Count | >100 users | <10 users |
 | Misuse Likelihood | High | Low |
 | User Harm Severity | Significant | Minimal |
@@ -238,7 +245,8 @@ Document risk assessment clearly - supervisory authority will review.
 **NO - Do not notify if:**
 
 - No personal data involved
-- Breach unlikely to result in risk (e.g., encrypted data, key secure)
+- Breach unlikely to result in risk (e.g., data encrypted with E2EE, keys secure)
+- ⚠️ Only applies to users who enabled E2EE (optional feature)
 - Incident was not a breach (e.g., DDoS, user error)
 
 **When in doubt: NOTIFY. Under-reporting is riskier than over-reporting.**
@@ -321,6 +329,7 @@ If investigation cannot be completed within 72 hours:
 **NO - Do not notify users if:**
 
 - Risk is low (e.g., data encrypted with E2EE, keys secure)
+- ⚠️ Users without E2EE have data stored unencrypted - higher risk
 - Disproportionate effort (e.g., contact info lost in breach)
 - Supervisory authority grants exemption
 
@@ -351,7 +360,7 @@ What Happened:
 [Brief description of breach - e.g., "On [date], we discovered unauthorized access to our database."]
 
 What Data Was Affected:
-[List specific data types - e.g., "Email addresses, password hashes (encrypted), and sync operations."]
+[List specific data types - e.g., "Email addresses, password hashes (bcrypt), and sync operations (encrypted for E2EE users, unencrypted for non-E2EE users)."]
 
 What We Are Doing:
 - [Immediate actions taken - e.g., "We immediately secured the system and rotated credentials."]
@@ -453,7 +462,9 @@ Create file: `INCIDENT-[YYYY-MM-DD]-[ID].md`
 
 - [ ] Email addresses
 - [ ] Password hashes
-- [ ] User content (encrypted/plaintext?)
+- [ ] User content (encrypted if E2EE enabled, unencrypted otherwise)
+- [ ] Was user using E2EE? (check user account settings)
+- [ ] Percentage of affected users with E2EE enabled vs disabled
 - [ ] Other: \***\*\_\*\***
 
 **Users affected:** [Number/All/Unknown]
@@ -566,7 +577,11 @@ Schedule annual incident response drill:
 ### Technical Controls
 
 - [ ] Implement comprehensive audit logging
-- [ ] Enable database encryption at rest (verify with Alfahosting)
+- [x] ❌ Database encryption at rest: NOT IMPLEMENTED
+  - PostgreSQL data files stored unencrypted on disk
+  - Compensating control: Optional E2EE available (not enabled by default)
+  - Risk: Users who don't enable E2EE have unencrypted data at rest
+  - Recommendation: Implement LUKS disk encryption OR make E2EE mandatory
 - [ ] Set up intrusion detection system (IDS)
 - [ ] Implement automated security scanning
 - [ ] Enable two-factor authentication for admin access
@@ -608,9 +623,9 @@ Schedule annual incident response drill:
 ```
 Is personal data involved?
 ├─ No → Not a data breach (may still be security incident)
-└─ Yes → Is data encrypted with keys secure?
-    ├─ Yes → Low risk, may not require notification
-    └─ No → Likely breach
+└─ Yes → Was data encrypted with E2EE?
+    ├─ Yes (E2EE enabled) → Keys secure? → Low risk, may not require notification
+    └─ No (E2EE disabled) → Unencrypted data → HIGH RISK
         └─ Affects >10 users OR sensitive data?
             ├─ No → Notify authority (low priority)
             └─ Yes → HIGH PRIORITY