# 9. Privacy & Consent — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: privacy_consent.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature, expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 9.1 Consent Management | Consent capture at registration | TC-SA-01-09-001 |
| 9.1 Consent Management | Consent record per purpose | TC-SA-01-09-002 |
| 9.1 Consent Management | Granular consent (core vs optional) | TC-SA-01-09-003 |
| 9.1 Consent Management | Consent withdrawal by the user at any time | TC-SA-01-09-004 |
| 9.1 Consent Management | Re-consent flow on a material policy change | TC-SA-01-09-005 |
| 9.1 Consent Management | Re-consent coverage dashboard | TC-SA-01-09-006 |
| 9.1 Consent Management | Admin view: consent status per user and platform-wide | TC-SA-01-09-007 |
| 9.1 Consent Management | Immutable consent history | TC-SA-01-09-008 |
| 9.1 Consent Management | Audit logging of all consent events | TC-SA-01-09-009 |
| 9.1 Consent Management | Rule: withdrawing an optional consent never blocks the core service | TC-SA-01-09-010 |
| 9.1 Consent Management | Rule: a withdrawal adds a new record rather than erasing the original | TC-SA-01-09-011 |
| 9.1 Consent Management | Rule: material change triggers re-consent; non-material does not | TC-SA-01-09-012 |
| 9.1 Consent Management | Rule: non-re-consenting users handled per policy, never silently kept | TC-SA-01-09-013 |
| 9.1 Consent Management | Rule: every consent event audit-logged with policy version and timestamp | TC-SA-01-09-014 |
| 9.1 Consent Management | Rule: consent status visible per user and aggregated in the coverage dashboard | TC-SA-01-09-015 |
| 9.2 Right to Access Personal Data | User-initiated data access request | TC-SA-01-09-016 |
| 9.2 Right to Access Personal Data | Support-initiated request handling | TC-SA-01-09-017 |
| 9.2 Right to Access Personal Data | Compilation of all personal data held | TC-SA-01-09-018 |
| 9.2 Right to Access Personal Data | Redaction of other individuals' personal data | TC-SA-01-09-019 |
| 9.2 Right to Access Personal Data | Readable export delivered securely | TC-SA-01-09-020 |
| 9.2 Right to Access Personal Data | Request tracking with deadline monitoring | TC-SA-01-09-021 |
| 9.2 Right to Access Personal Data | Audit logging of every access request, verification, fulfillment | TC-SA-01-09-022 |
| 9.2 Right to Access Personal Data | Rule: identity verification mandatory before any data is released | TC-SA-01-09-023 |
| 9.2 Right to Access Personal Data | Rule: data about other individuals is redacted | TC-SA-01-09-024 |
| 9.2 Right to Access Personal Data | Rule: requests tracked against the deadline; approaching deadlines raise reminders | TC-SA-01-09-025 |
| 9.2 Right to Access Personal Data | Rule: the export is complete within scope (all personal data, not a curated subset) | TC-SA-01-09-026 |
| 9.2 Right to Access Personal Data | Rule: fulfillment and redaction decisions audit-logged with the timeframe met | TC-SA-01-09-027 |
| 9.2 Right to Access Personal Data | Rule: repeated access requests permitted but rate-limited | TC-SA-01-09-028 |
| 9.3 Right to Deletion (Be Forgotten) | User-initiated deletion request | TC-SA-01-09-029 |
| 9.3 Right to Deletion (Be Forgotten) | Identity verification before processing | TC-SA-01-09-030 |
| 9.3 Right to Deletion (Be Forgotten) | Deletion scope review summary | TC-SA-01-09-031 |
| 9.3 Right to Deletion (Be Forgotten) | Downstream effect handling | TC-SA-01-09-032 |
| 9.3 Right to Deletion (Be Forgotten) | Deletion execution with explicit acknowledgment | TC-SA-01-09-033 |
| 9.3 Right to Deletion (Be Forgotten) | Confirmation of what was deleted and what is retained | TC-SA-01-09-034 |
| 9.3 Right to Deletion (Be Forgotten) | Propagation to all systems within the regulatory timeframe | TC-SA-01-09-035 |
| 9.3 Right to Deletion (Be Forgotten) | Request tracking and audit logging of the full deletion | TC-SA-01-09-036 |
| 9.3 Right to Deletion (Be Forgotten) | Rule: deletion is irreversible; explicit acknowledgment required | TC-SA-01-09-037 |
| 9.3 Right to Deletion (Be Forgotten) | Rule: legally required records retained but anonymized; reason communicated | TC-SA-01-09-038 |
| 9.3 Right to Deletion (Be Forgotten) | Rule: active paid subscription cancellation and refund handled in the flow | TC-SA-01-09-039 |
| 9.3 Right to Deletion (Be Forgotten) | Rule: deletion propagates to all systems (including backups) within the timeframe | TC-SA-01-09-040 |
| 9.3 Right to Deletion (Be Forgotten) | Rule: downstream effects executed and recorded in the audit log | TC-SA-01-09-041 |
| 9.3 Right to Deletion (Be Forgotten) | Rule: the full deletion audit-logged with timestamps | TC-SA-01-09-042 |
| 9.4 Data Portability | User-initiated portability request | TC-SA-01-09-043 |
| 9.4 Data Portability | Export in structured machine-readable formats | TC-SA-01-09-044 |
| 9.4 Data Portability | Scope: profile, learning progress, assessments, preferences, user content | TC-SA-01-09-045 |
| 9.4 Data Portability | Stable, documented format | TC-SA-01-09-046 |
| 9.4 Data Portability | Secure delivery of the portable file | TC-SA-01-09-047 |
| 9.4 Data Portability | Request tracking and audit logging | TC-SA-01-09-048 |
| 9.4 Data Portability | Rate limiting on repeated portability requests | TC-SA-01-09-049 |
| 9.4 Data Portability | Rule: exports include only the user's own personal data | TC-SA-01-09-050 |
| 9.4 Data Portability | Rule: derived/analytics data included where personal; aggregate excluded | TC-SA-01-09-051 |
| 9.4 Data Portability | Rule: format stable and documented; changes versioned and backward-compatible | TC-SA-01-09-052 |
| 9.4 Data Portability | Rule: repeated requests rate-limited | TC-SA-01-09-053 |
| 9.4 Data Portability | Rule: delivery secure (authenticated, time-limited link); delivery audit-logged | TC-SA-01-09-054 |
| 9.4 Data Portability | Rule: the full request tracked and audit-logged within the regulatory timeframe | TC-SA-01-09-055 |

## 9.1 Consent Management

