Data Subject Rights & Consent

Articles 15-22 of GDPR give data subjects eight rights over their personal data. Aforo provides the infrastructure to receive, route, fulfill, and audit those requests within the 72-hour Article 12 acknowledgement window. This page covers what each right means, how requests flow through the system, and the consent ledger that backs Article 7.

The eight rights at a glance#

How customers exercise their rights#

Your end-customers self-serve through the storefront portal\'s /privacy page, (e.g. https://acme.storefront.aforo.ai/privacy), which surfaces three primary actions:

Authentication on the portal

The portal requires the customer to be signed in, and Aforo identifies them from their authenticated session — a request can never impersonate another customer. Cross-customer probes return a 404.

Operator workflow — Privacy Operations queue#

Operator-side requests (email, postal mail, phone, regulator-forwarded) are filed manually into the queue at Aforo Product UI → Governance → Privacy Operations → Subject Requests. The page is the consolidated tabbed surface that replaced the standalone "Data Subject Requests" sidebar entry in May 2026 (RBAC: OWNER, ADMIN, BILLING_ADMIN). Each row carries a 72h SLA badge that flips amber → red as the deadline approaches.

State machine

Required fields when filing manually

• Subject email + customer id — the data subject being identified.
• Request type — one of ACCESS / RECTIFICATION / ERASURE / RESTRICTION / PORTABILITY / OBJECTION.
• Source channel — STOREFRONT_PORTAL / EMAIL / PHONE / POSTAL / REGULATOR / OTHER.
• Verification status — did you confirm the requestor\'s identity? Article 12(6) lets you refuse if you can\'t verify.
• Internal notes — never surfaced to the customer; audit-only for the handling operator.

Article 12 SLA timers#

Consent ledger (Article 7)#

Article 7 requires the controller to demonstrate that the data subject consented to processing. Aforo\'s consent ledger is an append-only PostgreSQL table per tenant (consent_records) that captures every grant and withdrawal with full provenance.

What gets captured on every consent event

{
  "consent_id": "cons_8a3f...",
  "tenant_id": "smartai",
  "end_customer_id": "cust_acme_alice",
  "consent_type": "marketing_emails",
  "state": "GRANTED",                       // GRANTED or WITHDRAWN
  "source": "PORTAL",                       // SIGNUP, PORTAL, COOKIE_BANNER, API, IMPORT, OPERATOR
  "granted_at": "2026-05-25T14:32:00Z",     // populated when state=GRANTED
  "withdrawn_at": null,                     // populated when state=WITHDRAWN
  "ip_address": "203.0.113.42",             // captured for evidentiary value
  "user_agent": "Mozilla/5.0 ...",
  "policy_version": "v3.1.2",               // which terms were in force at consent time
  "created_at": "2026-05-25T14:32:00Z"
}

Three consent types Aforo seeds out of the box

Withdrawing consent

Article 7(3) requires consent withdrawal to be as easy as giving it. Customers withdraw any consent from the storefront portal\'s /privacy page. Withdrawal does NOT update the existing row — it appends a new state: WITHDRAWN row. The ledger is append-only so the full grant/withdraw timeline survives audits.

GDPR-driven cascade purge#

When an erasure request enters its irreversible window (after the 30-day grace expires), Aforo cascades the erasure across every system that holds the customer's data. Each system purges its own copy independently and idempotently: