# 9. Privacy & Consent

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 9. Privacy & Consent

### 9.1 Consent Management
**What it does:** Captures, records, and manages user consent for data processing — what was consented to, under which policy version, through which channel, and when — with the ability to honor withdrawals at any time and to re-collect consent when a policy changes materially. Consent is tracked granularly (core service vs. optional purposes such as marketing) so that withdrawing an optional consent never affects the core service.

**Sub-features:**
- Consent capture at registration: privacy policy, terms, and specific processing purposes presented for acceptance
- Consent record per purpose: purpose, policy version, timestamp, and channel of capture
- Granular consent: core-service consent tracked separately from optional purposes (e.g., marketing communications)
- Consent withdrawal by the user at any time from profile settings, effective immediately
- Re-consent flow when a policy version changes materially: users are prompted to review and accept the new version
- Re-consent coverage dashboard: accepted vs. pending vs. rejected, with the policy window
- Admin view: consent status per user and platform-wide consent coverage
- Immutable consent history: withdrawals add a new record rather than erasing the original
- Audit logging of all consent events

**Super Administrator User Journey:**
1. Legal updates the privacy policy to a new version with a material change (a new data-processing purpose). Super Admin opens System Settings → Privacy → Policy Versions and publishes the new version, marking it as material.
2. Publishing flags all active users for re-consent. On their next login, users see a notice: "Our Privacy Policy has changed. Please review and accept the updated policy to continue." with the changed sections highlighted.
3. Users review and accept (click-through); each acceptance is recorded against the new policy version with a timestamp.
4. Super Admin monitors the re-consent coverage dashboard daily: accepted vs. pending vs. rejected, with the policy window (e.g., 30 days) counting down.
5. For users who reject, or who do not act within the window, Super Admin reviews the required handling per policy: restrict the non-essential processing that lacks consent, or deactivate the account where the core service cannot be provided without consent.
6. Executes the handling in batches (with a confirmed preview of affected accounts), notifying each user of the outcome and their options.
7. Records the re-consent campaign completion in the compliance log: version, window, final coverage, and the handling of non-consenting users.
8. Later, a user withdraws marketing consent from their profile. The withdrawal is effective immediately, a new consent record is added (the original acceptance remains in history), and the user stops receiving marketing communications while the core service is unaffected.

**Rules & Edge Cases:**
- Core-service consent and optional (e.g., marketing) consent are tracked separately; withdrawing an optional consent never blocks the core service.
- Consent records form an immutable history: a withdrawal adds a new record (withdrawn, timestamp) rather than erasing the original acceptance.
- A material policy change triggers re-consent for all active users; a non-material change does not (the determination of "material" is made at publish time).
- Users who do not re-consent within the window are handled per policy (restrict non-essential processing or deactivate), never silently kept under the old consent.
- Every consent event (capture, withdrawal, re-consent) is audit-logged with the policy version and timestamp.
- Consent status is visible per user in the admin view and aggregated in the coverage dashboard for compliance reporting.

### 9.2 Right to Access Personal Data
**What it does:** Honors user requests to access the personal data the platform holds about them, by compiling a complete, readable export of everything held and delivering it securely within the regulatory timeframe. The flow covers self-service requests and support-initiated requests, verifies the requester's identity before releasing anything, and tracks each request against its deadline.

**Sub-features:**
- User-initiated data access request from profile settings (Privacy section)
- Support-initiated request handling for users who cannot self-serve
- Compilation of all personal data held: profile, account, activity, learning progress, communications, and consent records
- Redaction of other individuals' personal data (e.g., a parent's messages that contain a third party's data)
- Readable export format delivered securely to the user
- Request tracking: received → in progress → fulfilled, with deadline monitoring and reminders
- Audit logging of every access request, verification, and fulfillment