### TC-SA-01-09-001 — Consent capture at registration
**Type:** Positive
**Covers:** 9.1 → Consent capture at registration: privacy policy, terms, and specific processing purposes presented for acceptance
**Preconditions:** A new user registration; the registration flow.
**Steps:**
1. Start a new registration.
2. Verify the privacy policy, terms, and specific processing purposes are presented for acceptance.
3. Complete the registration with acceptance.
4. Verify the consent is recorded.
**Expected Result:** The registration presents the privacy policy, terms, and specific processing purposes for acceptance (the user must accept to proceed); the consent is captured (recorded per purpose); the registration cannot complete without the required consent; the capture is logged with the policy version, timestamp, and channel.
**Priority:** Critical

### TC-SA-01-09-002 — Consent record per purpose: purpose, policy version, timestamp, channel
**Type:** Positive
**Covers:** 9.1 → Consent record per purpose: purpose, policy version, timestamp, and channel of capture
**Preconditions:** A user with consent captured for multiple purposes; the consent records.
**Steps:**
1. Capture consent for several purposes (core service, marketing, etc.).
2. Locate each consent record.
3. Verify each record has the purpose, the policy version, the timestamp, and the channel of capture.
**Expected Result:** Each consent record has the purpose (what was consented to), the policy version (under which version), the timestamp (when), and the channel of capture (through which channel); no record is missing a field; the records are granular (one per purpose); the data supports the "what was consented to, under which version, when, how" question.
**Priority:** High

### TC-SA-01-09-003 — Granular consent: core-service tracked separately from optional purposes
**Type:** Positive
**Covers:** 9.1 → Granular consent: core-service consent tracked separately from optional purposes (e.g., marketing)
**Preconditions:** A user with both core-service and optional (marketing) consent; the consent records.
**Steps:**
1. Capture core-service consent and marketing consent separately.
2. Verify the two are tracked as separate records (not a single combined consent).
3. Verify each has its own purpose, version, timestamp, and channel.
**Expected Result:** The core-service consent and the optional (marketing) consent are tracked separately (distinct records, not a single combined flag); each has its own purpose, version, timestamp, and channel; the granularity supports independent withdrawal (withdrawing marketing does not affect core); the separation is clear in the records.
**Priority:** High

### TC-SA-01-09-004 — Consent withdrawal by the user at any time from profile settings
**Type:** Positive
**Covers:** 9.1 → Consent withdrawal by the user at any time from profile settings, effective immediately
**Preconditions:** A user with an active optional consent (e.g., marketing); profile settings access.
**Steps:**
1. Open the user's profile settings (Privacy/Consent section).
2. Withdraw the marketing consent.
3. Verify the withdrawal is effective immediately (the user stops receiving marketing).
4. Verify the core service is unaffected.
**Expected Result:** The user can withdraw consent at any time from profile settings (no support needed); the withdrawal is effective immediately (the marketing communications stop at once); the core service is unaffected (the user can still use the platform); the withdrawal is recorded (a new consent record); the withdrawal is audit-logged.
**Priority:** Critical

### TC-SA-01-09-005 — Re-consent flow when a policy version changes materially
**Type:** Positive
**Covers:** 9.1 → Re-consent flow when a policy version changes materially: users prompted to review and accept the new version
**Preconditions:** A material policy change published; active users to re-consent.
**Steps:**
1. Publish a new policy version marked as material.
2. Verify all active users are flagged for re-consent.
3. Have a user log in and verify they see the re-consent notice (with the changed sections highlighted).
4. Have the user review and accept (click-through).
5. Verify the acceptance is recorded against the new policy version.
**Expected Result:** Publishing a material change flags all active users for re-consent; on their next login, users see the notice ("Our Privacy Policy has changed. Please review and accept the updated policy to continue.") with the changed sections highlighted; the acceptance is a click-through; each acceptance is recorded against the new policy version with a timestamp; the re-consent is audit-logged.
**Priority:** Critical

### TC-SA-01-09-006 — Re-consent coverage dashboard: accepted vs pending vs rejected, with the policy window
**Type:** Positive
**Covers:** 9.1 → Re-consent coverage dashboard: accepted vs. pending vs. rejected, with the policy window
**Preconditions:** A re-consent campaign in progress; the coverage dashboard.
**Steps:**
1. Open the re-consent coverage dashboard.
2. Verify it shows accepted vs. pending vs. rejected counts.
3. Verify the policy window (e.g., 30 days) is shown counting down.
4. Verify the counts are accurate (match the actual user states).
**Expected Result:** The dashboard shows the re-consent coverage (accepted vs. pending vs. rejected) with accurate counts; the policy window (e.g., 30 days) is shown counting down; the counts match the actual user states; the dashboard supports the daily monitoring; the data is refreshable; the window expiry is visible.
**Priority:** High

### TC-SA-01-09-007 — Admin view: consent status per user and platform-wide coverage
**Type:** Positive
**Covers:** 9.1 → Admin view: consent status per user and platform-wide consent coverage
**Preconditions:** Users with various consent states; the admin consent view.
**Steps:**
1. Open the admin consent view for a specific user and verify their consent status (per purpose).
2. Open the platform-wide consent coverage view.
3. Verify the per-user status is accurate.
4. Verify the platform-wide coverage is accurate (aggregated).
**Expected Result:** The admin view shows the consent status per user (per purpose: accepted, withdrawn, pending); the platform-wide consent coverage is shown (aggregated across all users); both are accurate (match the actual consent records); the view supports the compliance reporting; the data is refreshable.
**Priority:** Medium

### TC-SA-01-09-008 — Immutable consent history: withdrawals add a new record
**Type:** Positive
**Covers:** 9.1 → Immutable consent history: withdrawals add a new record rather than erasing the original
**Preconditions:** A user who accepted and then withdrew a consent; the consent history.
**Steps:**
1. Verify the original acceptance record is still present (not erased).
2. Verify the withdrawal added a new record (withdrawn, timestamp).
3. Verify the history shows the full sequence (acceptance → withdrawal).
4. Verify the original record is immutable (cannot be edited/deleted).
**Expected Result:** The original acceptance record is preserved (not erased by the withdrawal); the withdrawal added a new record (marked withdrawn, with a timestamp); the history shows the full sequence (acceptance → withdrawal); the original record is immutable (cannot be edited or deleted); the history is complete and tamper-evident.
**Priority:** High

