PrivacyOps

PrivacyOps is the day-to-day operation of a privacy programme: keeping an accurate record of which personal data the organisation processes, why, where and for how long; answering people who ask to see, correct, delete or stop the use of their data, within legal deadlines; assessing risky processing before it starts; and deciding, with evidence, whether a breach must be reported and to whom.

The unit of work is a person, not a system or dataset. One customer’s erasure request becomes tasks in a CRM, a billing system, a warehouse, two processors and a backup store, and closes only when every task has evidence. Features are assessed, and breaches judged, by their effect on people.

Who this page is for. Beginners: start with the glossary and Lab 1. Engineers who own systems: the workflow and reference implementation. Privacy leads and data protection officers (DPOs): the operating model, metrics and decision framework. Nothing here is legal advice; the dated legal facts tell you what to ask counsel.

The work is mainstream under other names: the IAPP’s CIPM body of knowledge (v4.2.0) calls it the “Privacy Program Operational Life Cycle”;^[6] NIST has a Privacy Framework;^[7] ISO/IEC 27701 specifies a privacy management system;^[8] job adverts often say “privacy operations” (our observation; postings expire). So the label is vendor-specific; the page teaches the practice under its standard names.

PrivacyOps is not a product (a platform cannot decide a lawful basis or an exemption), not data security (privacy also asks whether you should hold the data at all), not audit evidence and not cookie banners: the neighbour table says who owns those.

The “before” column is a composite of common failure patterns, not a report about a company.

Failures are enforced. In 2025 California’s privacy agency fined Honda $632,500, partly for demanding at least eight data fields before processing opt-outs that need no verification;^[9] in 2022 Sephora paid $1.2 million to settle the Attorney General’s allegations, including that it ignored Global Privacy Control signals.^[10] Manual work costs too: Gartner put the average cost of handling a request, often manually, at roughly US$1,400, and its 2019 survey found two-thirds of respondents took two weeks or more (reported 2020; old and second-hand: an order of magnitude only).^[11]

The obligations predate the label. The GDPR (adopted 2016, applied from 2018) made records of processing, one-month answers to rights requests, DPIAs, 72-hour breach notification and data protection by design legal duties.^[12] California’s CCPA, amended in 2020 by Proposition 24, the California Privacy Rights Act (CPRA),^[13] added an enforcement agency, now called “CalPrivacy”.^[14] Volume and deadlines turned privacy into an operation, and vendors named the shift.^[1]

Recent milestones:

• 14 October 2025: ISO/IEC 27701 became a stand-alone management system standard.^[8][15]
• 14 November 2025: India notified its Digital Personal Data Protection (DPDP) Rules; most duties start 18 months later, in May 2027 (clocks).^[16][17]
• 1 January 2026: California’s updated CCPA regulations added risk assessments and automated-decision rules.^[18]
• 5 February 2026: most UK Data (Use and Access) Act 2025 changes took effect, including statutory request time limits and a new lawful basis.^[19][20][21]
• 19 June 2026: UK controllers must handle data protection complaints and acknowledge each within 30 days.^[22]
• Pending: the EU “Digital Omnibus” proposal, still in committee on 18 October 2026 (advanced topics).^[23]

Who’s who. EDPB: EU regulators’ board; ICO: UK regulator (legally the Information Commission since 30 September 2026);^[25] CPPA or CalPrivacy: California’s agency; CJEU: EU Court of Justice; WP29: the EDPB’s predecessor, author of WP248; the Board: India’s Data Protection Board.

Abbreviations. DPO: data protection officer; SCC: standard contractual clauses; TIA: transfer impact assessment; LIA: legitimate-interest assessment; IDTA: the UK’s International Data Transfer Agreement; ADMT: automated decision-making technology; IAPP: International Association of Privacy Professionals, which awards the CIPM (Certified Information Privacy Manager); GRC: governance, risk and compliance.

Mental model: three registers and one rule. A privacy operation keeps three registers current: an inventory (what data, why, where, how long), cases (each person’s requests with clock and evidence) and decisions (lawful bases and LIAs, DPIAs, transfer and vendor assessments, breach decisions). The rule: no case closes and no decision is final without evidence someone else can check.

