# Data Subject Rights Procedure — {{ ORG_NAME }}

**Effective date:** {{ EFFECTIVE_DATE }}
**Audience:** All staff who might receive a data-subject request.

A data-subject request (DSR) is any communication where a person asks
to see, correct, delete, port, or restrict the personal data we hold
about them, or asks us to stop processing it. We must reply within
**30 days** of receipt.

## 1. Where DSRs come in

Anyone in {{ ORG_NAME }} could be the first to see a DSR — over email,
on a support call, on social media, or via the **{{ CONTACT_EMAIL }}**
address. As soon as you spot one:

1. Forward the original message to **{{ CONTACT_EMAIL }}** the same day.
2. Reply to the requester acknowledging receipt within 24 hours.
3. Do **not** start fulfilling the request yourself unless you are the
   designated DSR handler.

## 2. Identity check

Before we hand over any data, we confirm the requester really is who they
say they are. Acceptable proofs in order of preference:

- They send the request from the email on file for their account
- They authenticate to their account and submit the request from inside
- They provide a government-issued photo ID matching the account name
  (held only for verification, then deleted)

Never ask for more identification than you need.

## 3. Scope and search

For each accepted request, the DSR handler:

1. Identifies all systems where the requester's data could live
   (CRM, support, billing, logs, backups, processor systems).
2. Pulls each system's record into a single working folder.
3. Redacts third-party personal data from anything we are about to
   send back (other people's names, emails, etc.).

## 4. Replying

| Right | Default action |
|---|---|
| Access | Send a CSV / PDF of the records, with a plain-language summary |
| Rectification | Update the record; tell processors so they update too |
| Erasure | Delete from production; mark backups for deletion-at-restore |
| Restriction | Flag the record so it is read-only until resolved |
| Portability | Same data, in a structured machine-readable format (JSON / CSV) |
| Objection | Stop the specific processing; document the decision |

If we refuse a request (e.g., overriding legal obligation), we tell the
requester *why* and remind them of their right to complain to the
supervisory authority.

## 5. Records

Every DSR is logged with: requester identifier, date received, date
closed, action taken, who handled it. Records are kept for **24 months**
to evidence compliance, then deleted.

## 6. Escalation

If a request looks like it might involve a breach, special-category
data, or a vulnerable individual, escalate to **{{ CONTACT_EMAIL }}**
immediately and do not respond until told to.