### TC-SA-01-09-009 — Audit logging of all consent events
**Type:** Positive
**Covers:** 9.1 → Audit logging of all consent events
**Preconditions:** Consent events produced (capture, withdrawal, re-consent); audit log access.
**Steps:**
1. Produce consent events: a capture, a withdrawal, and a re-consent acceptance.
2. Locate all in the audit log.
3. Verify each has the event type, the user, the purpose, the policy version, and the timestamp.
**Expected Result:** Every consent event (capture, withdrawal, re-consent) is audit-logged; each entry has the event type, the user, the purpose, the policy version, and the timestamp; no event is missing; the log supports the compliance audit; the log is exportable.
**Priority:** High

### TC-SA-01-09-010 — Withdrawing an optional consent never blocks the core service
**Type:** Negative
**Covers:** 9.1 → Rule: core-service and optional consent tracked separately; withdrawing an optional consent never blocks the core service
**Preconditions:** A user with both core-service and marketing consent; the marketing consent to withdraw.
**Steps:**
1. Have the user withdraw the marketing consent.
2. Verify the user can still use the core service (log in, access content, etc.).
3. Verify the marketing communications stop.
4. Verify no core-service feature is blocked.
**Expected Result:** The marketing consent withdrawal does not block the core service (the user can still log in and use all core features); the marketing communications stop (the optional purpose is honored); no core-service feature is affected; the separation is exact (the optional withdrawal has zero core-service impact); the withdrawal is logged.
**Priority:** Critical

### TC-SA-01-09-011 — A withdrawal adds a new record rather than erasing the original
**Type:** Edge
**Covers:** 9.1 → Rule: consent records form an immutable history; a withdrawal adds a new record (withdrawn, timestamp) rather than erasing the original acceptance
**Preconditions:** A user with an acceptance record; a withdrawal to perform; the consent history.
**Steps:**
1. Record the original acceptance (purpose, version, timestamp).
2. Perform the withdrawal.
3. Verify the original acceptance is unchanged (not erased, not modified).
4. Verify a new record was added (withdrawn, with a new timestamp).
**Expected Result:** The original acceptance record is unchanged (not erased or modified by the withdrawal); a new record is added (marked withdrawn, with a new timestamp); the history is append-only (the original is preserved); the sequence is clear (acceptance → withdrawal); the immutability holds; the new record is audit-logged.
**Priority:** High

### TC-SA-01-09-012 — Material change triggers re-consent; non-material does not
**Type:** Edge
**Covers:** 9.1 → Rule: a material policy change triggers re-consent for all active users; a non-material change does not
**Preconditions:** A material policy change and a non-material policy change to publish; active users.
**Steps:**
1. Publish a material change and verify all active users are flagged for re-consent.
2. Publish a non-material change and verify users are NOT flagged for re-consent.
3. Verify the "material" determination is made at publish time.
4. Verify the distinction is consistent.
**Expected Result:** The material change triggers re-consent for all active users (they are flagged and prompted); the non-material change does not trigger re-consent (users are not prompted); the "material" determination is made at publish time (the publisher marks it); the distinction is consistent (material → re-consent, non-material → no re-consent); both publishes are audit-logged.
**Priority:** High

### TC-SA-01-09-013 — Non-re-consenting users handled per policy, never silently kept
**Type:** Negative
**Covers:** 9.1 → Rule: users who do not re-consent within the window are handled per policy (restrict or deactivate), never silently kept under the old consent
**Preconditions:** A re-consent window that has elapsed; users who did not re-consent (rejected or no action).
**Steps:**
1. Let the re-consent window elapse with some users not re-consenting.
2. Verify those users are handled per policy (restrict non-essential processing or deactivate).
3. Verify they are NOT silently kept under the old consent.
4. Verify each is notified of the outcome and their options.
**Expected Result:** The non-re-consenting users are handled per policy (the non-essential processing that lacks consent is restricted, or the account is deactivated where the core service cannot be provided); they are NOT silently kept under the old consent (no implicit continuation); each is notified of the outcome and their options; the handling is executed in batches (with a confirmed preview); the handling is audit-logged.
**Priority:** Critical

### TC-SA-01-09-014 — Every consent event audit-logged with policy version and timestamp
**Type:** Positive
**Covers:** 9.1 → Rule: every consent event (capture, withdrawal, re-consent) is audit-logged with the policy version and timestamp
**Preconditions:** Multiple consent events; audit log access.
**Steps:**
1. Produce consent events (capture, withdrawal, re-consent) across users.
2. Locate all in the audit log.
3. Verify each has the policy version and the timestamp.
4. Verify no event lacks the version or timestamp.
**Expected Result:** Every consent event is audit-logged with the policy version (which version the consent is against) and the timestamp (when); no event lacks either field; the log supports the compliance audit ("what was consented to, under which version, when?"); the entries are complete; the log is exportable.
**Priority:** High

### TC-SA-01-09-015 — Consent status visible per user and aggregated in the coverage dashboard
**Type:** Positive
**Covers:** 9.1 → Rule: consent status visible per user in the admin view and aggregated in the coverage dashboard for compliance reporting
**Preconditions:** Users with various consent states; the admin view and the coverage dashboard.
**Steps:**
1. Verify the per-user consent status is visible in the admin view (for a sample of users).
2. Verify the aggregated coverage is visible in the coverage dashboard.
3. Verify the per-user and aggregated views are consistent (the aggregate matches the sum of the per-user states).
4. Verify the data supports the compliance reporting.
**Expected Result:** The consent status is visible per user in the admin view (each user's consent state per purpose); the aggregated coverage is visible in the coverage dashboard (platform-wide); the two are consistent (the aggregate matches the per-user states); the data supports the compliance reporting; the views are refreshable; the consistency holds.
**Priority:** Medium

## 9.2 Right to Access Personal Data

### TC-SA-01-09-016 — User-initiated data access request from profile settings
**Type:** Positive
**Covers:** 9.2 → User-initiated data access request from profile settings (Privacy section)
**Preconditions:** An authenticated user; profile settings access.
**Steps:**
1. Open the user's profile settings (Privacy section).
2. Submit a data access request.
3. Verify the request appears in the privacy request queue.
4. Verify the regulatory deadline (e.g., 30 days) is shown.
**Expected Result:** The user can submit a data access request from profile settings (self-service, no support needed); the request appears in the privacy request queue; the regulatory deadline (e.g., 30 days) is shown on the request; the request is tracked (received state); the submission is audit-logged.
**Priority:** Critical

### TC-SA-01-09-017 — Support-initiated request handling for users who cannot self-serve
**Type:** Positive
**Covers:** 9.2 → Support-initiated request handling for users who cannot self-serve
**Preconditions:** A user who cannot self-serve (e.g., a parent on a child's account); a support admin.
**Steps:**
1. Have the support admin initiate the data access request on the user's behalf through the support flow.
2. Verify the request appears in the privacy request queue.
3. Verify the same identity verification applies.
4. Verify the same tracking applies.
**Expected Result:** The support admin can initiate the request on the user's behalf (for users who cannot self-serve); the request appears in the queue (same as a self-service request); the same identity verification applies (the requester's identity is verified); the same tracking applies (deadline monitoring, state transitions); the support-initiated request is audit-logged (with the acting admin).
**Priority:** High

### TC-SA-01-09-018 — Compilation of all personal data held
**Type:** Positive
**Covers:** 9.2 → Compilation of all personal data held: profile, account, activity, learning progress, communications, and consent records
**Preconditions:** A user with data in all categories; a data access request in progress.
**Steps:**
1. Initiate the data compilation for the user.
2. Verify the system gathers all in-scope data: profile, account history, activity, learning progress, communications, and consent records.
3. Verify the compilation is complete (no category missing).
4. Verify the data is accurate (matches the actual records).
**Expected Result:** The compilation gathers all in-scope personal data (profile, account history, activity, learning progress, communications, consent records); no category is missing; the data is accurate (matches the actual records); the compilation is complete within scope (all personal data the platform holds, not a curated subset); the compilation is logged.
**Priority:** Critical

### TC-SA-01-09-019 — Redaction of other individuals' personal data
**Type:** Positive
**Covers:** 9.2 → Redaction of other individuals' personal data (e.g., a parent's messages that contain a third party's data)
**Preconditions:** A user whose data contains other individuals' personal data (e.g., messages to a teacher that include the teacher's data); a data access request in progress.
**Steps:**
1. Initiate the compilation for the user.
2. Identify data that contains other individuals' personal data (e.g., the teacher's data in the user's messages).
3. Verify the other individuals' data is redacted or excluded per policy.
4. Verify the user's own data is preserved.
**Expected Result:** The other individuals' personal data is redacted from the export (e.g., the teacher's data in the user's messages is redacted or excluded per policy); the user's own data is preserved (not over-redacted); the redaction is accurate (only the third-party data is removed); the redaction decisions are logged; the export does not leak third-party data.
**Priority:** High