flowchart TB
  L["LegalOps"] -->|advice, contract clauses| P
  R["RiskOps"] -->|risk appetite, acceptance| P
  S["ResponseOps"] -->|breach facts and times| P
  M["MarTechOps"] <-->|consent policy out, test results back| P
  P["PrivacyOps: inventory, rights cases, DPIAs, breach decisions"]
  P -->|what must be minimised or masked| D["DataSecOps"]
  P -->|records and decisions as evidence| C["ComplianceOps"]
  P -->|erasure log, beyond use| B["BackupOps"]
  P -->|requests touching HR records| H["PeopleOps"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class P core
  class L,R,S,M,D,C,B,H neutral

Principles (proposals):

1. The person is the unit of work: cases, not tickets per system.
2. Inventory before automation: a connector cannot reach a system nobody listed; the record is a legal duty (Art. 30).^[12]
3. Clocks are designed in: a due date computed on receipt, an alert at half-time.
4. Proportionate verification: reuse existing authentication; the EDPB calls an ID copy disproportionate for an authenticated requester and inappropriate unless necessary, suitable and lawful nationally.^[26]
5. Minimise your own data: case files are a new store of personal data.
6. Evidence or it did not happen: controllers must “be able to demonstrate compliance” (Art. 5(2)).^[12]
7. Design-time gate: Art. 25 applies “at the time of the determination of the means”.^[12]

R = responsible, A = accountable, C = consulted, I = informed. A proposal: adapt names to your organisation.

Customer support is the front door: responsible for logging requests made in any wording, informed of breach notices.

A DPO (mandatory in some cases, Art. 37) advises and monitors, takes no instructions on those tasks and holds no conflicting role (Art. 38(3), 38(6)),^[12] so where one exists, keep the DPO consulted, not accountable, on these decisions.

• Day 0 (build): inventory, lawful bases and notices (playbook), retention schedule, runbooks per request type, intake and a case tracker.
• Day 1 (launch): open the intake channels; train support to recognise requests in any wording; run the first cases end to end with system owners watching.
• Day 2 (operate): cases to the clock; change screening; yearly record review; erasure and signal tests; breach drills with ResponseOps; monthly metrics.

Escalation: case owner → privacy lead → DPO or general counsel. High residual DPIA risks go to the accountable executive through RiskOps and, under the GDPR, to prior consultation with the supervisory authority (Art. 36).^[12]

Every box can start as a spreadsheet or a shared mailbox.

flowchart TB
  I["Intake: form, email, phone, agents, signals"] --> C["Case management: clock, identity, scope"]
  C --> O["Orchestration: one task per system and processor"]
  O --> S["Systems and processors: find, export, delete, suppress"]
  S --> E["Evidence store: actions, approvals, response"]
  E --> R["Response to the person"]
  E --> K["Metrics and audit"]
  N["Change intake: systems, vendors, features"] --> A["Assessments: DPIA, transfer, vendor"]
  A --> V["Inventory and record of processing"]
  D["Discovery and classification scans"] --> V
  V --> O
  P["Consent and preference store"] --> S
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class C,O,V core
  class I,S,E,R,K,N,A,D,P neutral

Trade-offs: a ticketing tool can hold cases if it restricts access and computes due dates; connectors fail silently when a schema changes, so test them monthly with a synthetic person; scanners find unlisted data but produce false positives and cannot judge purpose. The evidence store, holding exports and identity data, is a trust boundary: restrict, encrypt and expire it.

%%{init: {"flowchart": {"rankSpacing": 26, "nodeSpacing": 24, "padding": 8}}}%%
flowchart TB
  A["Request received: clock starts"] --> O{"Opt-out or marketing objection?"}
  O -->|yes| P["Act without verifying identity; confirm and log"]
  O -->|no| B{"Identity and scope clear?"}
  B -->|no| C["Ask for proportionate ID or a clarification"]
  C --> B
  B -->|yes| F{"Manifestly unfounded or excessive?"}
  F -->|yes| G["Refuse or charge: reasons and complaint rights"]
  F -->|no| X{"Complex, or a temporary surge?"}
  X -->|yes| M["Extend: tell the person why within the first month"]
  X -->|no| H["Find the person in every system and processor"]
  M --> H
  H --> J["Redact others' data; withhold under exemptions; record why"]
  J --> K["Act: export, correct, delete or stop"]
  K --> N["Respond securely; close with evidence"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class O,B,F,X decision
  class G,M risk

Happy path (illustrative): a logged-in customer asks for a copy; the login is the identity check; eleven systems return exports; another customer’s name is redacted; the export lands in the account on day 9. Exception paths behind most late cases: identity loops, silent system owners, vague requests, requests hidden in complaints, and erasures that hit legal holds.

Case law shapes the export: the first copy is free whatever the person’s motive (CJEU, C-307/22),^[27] and a “copy” is a faithful and intelligible reproduction of all the data, including extracts or whole documents where essential (C-487/21).^[28] It must not adversely affect others (Art. 15(4)), so redaction is a step, not an afterthought.^[12] Decide extensions early: Art. 12(3) requires telling the person, with reasons, within the first month;^[12] effort or routine volume alone does not justify one, a temporary surge may (EDPB).^[26]

Rights-request deadlines as of October 2026; not legal advice and not complete (other US states, sector laws and contracts add more). Breach clocks are mapped on ResponseOps.

The EDPB counts GDPR months using Regulation 1182/71: a request received on 5 March is due by 5 April, and a deadline falling on a weekend or public holiday moves to the next working day.^[26][32] Lab 2 computes these dates.

India, as of 17 October 2026: Rules 3 and 5–16 (notices, security, breaches, children, rights) apply 18 months after Gazette publication, about mid-May 2027; Consent Manager registration (Rule 4) about mid-November 2026.^[17] We found no notified version of a January 2026 proposal to cut 18 months to 12, which would bring most duties forward to November 2026; re-check the Gazette in November 2026.^[33]

Owners are in the RACI; routine checks are in the checklists.

1. Choose before processing. Record a basis for each purpose in the record of processing before the data is used; a new purpose needs its own.^[21]
2. Legitimate interests: three tests, written down. Purpose (a legitimate, specific interest?), necessity (does the processing achieve it; is there a less intrusive way?) and balancing (do people’s interests override yours, starting with what they reasonably expect?). Record the outcome as an LIA before you start (template); an opt-out offered as a safeguard is not consent.^[34] The EDPB’s draft guidelines set the same three cumulative conditions.^[35] UK only: recognised legitimate interest (Art. 6(1)(ea)) covers five pre-approved conditions, such as preventing crime or safeguarding; it needs necessity but no balancing test.^[36]
3. Consent: keep the proof. The controller must “be able to demonstrate” consent (Art. 7(1)).^[12] Record who, when, what they were told (form and notice versions), how, and any withdrawal (consent record).^[37] Children: for information society services offered directly to a child on the basis of consent, a parent consents below 16 (member states may set 13–15), with reasonable efforts to verify (Art. 8); India requires verifiable parental consent before processing any child’s data (Rule 10, from May 2027).^[12][38]
4. Notices. Inform people when you collect their data, or at the latest within one month if it came from elsewhere (Arts. 13, 14(3)); again before any new purpose (Arts. 13(3), 14(4)); and name any legitimate interest (Art. 13(1)(d)).^[12]
5. Private by default. Process only the data each purpose needs, and do not make it accessible to “an indefinite number of natural persons” without the person’s intervention (Art. 25(2)).^[12]

1. Verify identity; check exceptions such as legal obligations and legal claims (Art. 17(3)(b), (e)) and legal holds.^[12]
2. Create one task per system and processor in the record. Processors must assist (Art. 28(3)(e)); other recipients are told unless impossible or disproportionate (Art. 19).^[12] Data kept under an exception is restricted to that purpose.
3. Backups: “The key issue is to put the backup data ‘beyond use’, even if it cannot be immediately overwritten”, and the person must be told what happens to backups (ICO).^[39] Re-apply an erasure log after any restore (an Atlas and BackupOps recommendation, not regulator text).
4. If the person also objected to marketing, a minimal suppression entry stops re-import; agree the design with counsel.
5. Close only when every task has evidence; tell the person what was erased, what remains and why.

1. Give every record category a period (or criteria), a trigger (account closed, last activity, contract end) and its reason. Storage limitation makes this a duty (Art. 5(1)(e)); the record and notices state it (Arts. 30(1)(f), 13(2)(a); California §7012(e)(4)).^[12][18]
2. Run each period as a scheduled deletion or anonymisation job owned by the system owner; a legal hold suspends it for named people or matters and is reviewed for release.
3. Keep evidence: each run logs what it deleted and any errors; a failed run is chased like a late case.

India, from May 2027: erase once the purpose is deemed served (for listed classes, after a period set in the rules), warn the person 48 hours before, and keep processing logs for at least a year (Rule 8, unofficial text).^[40]

California requires online businesses that sell or share personal information to accept an opt-out preference signal plus another method; a cookie banner “is not by itself an acceptable method for submitting requests to opt-out of sale/sharing”. Opt-outs need no verification (clocks).^[18] The usual signal is Global Privacy Control (Sec-GPC: 1), a W3C Working Draft (latest dated 24 September 2026).^[24] PrivacyOps writes the rule (“GPC equals opt-out for this browser and any known profile”); MarTechOps wires the tags; both test monthly. In the EU, device storage and access need consent unless strictly necessary (ePrivacy Art. 5(3)).^[41]

Screen every change against the nine WP248 criteria (the worksheet lists them): “In most cases, a data controller can consider that a processing meeting two criteria would require a DPIA to be carried out”, though one can be enough.^[42] Processing on the authority’s published Art. 35(4) list, or an Art. 35(3) case, needs a DPIA whatever the count. Write it up with the Art. 35(7) contents (DPIA record) and review it when the risk changes (Art. 35(11)).^[12] California’s own risk assessments are due by 31 December 2027 for processing begun before 2026 and are kept for five years or while processing continues.^[18] Write one assessment that answers both.

Before data flows to a processor: Art. 28 contract terms, a security review and a record entry.^[12] For transfers out of the EU, follow the EDPB’s six steps: know your transfers, identify the tool, assess its effectiveness in the destination, add supplementary measures, take procedural steps, re-evaluate.^[43] Standard contractual clauses are the 2021 modules.^[44] The General Court dismissed a challenge to the EU–US Data Privacy Framework on 3 September 2025;^[45] we found no judgment on the appeal (C-703/25 P, lodged 31 October 2025) by 17 October 2026; re-check curia.europa.eu every quarter^[46] and keep a fallback for critical flows. UK exports use the UK’s own clauses, the IDTA or the Addendum to the EU clauses, which the ICO says to keep using while it updates them in 2026.^[47] India: transfers abroad must meet any conditions the government sets by order (Rule 15, from May 2027).^[48]

ResponseOps runs the incident and supplies facts; PrivacyOps owns the decisions below. The 72-hour GDPR clock runs from awareness, which the EDPB defines as “a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised”.^[49]

flowchart TB
  A["Facts from ResponseOps: what, whose, since when"] --> B{"Personal data affected?"}
  B -->|no| Z["Security incident only: no privacy notice"]
  B -->|yes| C["Record the awareness time"]
  C --> D{"Unlikely to result in a risk to people?"}
  D -->|yes| R["Breach register: facts, effects, decision"]
  D -->|no| E["Notify the authority: 72 hours, where feasible"]
  E --> F{"Likely high risk to people?"}
  F -->|no| R
  F -->|yes| G{"Data unintelligible, or risk since removed?"}
  G -->|yes| R
  G -->|no| G2{"Individual notices disproportionate?"}
  G2 -->|no| H["Tell people without undue delay, in plain language"]
  G2 -->|yes| Q["Public communication instead"]
  Q --> R
  H --> R
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class B,D,F,G,G2 decision
  class E,H,Q risk
  class R core

Thresholds come from GDPR Arts. 33–34; information may go to the authority in phases, and every breach is documented.^[12][49] Other regimes differ: HIPAA requires notices to individuals without unreasonable delay and no later than 60 calendar days after discovery;^[50] India, from May 2027, requires telling affected people and the Board without delay, then a detailed report to the Board within 72 hours (Rule 7, unofficial text).^[51][17]

Behaviour analytics, data-loss prevention and insider-risk tools process data about staff. WP248’s example “A company systematically monitoring its employees’ activities” meets two criteria (systematic monitoring, vulnerable people), enough for a DPIA in most cases.^[42] The ICO requires telling workers about monitoring except in very exceptional covert cases, and advises seeking and documenting their views.^[52] AI that monitors and evaluates workers’ performance and behaviour is high-risk under the EU AI Act (Annex III 4(b)).^[53] PrivacyOps owns purpose, retention, who may see a named person’s risk score, and the notice; the tools belong to AIOps for Security and EndpointOps.

As of October 2026; names are examples, not endorsements; verify features yourself.

Automate what is repetitive and checkable: due dates, tasks from the record, chasing owners, connector exports and deletes, discovery scans, draft redactions. Humans decide identity doubts, exemptions, lawful bases, DPIA conclusions and breach notifications, and review every disclosure. Treat vendor AI agents, such as Veeam’s “PrivacyOps agents”,^[5] as drafters. AI tools are processors too: prompts can hold personal data, so they need a record entry, retention and a vendor review.

Assumptions: a 400-person software company with customers in the EU, UK and California, about 60 systems holding personal data, one privacy lead and two analysts. The artefacts are tool-neutral.

1. Record-of-processing entry. One entry per activity, owned by a named person; the fields follow GDPR Art. 30(1) plus three operational fields (owner, lawful basis, systems).^[12]

Example status: syntax-checked by the Atlas validator, not executed (a data format, not a program).

id: PA-03
name: Customer support tickets
owner: Head of Support
controller_contact: "Example Ltd, privacy@example.com"
purposes: [Answer customer questions]
lawful_basis: contract
data_subjects: [customers]
data_categories: [contact details, ticket text, attachments]
recipients: [HelpdeskCo (processor)]
transfers:
  - country: US
    mechanism: "SCCs 2021/914 module 2 + transfer assessment TIA-2026-07"
retention: "3 years after ticket closure, then delete"
security_measures: "SSO with MFA; attachment scanning; access by support role only"
systems: [support_desk]
dpia: {criteria: [], status: not needed}
last_reviewed: 2026-03-15

2. Rights-request intake form. Ask only what you need to find and verify the person; requests in any other wording or channel are still valid.

Example status: syntax-checked, not executed (a form definition for a generic case tool).

form: rights-request
fields:
  - {id: request_type, type: choice, required: true,
     options: [access, erasure, correction, objection, opt_out, portability, other]}
  - {id: email, type: email, required: true,
     help: "We use this to find your records and contact you"}
  - {id: account_id, type: text, required: false}
  - {id: details, type: textarea, required: false,
     help: "Optional: which products, dates or records you mean"}
  - {id: agent, type: boolean, required: false,
     help: "Are you acting for someone else?"}
rules:
  - "opt_out requests: no identity verification; process the signal or request directly"
  - "signed-in users: the session is the identity check; do not ask for documents"
  - "case created on submit; due date computed from the received timestamp"

3. Case record. The evidence trail a regulator or auditor will ask for.

Example status: syntax-checked, not executed (illustrative schema).

{
  "case": "DSR-2026-0142",
  "type": "erasure",
  "jurisdiction": "EU",
  "received": "2026-10-01T09:12:00Z",
  "due": "2026-11-02",
  "identity": {"method": "account one-time code", "verified": "2026-10-01T09:20:00Z"},
  "tasks": [
    {"id": "T1", "system": "crm", "action": "delete",
     "done": "2026-10-03", "ref": "crm-audit-5521"},
    {"id": "T3", "system": "support_desk", "action": "processor delete",
     "done": "2026-10-06", "ref": "HC-9012"}
  ],
  "exceptions": [{"system": "billing", "basis": "Art. 17(3)(b)", "approved_by": "legal"}],
  "response_sent": null,
  "case_file_retention": "case closure + period set by counsel"
}

4. Consent record. One record per person and purpose, holding the five things the ICO says it must show (who, when, what they were told, how, withdrawal);^[37] a withdrawal is added to the record, not written over it.

Example status: syntax-checked, not executed (illustrative schema).

{
  "consent_id": "CON-2026-55102",
  "who": {"customer_id": "C-88812"},
  "purpose": "product newsletter by email",
  "when": "2026-09-14T10:02:11Z",
  "told": {"form": "signup-form-v3", "notice": "privacy-notice-v7"},
  "how": {"method": "unticked box ticked by the user", "submission_ref": "web-77120"},
  "withdrawn": null,
  "withdraw_via": ["unsubscribe link", "account settings"]
}

Three labs on synthetic data only: Python 3.8 or later and bash, standard library only, no accounts, no cost. Each lab was run on 2026-10-17 exactly as printed (Python 3.8.10, Ubuntu Linux); expected outputs are copied from those runs.

Objective. Check a small record of processing for the Art. 30 fields, lawful-basis evidence, overdue reviews and missing DPIAs. Prerequisites. Python 3.8+. Time. 20 minutes. Risk. None.

1. Create the folder and the record.

Example status: verified by execution on 2026-10-17 (bash, Linux).

mkdir -p ~/privacyops-labs/lab1 && cd ~/privacyops-labs/lab1
cat > ropa.json <<'EOF'
{
  "controller_contact": "Example Ltd, privacy@example.com, DPO: dpo@example.com",
  "activities": [
    {
      "id": "PA-01", "name": "Customer accounts and billing", "owner": "Head of Finance",
      "purposes": ["Provide the service", "Invoice and collect payment"],
      "lawful_basis": "contract", "data_subjects": ["customers"],
      "data_categories": ["contact details", "billing address", "invoices"],
      "special_categories": false, "recipients": ["payment processor"],
      "transfers": [],
      "retention": "Account: contract + 2 years; invoices: per tax law",
      "security_measures": "Encryption at rest, role-based access, access reviews",
      "systems": ["crm", "billing"], "dpia": {"criteria": [], "status": "not needed"},
      "last_reviewed": "2026-06-30"
    },
    {
      "id": "PA-02", "name": "Product analytics", "owner": "Head of Product",
      "purposes": ["Improve product features"], "lawful_basis": "legitimate_interests",
      "data_subjects": ["customers", "trial users"],
      "data_categories": ["user ID", "feature events", "IP address"],
      "special_categories": false, "recipients": ["analytics processor"],
      "transfers": [], "retention": "",
      "security_measures": "Pseudonymous user IDs; IP truncated at ingest",
      "systems": ["warehouse"], "dpia": {"criteria": [], "status": "not needed"},
      "last_reviewed": "2025-07-01"
    },
    {
      "id": "PA-03", "name": "Customer support tickets", "owner": "Head of Support",
      "purposes": ["Answer customer questions"], "lawful_basis": "contract",
      "data_subjects": ["customers"],
      "data_categories": ["contact details", "ticket text", "attachments"],
      "special_categories": false,
      "transfers": [{"country": "US", "mechanism": ""}],
      "retention": "3 years after ticket closure",
      "security_measures": "SSO, MFA, attachment malware scan",
      "systems": ["support_desk"], "dpia": {"criteria": [], "status": "not needed"},
      "last_reviewed": "2026-03-15"
    },
    {
      "id": "PA-04", "name": "Security monitoring of staff (UEBA)", "owner": "CISO",
      "purposes": ["Detect account compromise and insider threats"],
      "lawful_basis": "legitimate_interests", "lia_ref": "LIA-2026-04",
      "data_subjects": ["employees", "contractors"],
      "data_categories": ["sign-in events", "device telemetry", "risk scores"],
      "special_categories": false, "recipients": ["SOC provider"],
      "transfers": [], "retention": "Raw events 90 days; risk scores 12 months",
      "security_measures": "Access limited to SOC; four-eyes rule to unmask a person",
      "systems": ["siem", "ueba"],
      "dpia": {"criteria": ["systematic monitoring", "vulnerable data subjects",
                         "evaluation or scoring"], "status": "in progress"},
      "last_reviewed": "2026-09-01"
    }
  ]
}
EOF

2. Save the checker as ropa_check.py.

Example status: verified by execution on 2026-10-17 (Python 3, standard library).

"""Check a record of processing activities (RoPA) for gaps. Standard library only."""
import json
from datetime import date

AS_OF = date(2026, 10, 17)          # fixed so the output is reproducible
REVIEW_DAYS = 365                   # Atlas practice: every entry reviewed yearly
ART30 = ["purposes", "data_subjects", "data_categories", "recipients",
         "transfers", "retention", "security_measures"]      # GDPR Art. 30(1)(b)-(g)
OPERATIONAL = ["owner", "lawful_basis", "systems", "last_reviewed"]  # Atlas additions

with open("ropa.json") as f:
    ropa = json.load(f)

gaps_total, complete = 0, 0
if not ropa.get("controller_contact"):
    print("REGISTER: missing controller contact (Art. 30(1)(a))")
for a in ropa["activities"]:
    gaps = []
    for field in ART30 + OPERATIONAL:
        if field not in a or a[field] in ("", None):
            gaps.append(f"missing {field}")
    for t in a.get("transfers", []):
        if not t.get("mechanism"):
            gaps.append(f"transfer to {t['country']} has no transfer mechanism")
    if a.get("lawful_basis") == "legitimate_interests" and not a.get("lia_ref"):
        gaps.append("legitimate interests without an assessment reference")
    reviewed = a.get("last_reviewed")
    if reviewed and (AS_OF - date.fromisoformat(reviewed)).days > REVIEW_DAYS:
        gaps.append(f"review overdue (last {reviewed})")
    dpia = a.get("dpia", {})
    if len(dpia.get("criteria", [])) >= 2 and dpia.get("status") != "completed":
        n_crit = len(dpia["criteria"])
        gaps.append(f"DPIA {dpia.get('status')}: {n_crit} WP248 criteria met")
    status = "OK " if not gaps else "GAP"
    complete += not gaps
    gaps_total += len(gaps)
    print(f"{status} {a['id']} {a['name']}")
    for g in gaps:
        print(f"      - {g}")

n = len(ropa["activities"])
print(f"Complete entries: {complete}/{n} = {100 * complete / n:.0f}%  Gaps: {gaps_total}")

3. Run python3 ropa_check.py.

Expected output.

OK  PA-01 Customer accounts and billing
GAP PA-02 Product analytics
      - missing retention
      - legitimate interests without an assessment reference
      - review overdue (last 2025-07-01)
GAP PA-03 Customer support tickets
      - missing recipients
      - transfer to US has no transfer mechanism
GAP PA-04 Security monitoring of staff (UEBA)
      - DPIA in progress: 3 WP248 criteria met
Complete entries: 1/4 = 25%  Gaps: 6

Validation. PA-04 meets three WP248 criteria (two normally suffice), so processing should wait for the DPIA. PA-02 needs a written legitimate-interest assessment (template). Add "recipients": ["HelpdeskCo"] to PA-03 and re-run: its “missing recipients” line disappears. Troubleshooting. json.decoder.JSONDecodeError: a comma or quote was lost when pasting; run python3 -m json.tool ropa.json to find the line. Teardown. rm -rf ~/privacyops-labs/lab1

Objective. Compute due dates under the GDPR (with Regulation 1182/71 rules, an identity pause and an extension) and the CCPA regulations, and see where the regimes differ. Prerequisites. Python 3.8+. Time. 30 minutes. Risk. None; a planning aid, not legal advice.

Save as ~/privacyops-labs/lab2/clocks.py (create the folder with mkdir -p ~/privacyops-labs/lab2) and run python3 clocks.py there.

Example status: verified by execution on 2026-10-17 (Python 3, standard library).

"""Rights-request clocks (planning aid, not legal advice). Standard library only."""
import calendar
from datetime import date, timedelta

HOLIDAYS = {date(2026, 4, 6), date(2027, 1, 1)}   # supply your own calendar


def add_months(d, months):
    """Same date N months later; the month's last day if that date does not exist."""
    y, m = divmod(d.month - 1 + months, 12)
    year, month = d.year + y, m + 1
    return date(year, month, min(d.day, calendar.monthrange(year, month)[1]))


def is_working(d):
    return d.weekday() < 5 and d not in HOLIDAYS


def roll_forward(d):
    while not is_working(d):
        d += timedelta(days=1)
    return d


def business_days_after(d, n):
    while n:
        d += timedelta(days=1)
        n -= is_working(d)
    return d


def gdpr_due(received, extended=False, asked=None, answered=None):
    """Art. 12(3) with Reg. 1182/71 Art. 3; pause while waiting for ID (EDPB 01/2022)."""
    due = add_months(received, 3 if extended else 1)
    if asked and answered:
        due += timedelta(days=(answered - asked).days)  # conservative pause count
    return roll_forward(due)


def ccpa_due(received, extended=False):
    """45 calendar days from receipt (90 if extended); verification does not pause it."""
    return received + timedelta(days=90 if extended else 45)


CASES = [
    ("GDPR access, EDPB example 32", gdpr_due(date(2026, 3, 5))),
    ("GDPR, received Sat 31 Jan", gdpr_due(date(2026, 1, 31))),
    ("GDPR, ID asked 2 Oct, got 9 Oct", gdpr_due(date(2026, 10, 1),
                                                asked=date(2026, 10, 2),
                                                answered=date(2026, 10, 9))),
    ("GDPR, extended (complex)", gdpr_due(date(2026, 10, 1), extended=True)),
    ("CCPA know/delete: confirm by", business_days_after(date(2026, 10, 1), 10)),
    ("CCPA know/delete: respond by", ccpa_due(date(2026, 10, 1))),
    ("CCPA know/delete: extended", ccpa_due(date(2026, 10, 1), extended=True)),
    ("CCPA opt-out: stop selling by", business_days_after(date(2026, 10, 1), 15)),
    ("India DPDP (when in force)", date(2026, 10, 1) + timedelta(days=90)),
]
for label, due in CASES:
    print(f"{label:<32} {due.isoformat()} {due.strftime('%a')}")

Expected output.

GDPR access, EDPB example 32     2026-04-07 Tue
GDPR, received Sat 31 Jan        2026-03-02 Mon
GDPR, ID asked 2 Oct, got 9 Oct  2026-11-09 Mon
GDPR, extended (complex)         2027-01-04 Mon
CCPA know/delete: confirm by     2026-10-15 Thu
CCPA know/delete: respond by     2026-11-15 Sun
CCPA know/delete: extended       2026-12-30 Wed
CCPA opt-out: stop selling by    2026-10-22 Thu
India DPDP (when in force)       2026-12-30 Wed

Validation. The EDPB’s example gives 5 April 2026,^[26] a Sunday before Easter Monday, so Regulation 1182/71 moves it to Tuesday 7 April^[32] (plan for 5 April anyway). 28 February 2026 is a Saturday, so it rolls to 2 March. The identity case pauses the EU clock for seven days; the UK instead starts the month when the ID arrives,^[29] which here also gives 9 November. CCPA dates are not rolled past weekends. Troubleshooting. HOLIDAYS (two samples) serves both regimes here; in real use keep one calendar each: the member state’s for the GDPR (Reg. 1182/71 Art. 2(1)),^[32] and one agreed with counsel for CCPA business days, which the regulations do not define. Teardown. rm -rf ~/privacyops-labs/lab2

Objective. Fan one erasure request out to every system, apply exceptions, backups and processors, then refuse to reply until every task has evidence. Prerequisites. Python 3.8+. Time. 30 minutes. Risk. None.

1. Create the system register, the request and the evidence log.

Example status: verified by execution on 2026-10-17 (bash, Linux).

mkdir -p ~/privacyops-labs/lab3 && cd ~/privacyops-labs/lab3
cat > systems.json <<'EOF'
[
  {"system": "crm", "holds_subject": true, "action": "delete"},
  {"system": "billing", "holds_subject": true, "action": "retain",
   "exception": "Art. 17(3)(b), invoices per tax law",
   "minimise": "restrict to invoicing"},
  {"system": "support_desk", "holds_subject": true, "action": "delete",
   "processor": "HelpdeskCo"},
  {"system": "email_platform", "holds_subject": true, "action": "delete",
   "processor": "MailCo", "keep_suppression": true},
  {"system": "warehouse", "holds_subject": true, "action": "delete"},
  {"system": "backups", "holds_subject": true, "action": "beyond_use",
   "expires_days": 35, "covers": ["crm", "warehouse"]},
  {"system": "hr", "holds_subject": false, "action": "delete"}
]
EOF
cat > request.json <<'EOF'
{"case": "DSR-2026-0142", "type": "erasure", "received": "2026-10-01",
 "subject_ids": {"customer_id": "C-88812", "email": "a.person@example.com"},
 "legal_hold": false}
EOF
cat > evidence.json <<'EOF'
{"T1": {"done": "2026-10-03", "ref": "crm-audit-5521"},
 "T2": {"done": "2026-10-03", "ref": "billing-restriction-77"},
 "T3": {"done": "2026-10-06", "ref": "ticket HC-9012 confirmed by HelpdeskCo"},
 "T4": {"done": "", "ref": ""},
 "T5": {"done": "2026-10-04", "ref": "warehouse-job-3310"},
 "T6": {"done": "2026-10-04", "ref": "erasure-log row 142"}}
EOF

2. Save the planner as erasure_plan.py.

Example status: verified by execution on 2026-10-17 (Python 3, standard library).

"""Plan an erasure request across systems and check the evidence before replying."""
import json
from datetime import date, timedelta

with open("systems.json") as f:
    systems = json.load(f)
with open("request.json") as f:
    req = json.load(f)
with open("evidence.json") as f:
    evidence = json.load(f)

tasks, tid_of = [], {}
for s in systems:
    if not s["holds_subject"]:
        continue                      # searched, nothing found: record that too
    if req["legal_hold"]:
        what = "suspend: legal hold, delete when the hold is released"
    elif s["action"] == "delete":
        what = "delete records"
        if s.get("processor"):
            what = f"processor {s['processor']}: delete + confirm"
        if s.get("keep_suppression"):
            what += "; keep suppression hash"
    elif s["action"] == "retain":
        what = f"keep ({s['exception']}); {s['minimise']}"
    elif s["action"] == "beyond_use":
        what = "beyond use; re-apply after any restore"
    else:
        what = "unknown action: escalate to the privacy lead"
    tid_of[s["system"]] = f"T{len(tasks) + 1}"
    tasks.append((tid_of[s["system"]], s["system"], what))

print(f"Case {req['case']} ({req['type']}), received {req['received']}")
for tid, system, what in tasks:
    print(f"  {tid} {system:<15} {what}")

open_tasks = [t for t in tasks if not evidence.get(t[0], {}).get("done")]
no_ref = [t for t in tasks if evidence.get(t[0], {}).get("done")
          and not evidence[t[0]].get("ref")]
done = len(tasks) - len(open_tasks)
print(f"Evidence: {done}/{len(tasks)} tasks closed")
for tid, system, _ in open_tasks:
    print(f"  OPEN {tid} {system}: no completion evidence")
for tid, system, _ in no_ref:
    print(f"  WEAK {tid} {system}: closed without an evidence reference")

# A backup taken on the day of the last live deletion may still hold the person.
for s in systems:
    if s["action"] != "beyond_use" or not s["holds_subject"] or req["legal_hold"]:
        continue
    days = [evidence.get(tid_of[c], {}).get("done") for c in s["covers"]]
    if all(days):
        last = max(date.fromisoformat(d) for d in days)
        gone = last + timedelta(days=s["expires_days"] + 1)
        print(f"Backups: last copy expires by {gone} (live deletions done {last})")
    else:
        print("Backups: no expiry date until the covered live deletions are done")
ready = not open_tasks and not no_ref
print("Reply to the requester:", "READY" if ready else "NOT READY")

3. Run python3 erasure_plan.py.

Expected output.

Case DSR-2026-0142 (erasure), received 2026-10-01
  T1 crm             delete records
  T2 billing         keep (Art. 17(3)(b), invoices per tax law); restrict to invoicing
  T3 support_desk    processor HelpdeskCo: delete + confirm
  T4 email_platform  processor MailCo: delete + confirm; keep suppression hash
  T5 warehouse       delete records
  T6 backups         beyond use; re-apply after any restore
Evidence: 5/6 tasks closed
  OPEN T4 email_platform: no completion evidence
Backups: last copy expires by 2026-11-09 (live deletions done 2026-10-04)
Reply to the requester: NOT READY

4. Record MailCo’s confirmation and re-run.

Example status: verified by execution on 2026-10-17 (bash and Python 3).

python3 - <<'EOF'
import json
with open("evidence.json") as f:
    e = json.load(f)
e["T4"] = {"done": "2026-10-08", "ref": "MailCo confirmation MC-4410"}
with open("evidence.json", "w") as f:
    json.dump(e, f, indent=1)
EOF
python3 erasure_plan.py | tail -3

Expected output.

Evidence: 6/6 tasks closed
Backups: last copy expires by 2026-11-09 (live deletions done 2026-10-04)
Reply to the requester: READY

Validation. The backup taken on 4 October, the day of the last live deletion it covers, may still hold the person: 35 days plus a day’s margin gives 9 November, the date to tell them (processors confirm their own backups). hr holds no record of this person, so it gets no task; record that it was searched. Set "legal_hold": true in request.json and every task becomes a suspension. Troubleshooting. KeyError: 'exception': a retain system needs exception and minimise fields. Teardown. rm -rf ~/privacyops-labs/lab3

Targets are Atlas proposals; legal deadlines are maxima, so aim to close in half the legal period.

Impostors can abuse access requests to obtain other people’s data, and an export sent to the wrong address is itself a personal-data breach. Controls:

• Proportionate verification: reuse login; ask no more than authentication needs (principle 4).
• Delivery to a verified channel: an authenticated download area or the email already on file, not a new address in the request.
• Least privilege for case files: only the privacy team and the case’s task owners; exports encrypted; access logged.
• Retention for case files: long enough to answer complaints, then delete; the case system needs its own record entry.
• Authorised agents: check the authority without making agents hard to use.^[9]

Cost drivers are request volume, the number of systems each request touches, how many of those are manual, and exceptions that need legal review. A simple capacity model (illustrative):

• Monthly analyst hours = requests × (intake and verification hours + systems per request × manual hours per system + review hours).
• Example: 400 requests × (0.3 + 6 manual systems × 0.25 + 0.4) = 400 × 2.2 = 880 hours, or about 6.3 analysts at 140 productive hours each. Automating four of the six manual systems gives 400 × (0.3 + 2 × 0.25 + 0.4) = 480 hours, about 3.4 analysts.

Connectors pay first for the highest-volume manual systems. Deleting data you do not need lowers every future cost (fewer systems, smaller exports and breaches) and cuts storage energy: running retention schedules is the cheapest privacy control.

• Monthly synthetic-person test: a test customer in every system; file access and erasure requests; every system must appear in the export and be empty afterwards.
• Quarterly sample: re-perform ten closed cases end to end; check identity, scope, redactions and evidence.
• Discovery reconciliation: compare scanner findings with the record; every unknown store becomes an entry or a deletion.
• Complaints and regulator contacts are leading indicators: review every one for a root cause.

flowchart TB
  A["Complaint: erased person contacted again"] --> B["Open an incident and a privacy case"]
  B --> C{"Restore since the erasure date?"}
  C -->|no| D["Look for a missed system or processor"]
  C -->|yes| E["List erasures between backup date and restore"]
  E --> F["Re-apply the erasure log to the restored store"]
  D --> G["Fix the gap; delete; confirm"]
  F --> H["Check downstream copies made since restore"]
  H --> I{"Was the data used or disclosed?"}
  G --> I
  I -->|yes| J["Assess as a personal-data breach"]
  I -->|no| K["Close with evidence; tell the person"]
  J --> K
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class C,I decision
  class A,J risk

1. Contain (hours 0–2): pause sends from the restored database; open a privacy case linked to the incident.
2. Diagnose (hours 2–8): confirm the backup’s point in time; query the erasure log up to the restore (here, 37 erasures).
3. Re-apply (day 1): run the 37 deletions on the restored store and on copies made since; collect evidence per system.
4. Assess (days 1–2): decide with counsel whether this is a reportable breach; record the reasoning in the breach register either way.^[12]
5. Communicate: apologise to the complainant; decide whether to tell the other 36.
6. Prevent: make “re-apply erasure log” a mandatory restore step with BackupOps and test it in the next drill.

• “We bought a platform, so we have a programme.” Tools automate an inventory and owners; they do not create them.
• “Deleted from production means erased.” Processors, analytics copies, logs and backups also hold data.
• “Consent is the safest basis.” Consent must be freely given and as easy to withdraw as to give;^[12] it is often the wrong basis for processing you cannot stop on request.
• “Our DPIA is done.” Assessments must be reviewed when the processing or its risk changes (Art. 35(11)).^[12]
• “Legitimate interests is the flexible basis.” It holds only after the three tests are passed and written down before processing starts,^[34] and a basis cannot usually be swapped later.^[21]

Build a privacy operation when people have rights against you, when requests or launches miss deadlines, when you process sensitive data or monitor or profile people, or when customers’ contracts demand evidence.

Do not build a separate function if you are small, with few systems and a few requests a year: name an owner, keep a short record, write a one-page runbook, calendar the clocks. Do not buy a platform before you can list systems and owners; it will automate confusion. Do not use the label in place of a DPO or counsel where the law requires one.

flowchart TB
  A{"Rights apply to you?"} -->|no| B["Basic hygiene; re-check on expansion"]
  A -->|yes| C{"Systems, owners listed?"}
  C -->|no| D["First: inventory and owners, no platform"]
  C -->|yes| E{"High-risk processing?"}
  E -->|yes| F["DPIA capability and DPO advice now"]
  E -->|no| G{"Over ~20 requests a month?"}
  F --> G
  G -->|no| H["Owner, tracker, runbooks"]
  G -->|yes| I{"Systems reachable by API?"}
  I -->|yes| J["Case tool plus connectors"]
  I -->|no| K["Fix export and delete paths first"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A,C,E,G,I decision
  class D,F,J core

The thresholds are this Atlas’s heuristics, not industry benchmarks; replace them with your own hours and costs from the capacity model.

This Atlas’s proposal; no official privacy-operations maturity model is implied.

Quick wins: half-period internal targets, one verification method per channel, deleting one large store nobody needs.

Quick start

• Accountable owner named; DPO appointed or the need assessed (Art. 37)
• One intake channel published; support trained to log requests in any wording
• Systems with personal data listed with owners and export and delete paths
• Due dates computed for every open case; half-time alert set

Before launching a feature or vendor

• DPIA done if the authority’s Art. 35(4) list or Art. 35(3) covers it, or two or more WP248 criteria apply
• Lawful basis and purpose recorded (LIA for legitimate interests; consent records if consent)
• Notice updated before any new purpose; privacy-protective defaults set
• Retention period set and implemented; deletion tested
• Processor contract, transfer tool and record entry in place before data flows

Monthly operations review

• Scorecard: on-time rate, late backlog, erasure completeness, verification drop-out
• Synthetic-person test passed in every system; GPC test passed on key pages

Breach readiness (with ResponseOps)

• Awareness time recorded in every incident that may involve personal data
• Breach register includes non-notified breaches with reasoning

DPIA screening worksheet (WP248 criteria;^[42] Atlas layout)

Change: ____________________   Owner: ______________   Date: __________
On the authority's Art. 35(4) list, or an Art. 35(3) case? [ ] yes -> DPIA regardless
Criterion (tick if met)                          Evidence / note
[ ] 1 Evaluation or scoring, profiling
[ ] 2 Automated decision with legal or similar effect
[ ] 3 Systematic monitoring (incl. of staff)
[ ] 4 Sensitive or highly personal data
[ ] 5 Large scale (people, volume, duration, geography)
[ ] 6 Matching or combining datasets
[ ] 7 Vulnerable people (children, employees, patients)
[ ] 8 Innovative technology
[ ] 9 Prevents people using a service or contract
Result: 0 = no DPIA, record why | 1 = privacy lead decides | 2+ = DPIA before launch
Signed (privacy): ____________

DPIA record (headings from Art. 35(7), with the DPO’s advice under Art. 35(2) and people’s views under Art. 35(9);^[12] Atlas layout)

DPIA ID: ______  Change: ______  Owner: ______  Screening ref: ______
1 Processing: nature, scope, context, purposes (incl. any legitimate interest);
  data, people, systems, processors, transfers
2 Necessity and proportionality: basis, minimisation, retention, rights, notices
3 Risks to people: source, likelihood, severity (exposure, loss, unfair outcomes)
4 Measures: safeguards, security, how compliance is shown; residual risk
5 DPO advice: ______   Views of people or representatives (where appropriate): ______
Outcome: proceed / proceed with measures / prior consultation (Art. 36) / stop
Review when the processing or its risk changes (Art. 35(11)); next review: ______
Signed (privacy): ______   Accepted by (risk owner): ______

Legitimate-interest assessment (LIA) (the ICO’s three-part test;^[34] Atlas layout)

LIA ID: LIA-____   Record entry: PA-__   Owner: ______   Date: ______
1 Purpose: which interest, whose, what benefit? Lawful and specific?
2 Necessity: does the processing achieve it? Is there a less intrusive way?
3 Balancing: reasonable expectations; nature of the data; children or other
  vulnerable people; likely impact; safeguards (less data, opt-out, retention)
Outcome: legitimate interests apply / choose another basis / do not process
Notice names the interest: yes/no   Opt-out offered: yes/no   Review by: ______
Signed (privacy): ______

Rights-request response (access)

Subject: Your request [CASE-ID], received [DATE]
1. What we did: searched [N] systems and [M] service providers listed in our records.
2. Your data: attached securely via [CHANNEL]; format: [FORMAT].
3. About the processing: purposes, categories, recipients, retention, source,
   automated decisions and profiling (if any), transfer safeguards, your rights.
4. What we withheld and why: [EXEMPTION or "other people's data, redacted"].
5. Complaints: to us at [COMPLAINT CHANNEL] or to [AUTHORITY].
6. Questions: reply to this message; reference [CASE-ID].

Breach decision record

Breach ID: ______  Incident ID (ResponseOps): ______
Awareness time (UTC): ______  Recorded by: ______
Data and people affected (categories, approximate numbers): ______
Likely consequences for people: ______
Risk to people: unlikely / risk / high risk   Reasoning: ______
Authority notified: yes/no, when, reference: ______  Reasons if after 72 h: ______
People told: yes/no, when, how: ______
Or exception: 34(3)(a) / (b) / (c); if (c), public communication on: ______
Decided by: ______ (privacy)  ______ (legal)   Date: ______

Monthly scorecard

Month: ______        Target   Actual   Trend   Action owner
On-time closure      >=98%    ____     __      ______
Late backlog         0        ____     __      ______
Erasure completeness 100%     ____     __      ______
Record coverage      >=90%    ____     __      ______
Pre-launch reviews   100%     ____     __      ______
Signal honour rate   100%     ____     __      ______
Complaints ack <=30d 100%     ____     __      ______

Is “PrivacyOps” a certification or a job title? It is Securiti’s term and free course;^[3] the established credential is the IAPP’s CIPM,^[6] and an organisation can have its privacy management system certified against ISO/IEC 27701:2025.^[8] Job titles usually say “privacy operations” or “privacy analyst”.

Consent was withdrawn. Can we switch to legitimate interests to keep the data? Usually not. UK guidance says you “can’t usually swap from consent to a different basis”, and that switching after the fact is likely to be unfair to people.^[21] Stop the processing that relied on consent and log the withdrawal in the consent record.

Can we refuse a request made for tactical reasons, say during a dispute? Motive alone does not decide it: the first copy is free even when the reason is unrelated to checking lawfulness (CJEU).^[27] Refusal needs a manifestly unfounded or excessive request, with the burden on you (Art. 12(5)).^[12] The Digital Omnibus’s abuse ground was not law on 18 October 2026.^[59][23]

Do we have to delete data from backups? Put it beyond use and tell people what happens to backups (UK guidance; see the erasure playbook).^[39] Immutable backups make this a design decision (BackupOps).

Is pseudonymised data out of scope? Not for the key holder; for a recipient that cannot re-identify anyone, perhaps (advanced topics). Decide case by case with DataSecOps evidence.

We are not in the EU. Why lean on the GDPR? Its guidance is the most detailed public body of rights-handling practice. The workflow transfers; clocks and exemptions do not, so map each jurisdiction (for US states, the IAPP’s tracker).^[60]

• Proposed EU changes (not law). The Commission’s Digital Omnibus proposal of 19 November 2025 would require authority notification only for breaches “likely to result in a high risk”, “not later than 96 hours” after awareness, and would let controllers refuse or charge for access requests used for purposes other than protecting personal data.^[59] On 18 October 2026 the Parliament file read “Awaiting committee decision”.^[23] Keep running to 72 hours.
• Pseudonymisation is relative. The CJEU’s EDPS v SRB judgment (4 September 2025, under the EU institutions’ equivalent of the GDPR) held that pseudonymised data must not be regarded as personal data “in all cases and for every person”: for a recipient who cannot re-identify anyone, even by cross-checking, it may not be.^[61] Sharing decisions will rest on documented re-identification analysis.
• Signals and central deletion. GPC is on the W3C Recommendation track,^[24] and since 1 August 2026 California data brokers must collect deletion requests from the state’s central platform at least every 45 days.^[62]
• AI. An amendment to the EU AI Act was published on 24 July 2026, so check the current dates for its high-risk worker-monitoring category;^[53][63] California’s automated decision-making rules apply to existing uses from 1 January 2027.^[18]

Situation (illustrative). A consumer app receives 300 access requests a month by web form. After an impostor obtained another person’s order history, security proposes a government-ID photo for every request; support proposes keeping the one-time code to the email or phone on the account.

Option A: ID upload for everyone. It feels safe and stops this attack, but it collects sensitive documents the app never held (a new breach target); EDPB guidance calls ID copies disproportionate for authenticated users;^[26] California’s Honda order treated excessive verification demands as violations, both for opt-outs and for verifiable requests;^[9] and drop-outs will rise.

Option B: risk-based verification. Keep the account code; deliver exports only inside the account or to contact details on file; add a step only where risk is higher (no account, an email changed in the last 30 days, special-category data); never verify opt-outs.

Decision. The impostor succeeded because the export went to an address given in the request, not because the code was weak. Recommendation (Atlas reasoning): Option B with verified-channel delivery. Uncertainty: with health or financial data, or rising impostor attempts, a stronger step for non-account requests may become proportionate; record the reasoning in the request process’s DPIA.

Objectives: explain the label; choose and document a lawful basis; design a rights workflow with clocks, verification and evidence; screen changes for DPIAs; run an erasure across processors and backups; size the tooling.

PrivacyOps is a vendor’s word for a real job: making privacy law happen for each person, on time, with proof. The label will follow the market; the job will not, because obligations attach to people while their data spreads into new systems, processors and AI tools. Those who do it well need not own the most software: they know where personal data lives and who owns it, compute deadlines on arrival, ask for no more proof than they need, chase every copy including backups, and write down why they decided. Start with the inventory and one honest metric, on-time closure; the rest, platform included, gets easier.

All sources were opened on 2026-10-17 or later (dates in each note; EU texts on EUR-Lex unless stated); claim notes and gaps are in research/privacyops-ledger.md. Re-check: DPDP Rule 4 and the 12-month proposal (November 2026); C-703/25 P and the Digital Omnibus (quarterly); the ICO’s 2026 IDTA update and its guidance marked “under review”.

Changelog. 2026-10-17: first draft (r0), Blueprint v2, three labs executed; term status vendor-specific confirmed against the coverage matrix. 2026-10-17 (r1): DPDP start dates; UK 2026 changes; public-communication exception (Art. 34(3)); Lab 3 backup date; retention, children and non-EU transfers added; repetition cut. 2026-10-17 (r2, after the final QA score): lawful-basis and consent playbook, LIA, DPIA and consent-record templates; Art. 5 principles; early extension in Figure 3; six-column RACI; CPRA, §7026(c)–(d), HIPAA wording; re-check list. 2026-10-18, post-score polish: Art. 8 scope; recognised legitimate interest; Lab 2 holiday calendars; glossary lists; Omnibus re-checked; cuts.