**Super Administrator User Journey:**
1. A user submits a data access request from their profile; it appears in the privacy request queue with a regulatory deadline (e.g., 30 days) shown.
2. Super Admin (or the assigned support admin) opens the request and verifies the requester's identity (the request comes from the authenticated account, plus a confirmation step where policy requires).
3. Initiates the data compilation for that user. The system gathers all in-scope data: profile, account history, activity, learning progress, communications, and consent records.
4. Reviews the compiled export for completeness and for data that must be redacted — for example, messages the user sent that contain another person's personal data are redacted or excluded per policy.
5. Delivers the export securely to the user (secure download link) and marks the request fulfilled, noting the timeframe met.
6. The fulfillment is audit-logged: request received, identity verified, compiled, redactions applied, delivered, and the deadline met.
7. For a user who cannot self-serve (e.g., a parent on a child's account), Super Admin initiates the request on their behalf through the support flow, with the same identity verification and tracking.
8. Super Admin reviews the privacy request queue weekly: all requests are within deadline, and approaching deadlines raise reminders so none lapse.

**Rules & Edge Cases:**
- Identity verification is mandatory before any data is released; a request from an unverified source is not fulfilled.
- Data about other individuals (e.g., a parent's messages to a teacher that include the teacher's data) is redacted from the export.
- Requests are tracked against the regulatory deadline; approaching deadlines raise reminders to the responsible admin.
- The export is complete within scope: it covers all personal data the platform holds, not a curated subset.
- Fulfillment (and any redaction decisions) is audit-logged with the timeframe met.
- Repeated access requests are permitted but are rate-limited to prevent abuse.

### 9.3 Right to Deletion (Be Forgotten)
**What it does:** Honors user requests to delete their personal data, with careful handling of what can and cannot be deleted (legal retention obligations such as financial and tax records), what is anonymized rather than deleted where retention is required, and what downstream effects deletion has (account closure, subscription cancellation, license seat release). Deletion is irreversible and requires explicit user acknowledgment.

**Sub-features:**
- User-initiated deletion request from profile settings (Privacy section)
- Identity verification before processing
- 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
- Downstream effect handling: account closure, subscription cancellation with refund per policy, institute license seat release, content created by the user handled per policy
- Deletion execution with explicit user acknowledgment (irreversibility warning)
- Confirmation to the user of what was deleted and what is retained (with reasons)
- Propagation to all systems holding the user's personal data within the regulatory timeframe
- Request tracking and audit logging of the full deletion

**Super Administrator User Journey:**
1. A user submits a deletion request from their profile; it appears in the privacy request queue.
2. Super Admin verifies the requester's identity (authenticated request plus a confirmation step, given the irreversibility).
3. Reviews the deletion scope summary the system generated: personal data to be deleted; financial records from last year's payments that must be retained for tax purposes and will be anonymized; and the downstream effects — an active paid subscription to cancel (with a pro-rata refund per policy) and an institute license seat to release.
4. Presents the summary to the user 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]." The user explicitly acknowledges.
5. Super Admin confirms the deletion; the system executes it: personal data is deleted across all systems, the retained records are anonymized so the individual can no longer be identified, the subscription is cancelled with the refund processed, and the institute seat is released.
6. The user receives confirmation of exactly what was deleted and what is retained (with the legal reasons for retention).
7. The request is audit-logged with the verified identity, the scope, the anonymization applied, the downstream actions, and the completion time (within the regulatory timeframe).
8. Super Admin reviews the deletion queue weekly to confirm all deletions completed within the regulatory timeframe and that retention/anonymization was applied correctly.

**Rules & Edge Cases:**
- Deletion is irreversible; the user is warned and must confirm with explicit acknowledgment before execution.
- Legally required records (financial, tax, certain safeguarding records) are retained but anonymized so the individual can no longer be identified; the retention reason is communicated to the user.
- 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.
- Deletion propagates to all systems holding the user's personal data (including backups per the backup-retention policy) within the regulatory timeframe.
- Downstream effects (seat release, content handling) are executed as part of the flow and recorded in the audit log.
- The full deletion (verification, scope, execution, retention, downstream actions) is audit-logged with timestamps.

### 9.4 Data Portability
**What it does:** Allows users to obtain their personal data in a structured, commonly used, machine-readable format so they can move it to another service. Unlike the right-to-access export (which is optimized for human readability), the portability export is optimized for machine import: stable, documented, structured formats covering the user's own data.

**Sub-features:**
- User-initiated portability request from profile settings (Privacy section)
- Export in structured machine-readable formats (e.g., JSON/CSV) per data category
- Scope: profile data, learning progress, assessments and results, preferences, and content created by the user
- Stable, documented format so receiving systems can import it
- Secure delivery of the portable file (secure download link)
- Request tracking and audit logging
- Rate limiting on repeated portability requests

**Super Administrator User Journey:**
1. A user requests data portability from their profile (they are switching to another learning platform); the request appears in the privacy request queue.
2. Super Admin verifies the requester's identity (authenticated request plus confirmation).
3. Initiates the portability export for the user, selecting the standard scope: profile, learning progress, assessments and results, preferences, and user-created content.
4. Reviews the export manifest to confirm all in-scope data categories are present and in the documented structured format, and that no other individuals' data is included.
5. Delivers the portable file securely to the user (secure download link) along with the format documentation.
6. Marks the request complete; the event is audit-logged (request, verification, export scope, delivery, completion).
7. The user imports the file into the new platform successfully; no follow-up is needed.
8. Super Admin reviews the portability queue periodically to confirm all requests completed within the regulatory timeframe and that the export format remains stable and documented.

**Rules & Edge Cases:**
- Portability exports include only the user's own personal data, not data about other individuals.
- Derived or analytics data is included where it is personal to the user (e.g., their progress metrics); purely aggregate data is excluded.
- The format is stable and documented so receiving systems can import it; format changes are versioned and backward-compatible where feasible.
- Repeated portability requests are rate-limited to prevent abuse (e.g., a maximum per period).
- Delivery is secure (authenticated, time-limited download link); the delivery event is audit-logged.
- The full request (initiation, verification, scope, delivery, completion) is tracked and audit-logged within the regulatory timeframe.