### TC-SA-01-09-020 — Readable export format delivered securely to the user
**Type:** Positive
**Covers:** 9.2 → Readable export format delivered securely to the user
**Preconditions:** A compiled data access export; the secure delivery.
**Steps:**
1. Complete the compilation and redaction.
2. Verify the export is in a readable format (optimized for human readability).
3. Deliver the export securely to the user (secure download link).
4. Verify the user can download and read the export.
**Expected Result:** The export is in a readable format (optimized for human readability — not a raw machine dump); the export is delivered securely (a secure download link, authenticated); the user can download and read the export; the delivery is logged; the export is complete (all in-scope data, redacted where required); the format is usable by the user.
**Priority:** High

### TC-SA-01-09-021 — Request tracking: received → in progress → fulfilled, with deadline monitoring
**Type:** Positive
**Covers:** 9.2 → Request tracking: received → in progress → fulfilled, with deadline monitoring and reminders
**Preconditions:** A data access request in progress; the tracking view.
**Steps:**
1. Verify the request is tracked in the "received" state.
2. Move it to "in progress" and verify the state change.
3. Complete it and verify the "fulfilled" state.
4. Verify the deadline monitoring (the regulatory deadline is tracked).
5. Verify approaching deadlines raise reminders.
**Expected Result:** The request is tracked through the states (received → in progress → fulfilled); each state change is recorded; the deadline monitoring tracks the regulatory deadline (e.g., 30 days); approaching deadlines raise reminders to the responsible admin (none lapse); the tracking is visible in the queue; the state transitions are audit-logged.
**Priority:** High

### TC-SA-01-09-022 — Audit logging of every access request, verification, and fulfillment
**Type:** Positive
**Covers:** 9.2 → Audit logging of every access request, verification, and fulfillment
**Preconditions:** Data access requests produced (with verification and fulfillment); audit log access.
**Steps:**
1. Produce a data access request (received, identity verified, compiled, redacted, delivered, fulfilled).
2. Locate all the events in the audit log.
3. Verify each: request received, identity verified, compiled, redactions applied, delivered, deadline met.
**Expected Result:** Every access request event is audit-logged (request received, identity verified, compiled, redactions applied, delivered, fulfilled); each entry has the user, the action, and the timestamp; the deadline met is recorded; no event is missing; the log supports the compliance audit; the log is exportable.
**Priority:** High

### TC-SA-01-09-023 — Identity verification mandatory before any data is released
**Type:** Negative
**Covers:** 9.2 → Rule: identity verification is mandatory before any data is released; a request from an unverified source is not fulfilled
**Preconditions:** A data access request from an unverified source; the fulfillment flow.
**Steps:**
1. Submit a data access request from an unverified source (identity not verified).
2. Attempt to fulfill the request (release the data).
3. Observe the block.
4. Verify the data is not released.
**Expected Result:** The request from an unverified source is NOT fulfilled (the data is not released); the identity verification is mandatory (the fulfillment is blocked until the identity is verified); the block is clear (the request is held, not silently dropped); the attempt is logged; no data is released without verification; the rule holds for all request types.
**Priority:** Critical

### TC-SA-01-09-024 — Data about other individuals is redacted from the export
**Type:** Negative
**Covers:** 9.2 → Rule: data about other individuals (e.g., a parent's messages to a teacher that include the teacher's data) is redacted from the export
**Preconditions:** A user whose data contains other individuals' personal data; a compiled export.
**Steps:**
1. Compile the export for the user.
2. Inspect the export for other individuals' personal data (e.g., the teacher's data in the user's messages).
3. Verify the third-party data is redacted (not present in the export).
4. Verify the user's own data is intact.
**Expected Result:** The other individuals' personal data is redacted from the export (the teacher's data in the user's messages is not present); the user's own data is intact (not over-redacted); the redaction is complete (no third-party data leaks); the redaction is accurate (only the third-party data is removed); the redaction decisions are logged; the export is safe to release.
**Priority:** High

### TC-SA-01-09-025 — Requests tracked against the deadline; approaching deadlines raise reminders
**Type:** Positive
**Covers:** 9.2 → Rule: requests are tracked against the regulatory deadline; approaching deadlines raise reminders to the responsible admin
**Preconditions:** Data access requests with approaching deadlines; the tracking and reminder system.
**Steps:**
1. Create a request with a deadline approaching (e.g., 5 days remaining).
2. Verify the reminder is raised to the responsible admin.
3. Verify the request is tracked against the deadline (the remaining time is shown).
4. Verify no request lapses (all are fulfilled within the deadline or the reminder escalates).
**Expected Result:** The requests are tracked against the regulatory deadline (the remaining time is shown); approaching deadlines raise reminders to the responsible admin (the admin is alerted before the deadline); no request lapses (all are fulfilled within the deadline, or the reminder escalates to ensure fulfillment); the tracking is visible in the queue; the reminders are logged.
**Priority:** High

### TC-SA-01-09-026 — The export is complete within scope (all personal data, not a curated subset)
**Type:** Negative
**Covers:** 9.2 → Rule: the export is complete within scope: it covers all personal data the platform holds, not a curated subset
**Preconditions:** A user with data in all categories; a compiled export; the actual data records.
**Steps:**
1. Compile the export for the user.
2. Cross-check the export against the actual data records (profile, account, activity, learning progress, communications, consent records).
3. Verify no in-scope data category is missing from the export.
4. Verify the export is not a curated subset (all records are present, not a sample).
**Expected Result:** The export is complete within scope (all personal data the platform holds is present — profile, account, activity, learning progress, communications, consent records); no in-scope category is missing; the export is not a curated subset (all records are present, not a sample or summary); the completeness is verifiable (cross-check against the actual records); the export honors the "complete" requirement; the completeness is logged.
**Priority:** Critical

### TC-SA-01-09-027 — Fulfillment and redaction decisions audit-logged with the timeframe met
**Type:** Positive
**Covers:** 9.2 → Rule: fulfillment (and any redaction decisions) is audit-logged with the timeframe met
**Preconditions:** A fulfilled data access request (with redactions); audit log access.
**Steps:**
1. Fulfill a data access request (with redactions applied).
2. Locate the fulfillment in the audit log.
3. Verify the redaction decisions are logged (what was redacted and why).
4. Verify the timeframe met is recorded (the deadline was met).
**Expected Result:** The fulfillment is audit-logged (the request was fulfilled); the redaction decisions are logged (what was redacted and the reason — e.g., "third-party data redacted per policy"); the timeframe met is recorded (the deadline was met, with the actual fulfillment time); no fulfillment is unlogged; the log supports the compliance audit; the log is exportable.
**Priority:** High

### TC-SA-01-09-028 — Repeated access requests permitted but rate-limited
**Type:** Edge
**Covers:** 9.2 → Rule: repeated access requests are permitted but are rate-limited to prevent abuse
**Preconditions:** A user submitting repeated data access requests; the rate limit known.
**Steps:**
1. Submit a data access request (permitted).
2. Submit additional requests within the rate-limit window (verify they are permitted up to the limit).
3. Submit requests beyond the rate-limit window (verify they are rate-limited).
4. Verify the rate limit is enforced (not a hard block on all repeats).
**Expected Result:** Repeated access requests are permitted (the right to access is not denied on repeat); the requests are rate-limited to prevent abuse (a maximum per period); requests within the limit are processed; requests beyond the limit are rate-limited (deferred, not hard-blocked); the rate limit is enforced consistently; the limit is logged; the right is honored (the rate limit is a reasonable constraint, not a denial).
**Priority:** Medium

## 9.3 Right to Deletion (Be Forgotten)

### TC-SA-01-09-029 — User-initiated deletion request from profile settings
**Type:** Positive
**Covers:** 9.3 → User-initiated deletion request from profile settings (Privacy section)
**Preconditions:** An authenticated user; profile settings access.
**Steps:**
1. Open the user's profile settings (Privacy section).
2. Submit a deletion request.
3. Verify the request appears in the privacy request queue.
4. Verify the request is tracked.
**Expected Result:** The user can submit a deletion request from profile settings (self-service); the request appears in the privacy request queue; the request is tracked (received state); the submission is audit-logged; the request is distinct from a data access request (deletion, not access); the queue shows the deletion type.
**Priority:** Critical

### TC-SA-01-09-030 — Identity verification before processing
**Type:** Positive
**Covers:** 9.3 → Identity verification before processing
**Preconditions:** A deletion request; the identity verification step.
**Steps:**
1. Open the deletion request.
2. Verify the requester's identity (authenticated request plus a confirmation step, given the irreversibility).
3. Verify the verification is completed before processing.
4. Verify the verification is logged.
**Expected Result:** The requester's identity is verified before the deletion is processed (authenticated request plus a confirmation step — the irreversibility requires extra assurance); the verification is completed before any processing; the verification is logged (who verified, when, how); no deletion is processed without verification; the confirmation step is present (given the irreversibility).
**Priority:** Critical

### TC-SA-01-09-031 — Deletion scope review: a summary of what will be deleted, retained, and the downstream effects
**Type:** Positive
**Covers:** 9.3 → Deletion scope review: a summary of what will be deleted, what must be retained for legal reasons (and will be anonymized), and the downstream effects
**Preconditions:** A deletion request in progress; the scope summary generation.
**Steps:**
1. Generate the deletion scope summary for the user.
2. Verify it lists what will be deleted (personal data).
3. Verify it lists what must be retained for legal reasons (e.g., financial/tax records) and that it will be anonymized.
4. Verify it lists the downstream effects (account closure, subscription cancellation, seat release, content handling).
**Expected Result:** The scope summary lists what will be deleted (the personal data); what must be retained for legal reasons (e.g., financial/tax records) and that it will be anonymized; and the downstream effects (account closure, subscription cancellation with refund, institute license seat release, content handling per policy); the summary is complete (all three sections); the summary is accurate (matches the actual data and policy); the summary is presented to the user before confirmation.
**Priority:** Critical

### TC-SA-01-09-032 — Downstream effect handling: account closure, subscription cancellation, seat release, content handling
**Type:** Positive
**Covers:** 9.3 → Downstream effect handling: account closure, subscription cancellation with refund per policy, institute license seat release, content created by the user handled per policy
**Preconditions:** A user with an active paid subscription and an institute license seat; a deletion in progress.
**Steps:**
1. Execute the deletion for the user.
2. Verify the account is closed.
3. Verify the subscription is cancelled with a refund per policy.
4. Verify the institute license seat is released.
5. Verify the content created by the user is handled per policy.
**Expected Result:** The downstream effects are handled as part of the deletion flow: the account is closed; the subscription is cancelled with a refund per policy (not left dangling); the institute license seat is released; the content created by the user is handled per policy; each effect is executed (not just noted); the effects are recorded in the audit log; the handling is complete.
**Priority:** Critical

### TC-SA-01-09-033 — Deletion execution with explicit user acknowledgment (irreversibility warning)
**Type:** Positive
**Covers:** 9.3 → Deletion execution with explicit user acknowledgment (irreversibility warning)
**Preconditions:** A deletion request with the scope summary presented; the user's acknowledgment.
**Steps:**
1. Present the scope summary with the irreversibility warning ("This action cannot be undone. [X] will be deleted. [Y] will be retained and anonymized for legal reasons. Your subscription will be cancelled with a refund of [Z].").
2. Verify the user must explicitly acknowledge (no implicit consent).
3. Execute the deletion after the acknowledgment.
4. Verify the deletion is executed.
**Expected Result:** The irreversibility warning is presented (the user is warned the action cannot be undone); the user must explicitly acknowledge (the deletion is not executed without the explicit acknowledgment); the acknowledgment is recorded; the deletion is executed after the acknowledgment; the warning is clear (what will be deleted, what retained, the refund); the execution is logged.
**Priority:** Critical

### TC-SA-01-09-034 — Confirmation to the user of what was deleted and what is retained (with reasons)
**Type:** Positive
**Covers:** 9.3 → Confirmation to the user of what was deleted and what is retained (with reasons)
**Preconditions:** A completed deletion; the confirmation to the user.
**Steps:**
1. Complete the deletion.
2. Verify the user receives a confirmation.
3. Verify the confirmation states what was deleted.
4. Verify the confirmation states what is retained (with the legal reasons for retention).
**Expected Result:** The user receives a confirmation after the deletion; the confirmation states what was deleted (the personal data); the confirmation states what is retained (the legally required records) with the reasons (e.g., "retained for tax purposes"); the confirmation is clear and complete; the confirmation is delivered (via the user's registered channel); the confirmation is logged.
**Priority:** High

### TC-SA-01-09-035 — Propagation to all systems holding the user's personal data within the regulatory timeframe
**Type:** Positive
**Covers:** 9.3 → Propagation to all systems holding the user's personal data within the regulatory timeframe
**Preconditions:** A user's personal data held in multiple systems; a deletion in progress; the regulatory timeframe known.
**Steps:**
1. Execute the deletion for the user.
2. Verify the deletion propagates to all systems holding the user's personal data (including backups per the backup-retention policy).
3. Verify the propagation completes within the regulatory timeframe.
4. Verify no system retains the user's personal data (except the legally required anonymized records).
**Expected Result:** The deletion propagates to all systems holding the user's personal data (not just the primary system — including backups per the backup-retention policy); the propagation completes within the regulatory timeframe; no system retains the user's personal data (except the legally required records, which are anonymized); the propagation is verified (all systems checked); the completion time is logged; the timeframe is met.
**Priority:** Critical

### TC-SA-01-09-036 — Request tracking and audit logging of the full deletion
**Type:** Positive
**Covers:** 9.3 → Request tracking and audit logging of the full deletion
**Preconditions:** A deletion request in progress; the tracking and audit log.
**Steps:**
1. Verify the deletion request is tracked (received → in progress → completed).
2. Verify the full deletion is audit-logged (verification, scope, execution, retention, downstream actions).
3. Verify each step has a timestamp.
4. Verify the completion time is within the regulatory timeframe.
**Expected Result:** The deletion request is tracked through the states (received → in progress → completed); the full deletion is audit-logged (identity verification, scope review, execution, retention/anonymization, downstream actions); each step has a timestamp; the completion time is within the regulatory timeframe; no step is missing; the log supports the compliance audit; the log is exportable.
**Priority:** High

### TC-SA-01-09-037 — Deletion is irreversible; explicit acknowledgment required
**Type:** Negative
**Covers:** 9.3 → Rule: deletion is irreversible; the user is warned and must confirm with explicit acknowledgment before execution
**Preconditions:** A deletion request; the execution flow.
**Steps:**
1. Attempt to execute the deletion without the user's explicit acknowledgment (verify it is blocked).
2. Verify the irreversibility warning is presented.
3. Obtain the explicit acknowledgment and execute.
4. Verify the deletion cannot be undone (no "undo" or "restore" path).
**Expected Result:** The deletion cannot be executed without the user's explicit acknowledgment (the execution is blocked); the irreversibility warning is presented (the user is warned); after the acknowledgment, the deletion is executed; the deletion is irreversible (no "undo" or "restore" path exists); the irreversibility is clear; the acknowledgment is logged; the rule holds (no accidental or implicit deletion).
**Priority:** Critical

### TC-SA-01-09-038 — Legally required records retained but anonymized; reason communicated
**Type:** Positive
**Covers:** 9.3 → Rule: legally required records (financial, tax, certain safeguarding records) are retained but anonymized; the retention reason is communicated to the user
**Preconditions:** A user with legally required records (e.g., last year's payment records for tax); a deletion in progress.
**Steps:**
1. Execute the deletion for the user.
2. Verify the legally required records are retained (not deleted).
3. Verify the retained records are anonymized (the individual can no longer be identified).
4. Verify the retention reason is communicated to the user (in the confirmation).
**Expected Result:** The legally required records (financial, tax, certain safeguarding records) are retained (not deleted — the legal obligation is honored); the retained records are anonymized (the individual can no longer be identified — the data is not usable to re-identify the user); the retention reason is communicated to the user (e.g., "retained for tax purposes"); the anonymization is effective (no re-identification path); the retention and anonymization are logged.
**Priority:** Critical

### TC-SA-01-09-039 — Active paid subscription cancellation and refund handled in the flow
**Type:** Positive
**Covers:** 9.3 → Rule: if the user has an active paid subscription, cancellation and any refund per policy are handled as part of the deletion flow, not left dangling
**Preconditions:** A user with an active paid subscription; a deletion in progress.
**Steps:**
1. Execute the deletion for the user.
2. Verify the subscription is cancelled (as part of the deletion flow).
3. Verify the refund per policy is processed (e.g., pro-rata refund).
4. Verify the cancellation and refund are not left dangling (completed, not pending).
**Expected Result:** The active paid subscription is cancelled as part of the deletion flow (not left dangling); the refund per policy is processed (e.g., pro-rata refund — the amount is calculated and issued); the cancellation and refund are completed (not pending); the refund amount is stated in the scope summary and the confirmation; the handling is logged; the user is not charged after the deletion.
**Priority:** High

### TC-SA-01-09-040 — Deletion propagates to all systems (including backups) within the timeframe
**Type:** Edge
**Covers:** 9.3 → Rule: deletion propagates to all systems holding the user's personal data (including backups per the backup-retention policy) within the regulatory timeframe
**Preconditions:** A user's personal data in the primary system and in backups; a deletion in progress; the regulatory timeframe known.
**Steps:**
1. Execute the deletion for the user.
2. Verify the primary system's data is deleted.
3. Verify the backups are handled per the backup-retention policy (the user's data is deleted from backups within the timeframe, or the backup is purged per policy).
4. Verify the propagation completes within the regulatory timeframe.
**Expected Result:** The deletion propagates to the primary system (data deleted); the backups are handled per the backup-retention policy (the user's data is deleted from backups within the timeframe, or the backup is purged per policy — the data does not persist in backups beyond the policy); the propagation completes within the regulatory timeframe; all systems are checked (no system retains the user's personal data, except the legally required anonymized records); the completion is logged; the timeframe is met.
**Priority:** Critical

### TC-SA-01-09-041 — Downstream effects executed and recorded in the audit log
**Type:** Positive
**Covers:** 9.3 → Rule: downstream effects (seat release, content handling) are executed as part of the flow and recorded in the audit log
**Preconditions:** A user with an institute license seat and user-created content; a deletion in progress.
**Steps:**
1. Execute the deletion for the user.
2. Verify the institute license seat is released (executed, not just noted).
3. Verify the user-created content is handled per policy (executed).
4. Verify both effects are recorded in the audit log.
**Expected Result:** The downstream effects are executed as part of the deletion flow (the institute license seat is released — the seat is available for reassignment; the user-created content is handled per policy — e.g., deleted or retained per the content policy); the effects are not just noted (they are actually executed); both effects are recorded in the audit log (with timestamps); the execution is verified (the seat is actually released, the content is actually handled); the log supports the compliance audit.
**Priority:** High

### TC-SA-01-09-042 — The full deletion audit-logged with timestamps
**Type:** Positive
**Covers:** 9.3 → Rule: the full deletion (verification, scope, execution, retention, downstream actions) is audit-logged with timestamps
**Preconditions:** A completed deletion; audit log access.
**Steps:**
1. Locate the full deletion in the audit log.
2. Verify each step is logged: identity verification, scope review, execution, retention/anonymization, downstream actions.
3. Verify each step has a timestamp.
4. Verify the sequence is complete (no step missing).
**Expected Result:** The full deletion is audit-logged (identity verification, scope review, execution, retention/anonymization, downstream actions); each step has a timestamp; the sequence is complete (no step is missing); the timestamps are in order (the sequence is logical); the log supports the compliance audit ("when was each step done?"); the log is exportable; the completion time is within the regulatory timeframe.
**Priority:** High

## 9.4 Data Portability

### TC-SA-01-09-043 — User-initiated portability request from profile settings
**Type:** Positive
**Covers:** 9.4 → User-initiated portability request from profile settings (Privacy section)
**Preconditions:** An authenticated user; profile settings access.
**Steps:**
1. Open the user's profile settings (Privacy section).
2. Submit a data portability request.
3. Verify the request appears in the privacy request queue.
4. Verify the request is tracked.
**Expected Result:** The user can submit a data portability request from profile settings (self-service); the request appears in the privacy request queue; the request is tracked (received state); the submission is audit-logged; the request is distinct from a data access request (portability — machine-readable, not human-readable); the queue shows the portability type.
**Priority:** High

### TC-SA-01-09-044 — Export in structured machine-readable formats per data category
**Type:** Positive
**Covers:** 9.4 → Export in structured machine-readable formats (e.g., JSON/CSV) per data category
**Preconditions:** A user with data in all categories; a portability request in progress.
**Steps:**
1. Initiate the portability export for the user.
2. Verify the export is in structured machine-readable formats (e.g., JSON/CSV).
3. Verify the export is per data category (each category in its own structured file/section).
4. Verify the format is machine-readable (parseable by a receiving system).
**Expected Result:** The export is in structured machine-readable formats (e.g., JSON/CSV — not a human-readable document); the export is per data category (profile, learning progress, assessments, preferences, content — each in its own structured file/section); the format is machine-readable (a receiving system can parse and import it); the structure is consistent (stable schema); the export is complete (all in-scope categories).
**Priority:** High

### TC-SA-01-09-045 — Scope: profile, learning progress, assessments, preferences, user content
**Type:** Positive
**Covers:** 9.4 → Scope: profile data, learning progress, assessments and results, preferences, and content created by the user
**Preconditions:** A user with data in all scope categories; a portability request in progress.
**Steps:**
1. Initiate the portability export for the user.
2. Verify the scope includes: profile data, learning progress, assessments and results, preferences, and content created by the user.
3. Verify no scope category is missing.
4. Verify the data is accurate (matches the actual records).
**Expected Result:** The portability export scope includes all five categories (profile data, learning progress, assessments and results, preferences, content created by the user); no category is missing; the data is accurate (matches the actual records); the scope is the standard scope (documented); the export is complete within the scope; the scope is logged.
**Priority:** High

### TC-SA-01-09-046 — Stable, documented format so receiving systems can import it
**Type:** Positive
**Covers:** 9.4 → Stable, documented format so receiving systems can import it
**Preconditions:** A portability export; the format documentation; a receiving system.
**Steps:**
1. Generate the portability export.
2. Verify the format is documented (the schema/structure is documented).
3. Verify the format is stable (consistent across exports).
4. Verify a receiving system can import the export (the import succeeds).
**Expected Result:** The format is documented (the schema/structure is documented — a receiving system knows the fields and their meaning); the format is stable (consistent across exports — the same schema each time); a receiving system can import the export (the import succeeds — the user's scenario: switching to another learning platform); the documentation is provided with the export; the stability is verifiable (multiple exports have the same schema).
**Priority:** High

### TC-SA-01-09-047 — Secure delivery of the portable file
**Type:** Positive
**Covers:** 9.4 → Secure delivery of the portable file (secure download link)
**Preconditions:** A completed portability export; the secure delivery.
**Steps:**
1. Complete the portability export.
2. Deliver the portable file securely to the user (secure download link).
3. Verify the link is authenticated (only the user can access it).
4. Verify the link is time-limited (expires after a period).
**Expected Result:** The portable file is delivered securely (a secure download link — not an open URL); the link is authenticated (only the user can access it — not a shared or public link); the link is time-limited (expires after a period — not permanent); the user can download the file; the delivery is logged; the file is not exposed (no unauthenticated access).
**Priority:** High

### TC-SA-01-09-048 — Request tracking and audit logging
**Type:** Positive
**Covers:** 9.4 → Request tracking and audit logging
**Preconditions:** A portability request in progress; the tracking and audit log.
**Steps:**
1. Verify the portability request is tracked (received → in progress → complete).
2. Verify the request is audit-logged (request, verification, export scope, delivery, completion).
3. Verify each step has a timestamp.
4. Verify the completion is within the regulatory timeframe.
**Expected Result:** The portability request is tracked through the states (received → in progress → complete); the request is audit-logged (request received, identity verified, export scope, delivery, completion); each step has a timestamp; the completion is within the regulatory timeframe; no step is missing; the log supports the compliance audit; the log is exportable.
**Priority:** High

### TC-SA-01-09-049 — Rate limiting on repeated portability requests
**Type:** Edge
**Covers:** 9.4 → Rate limiting on repeated portability requests
**Preconditions:** A user submitting repeated portability requests; the rate limit known.
**Steps:**
1. Submit a portability request (permitted).
2. Submit additional requests within the rate-limit window (verify they are permitted up to the limit).
3. Submit requests beyond the rate-limit window (verify they are rate-limited).
4. Verify the rate limit is enforced (a maximum per period).
**Expected Result:** Repeated portability requests are rate-limited (a maximum per period — e.g., one per 30 days); requests within the limit are processed; requests beyond the limit are rate-limited (deferred, not hard-blocked); the rate limit is enforced consistently; the limit is logged; the right is honored (the rate limit is a reasonable constraint to prevent abuse, not a denial); the next permitted request time is communicated.
**Priority:** Medium

### TC-SA-01-09-050 — Exports include only the user's own personal data
**Type:** Negative
**Covers:** 9.4 → Rule: portability exports include only the user's own personal data, not data about other individuals
**Preconditions:** A user whose data contains other individuals' personal data; a portability export.
**Steps:**
1. Generate the portability export for the user.
2. Inspect the export for other individuals' personal data (e.g., a teacher's data in the user's messages, or another student's data).
3. Verify the third-party data is NOT included in the export.
4. Verify the user's own data is intact.
**Expected Result:** The portability export includes only the user's own personal data (no data about other individuals); the third-party data is NOT included (e.g., a teacher's data in the user's messages is excluded, another student's data is excluded); the user's own data is intact (not over-excluded); the exclusion is accurate (only the third-party data is removed); the export is safe to transfer to another service; the exclusion is logged.
**Priority:** High

### TC-SA-01-09-051 — Derived/analytics data included where personal; aggregate excluded
**Type:** Edge
**Covers:** 9.4 → Rule: derived or analytics data is included where it is personal to the user (e.g., their progress metrics); purely aggregate data is excluded
**Preconditions:** A user with personal derived data (e.g., their progress metrics) and aggregate data (e.g., cohort averages); a portability export.
**Steps:**
1. Generate the portability export for the user.
2. Verify the personal derived data (e.g., the user's progress metrics) is included.
3. Verify the purely aggregate data (e.g., cohort averages) is excluded.
4. Verify the distinction is correct (personal included, aggregate excluded).
**Expected Result:** The personal derived/analytics data (e.g., the user's progress metrics — data that is personal to the user) is included in the export; the purely aggregate data (e.g., cohort averages — data that is not personal to the user) is excluded; the distinction is correct (personal → included, aggregate → excluded); the inclusion/exclusion is accurate; the rule is applied consistently; the decision is logged.
**Priority:** Medium

### TC-SA-01-09-052 — Format stable and documented; changes versioned and backward-compatible
**Type:** Edge
**Covers:** 9.4 → Rule: the format is stable and documented; format changes are versioned and backward-compatible where feasible
**Preconditions:** The portability format; a format change to make; existing exports.
**Steps:**
1. Verify the current format is documented and stable.
2. Make a format change (e.g., add a field) and verify it is versioned.
3. Verify the change is backward-compatible where feasible (existing imports still work).
4. Verify the version is indicated in the export.
**Expected Result:** The format is stable and documented (the schema is documented and consistent); a format change is versioned (the new version is indicated in the export); the change is backward-compatible where feasible (existing receiving systems can still import — the old fields are not removed, only added); the version is indicated (the export states its format version); the stability is maintained (no breaking changes without a version bump); the change is logged.
**Priority:** Medium

### TC-SA-01-09-053 — Repeated requests rate-limited
**Type:** Negative
**Covers:** 9.4 → Rule: repeated portability requests are rate-limited to prevent abuse (e.g., a maximum per period)
**Preconditions:** A user submitting repeated portability requests beyond the limit; the rate limit known.
**Steps:**
1. Submit portability requests up to the maximum per period (verify they are processed).
2. Submit an additional request beyond the maximum (verify it is rate-limited).
3. Verify the rate limit is enforced (the request is deferred, not processed).
4. Verify the next permitted time is communicated.
**Expected Result:** The repeated portability requests are rate-limited (a maximum per period — e.g., one per 30 days); requests up to the maximum are processed; the request beyond the maximum is rate-limited (deferred, not processed — the abuse is prevented); the rate limit is enforced consistently; the next permitted time is communicated (the user knows when they can request again); the limit is logged; the right is honored (the rate limit is a reasonable constraint, not a denial).
**Priority:** Medium

### TC-SA-01-09-054 — Delivery secure (authenticated, time-limited link); delivery audit-logged
**Type:** Positive
**Covers:** 9.4 → Rule: delivery is secure (authenticated, time-limited download link); the delivery event is audit-logged
**Preconditions:** A completed portability export; the secure delivery; audit log access.
**Steps:**
1. Deliver the portable file via the secure download link.
2. Verify the link is authenticated (only the user can access it).
3. Verify the link is time-limited (expires after a period).
4. Verify the delivery event is audit-logged (who, what, when).
**Expected Result:** The delivery is secure (the download link is authenticated — only the user can access it, not a public link); the link is time-limited (expires after a period — not permanent); the delivery event is audit-logged (the user, the file delivered, the timestamp); no delivery is unlogged; the link is not exposed (no unauthenticated access); the expiry is enforced (the link stops working after the period); the log supports the compliance audit.
**Priority:** High

### TC-SA-01-09-055 — The full request tracked and audit-logged within the regulatory timeframe
**Type:** Positive
**Covers:** 9.4 → Rule: the full request (initiation, verification, scope, delivery, completion) is tracked and audit-logged within the regulatory timeframe
**Preconditions:** A completed portability request; the tracking and audit log; the regulatory timeframe known.
**Steps:**
1. Verify the full request is tracked (initiation → verification → scope → delivery → completion).
2. Verify each step is audit-logged with a timestamp.
3. Verify the completion is within the regulatory timeframe.
4. Verify the sequence is complete (no step missing).
**Expected Result:** The full portability request is tracked (initiation, verification, scope, delivery, completion); each step is audit-logged with a timestamp; the completion is within the regulatory timeframe (the deadline is met); the sequence is complete (no step is missing); the timestamps are in order (the sequence is logical); the log supports the compliance audit; the log is exportable; the timeframe is met.
**Priority:** High