Module specifications

This page defines the common implementation contract and the module-specific deltas. A module is not complete because a form exists: its state, API, events, jobs, audit, degraded behavior and acceptance tests must close the operating loop.

Common module contract

Every module implements:

1. an explicit user problem and legal/control objective;
2. personas and permission predicates;
3. list/detail/create/review pages with labelled fields, defaults, help and validation;
4. trigger and preconditions;
5. numbered happy path and cancellable/reopenable states;
6. tenant-keyed entities, constraints, timestamps, classification and retention;
7. versioned /v1 API, scopes, idempotency, cursor pagination, optimistic lock and error schema;
8. signed versioned events with correlation/causation IDs, retries and dead letter;
9. scheduled jobs with IANA time zone and absolute UTC deadlines;
10. accessible/localisable notification templates;
11. adapter/manual fallback;
12. append-only audit and evidence;
13. empty, loading, stale, duplicate, conflict, unauthorised, timeout, partial and failure states;
14. abuse cases and rate/volume protection;
15. Given/When/Then tests;
16. service and outcome metrics that do not penalise Principals;
17. MVP/later/never boundary; and
18. maker-checker for high-impact decisions.

Common headers: Authorization, Idempotency-Key, X-Correlation-ID, If-Match: "<resource-version>". Errors return:

{
  "type": "https://opendpdp.org/problems/version-conflict",
  "title": "The record changed",
  "status": 409,
  "code": "RESOURCE_VERSION_CONFLICT",
  "detail": "Refresh and compare your changes.",
  "correlation_id": "cor_synthetic_01",
  "retryable": false,
  "field_errors": []
}

1. Customer acquisition and onboarding

Problem/control: establish a secure, correctly scoped tenant without production PII in trials. Personas: sales engineer (synthetic only), tenant owner, security admin, legal reviewer.

Pages and fields: trial request; domain verification; tenant (name, slug, time_zone, deployment_profile, region); entities/brands/units; sector/licence; role assessment; contacts; SSO/SCIM/MFA/IP/service accounts; role mapping; import dry run; readiness; go-live; offboarding. Critical validations are described in enterprise onboarding.

Trigger/preconditions: approved request and verified organisational domain. Happy path: create tenant → MFA → entity/role → access → imports → synthetic tests → maker-checker → live.

State: trial → provisioned → configuring → review_pending → approved → live → offboarding → deleted; branches expired, rejected, suspended. Reopen from review to configuring with a reason. Deletion is terminal except evidence explicitly retained by policy.

Data/API/events/jobs: Tenant, LegalEntity, User, RoleBinding, DeploymentProfile, SetupCheck; POST /v1/tenants, /entities, /imports:dry-run, /go-live-approvals; tenant.provisioned.v1, tenant.activated.v1, tenant.offboarding_started.v1. Jobs check domain, contact, SCIM drift, checklist staleness and deletion.

Failures/abuse: last-owner SCIM deletion blocked; duplicate domain reviewed; secret never logged; trial connector blocked; import is transactionally dry-run; tenant-squatting rate limited.

Evidence/metrics: domain proof, role decision, access tests, approval; time to safe activation, critical skipped items, SSO/restore test rate. MVP: one tenant/entity, OIDC, MFA, roles, CSV import, approval. Later: SAML/SCIM, groups, multi-entity, air-gap bundle. Never: real PII demo.

Acceptance: Given no SDF notification source, when “designated” is selected, then approval fails.

2. Applicability and obligation registry

Problem/control: know which entity, role and source applies without presenting automated legal advice. Personas: legal reviewer, privacy admin, sector owner, auditor.

Pages/fields: entity tree; licences (authority, category, number, effective/expiry); products/channels; India nexus; Data Principal populations; role per processing activity; instruments; obligation plan (LEG, CTRL, owner, status, exception, review).

Happy path: record facts → propose sources → reviewer classifies role/applicability → approve configuration version → diff impacted controls. State: assessment draft → facts_complete → legal_review → approved → superseded; uncertain blocks auto-activation.

Data/API/events: ApplicabilityAssessment, InstrumentVersion, Obligation, ControlMapping; GET/POST /v1/processing-activities, /v1/obligations; legal_config.approved.v1, obligation.impact_detected.v1. Nightly job finds expiring licences and stale legal review.

Failure/abuse: a scraper cannot activate law; a user cannot apply an exemption tenant-wide; sector pack mismatch warns and requires review. Evidence: signed assessment/diff. Metrics: high-risk activities with approved entity/role/source; stale assessments. MVP: curated DPDP and one sector pack. Later: change feeds and policy simulation. Never: autonomous legal opinion.

Acceptance: Given a vendor has an independent analytics purpose, when its activity is reviewed, then it cannot remain only a Processor instruction.

3. Data discovery, inventory and processing activities

Problem/control: locate data/flows without copying raw PII into the control plane. Personas: data/system owner, privacy admin, connector admin, reviewer.

Pages/fields: systems; datasets/fields; scan runs; findings (category, confidence, sample policy, owner, status); processing activity (entity, purpose, principals, sources, recipients, processors, countries, retention, safeguards); graph/lineage.

Trigger: manual entry/import or approved metadata connector. Happy path: configure local agent → test scope → scan schema/metadata → classify → owner reviews false positives → approve inventory/activity. Sampling is disabled by default; where enabled, redact locally and never retain raw sample in the control plane.

State: connector draft/tested/active/degraded/revoked; finding new/confirmed/rejected/suppressed; activity draft/review/active/retired. Data/API: System, Dataset, DataField, DiscoveryFinding, ProcessingActivity, DataFlow; /v1/connectors, /v1/processing-activities; events scan.completed.v1, classification.reviewed.v1. Scheduled incremental scans use source cursors.

Failures: permission denied shows missing scope; stale result carries source timestamp; schema rename opens reconciliation; rate/load budget aborts safely; offline agent queues signed summary. Abuse: prevent wildcard production scans, query injection, secret exfiltration and sample download. Evidence: connector policy, run manifest, reviewer decisions. Metrics: owned systems, unreviewed high-confidence findings, scan freshness. MVP: manual/CSV plus PostgreSQL metadata scanner. Later: MySQL/SQL Server/Oracle, object/data warehouse/SaaS/streams. Never: central raw-data crawler by default.

Acceptance: Given sample access is off, when a scan runs, then no cell value crosses the agent boundary.

4. Purpose, notice, consent and preferences

Problem/control: bind an exact purpose/data/recipient to approved copy and provable choice. Personas: data owner, privacy/content/legal reviewer, developer, Principal.

Pages/fields: purpose catalogue (ground, section 7 subtype, data, recipients, retention); notice builder/version/translation; channel deployment; receipt search/export/dispute; preference centre; withdrawal propagation and reconciliation.

Happy path: approve purpose → author/review notice and translations → publish immutable version → client requests consent → record grant/deny → show receipt → withdrawal creates downstream tasks. No legitimate_interest enum exists.

State: purpose/notice draft → review → approved → active → superseded; consent requested → granted|denied → withdrawn with optional lawful expiry only if configured; propagation queued → sent → acknowledged|failed → reconciled.

Data/API/events: Purpose, NoticeVersion, Translation, ConsentReceipt, Preference, PropagationTask; /v1/notices, /v1/purposes, /v1/consents, POST /v1/consents/{id}/withdraw, /preferences; consent.granted.v1, consent.withdrawn.v1, propagation.failed.v1. Receipts are append-only; correction creates a linked record.

Jobs: translation staleness, destination retry with exponential backoff/jitter, expiry where lawfully configured, pre-commencement notice campaign. Failures: clock skew records occurred and received time; duplicate grant idempotent; offline receipt sync detects conflicting notice; unknown version rejected; partial withdrawal visible.

Abuse: prohibit preselection, bundled purpose, replay, forged proof, admin backdating and easier grant than withdrawal. Evidence: notice hash/delivery, receipt, propagation report. Metrics: proof completeness, comparable-step audit, propagation latency/failure—not grant rate. MVP: web and API English notice, receipt/withdrawal, generic webhook. Later: mobile SDK, branch/IVR/paper, translation, AA/DEPA adapter. Never: buy/sell consent graph.

Acceptance: Given one downstream timeout, when withdrawal completes elsewhere, then status is partial and retries only the failed destination.

5. Data Principal rights, grievance and nomination

Problem/control: safely authenticate, fulfil and explain exact rights without gathering excess identity data. Personas: Principal, assisted agent, DPO, legal reviewer, system owner.

Pages/fields: portal start; identity method/outcome; request/grievance form; case timeline; assignments/tasks; secure messages; response package; exception/refusal; nomination and activation.

Happy path: submit → match/verify → triage → create per-system tasks → review/redact → approve → secure delivery → feedback/close. State: detailed in the portal spec; reopen on new evidence or failed destination; withdrawal cancels pending work but preserves audit.

Data/API/events: DataPrincipalRef, IdentityMatch, RightsRequest, Grievance, Nomination, FulfilmentTask, SecureMessage, DisclosurePackage; /v1/rights-requests, /v1/grievances; rights_request.received.v1, task.completed.v1, response.delivered.v1. Principal refs use tenant-secret HMAC over stable customer ID; re- identification requires a scoped connector call.

Jobs: clock/escalation, clarification reminder, secure-link expiry, stuck task, message delivery. Failures: no match → assisted review; multiple matches → safe clarification; connector down → manual task; third-party content → redaction review; refusal requires source and checker.

Abuse: impersonation, enumeration, mass export, attachment malware, abusive duplication, support collusion. Evidence: identity method/outcome, complete timeline, tasks, approval and delivery. Metrics: acknowledgement/fulfilment time, partial/failure reason, reopen and identity override—not low request volume. MVP: access/correction/erasure/grievance case, manual/API tasks, secure messages. Later: nomination activation and advanced package generation. Never: automatic legal refusal.

Acceptance: Given an existing authenticated session, when risk is low, then no new government identity document is requested.

6. Retention, legal holds and deletion

Problem/control: reconcile purpose end and withdrawal with binding preservation, processors and backups. Personas: records manager, legal reviewer, system owner, auditor.

Pages/fields: rule catalogue; conflict view; hold create/review/release; disposal queue; destination task; backup policy; certificate/exception. Exact rule fields are in the retention page.

State: rule draft/review/active/superseded; hold proposed/active/review_due/released; disposal planned/approved/running/partial/verified/failed/cancelled. Release recalculates original trigger; it does not restart retention.

Data/API/events: RetentionPolicy, RetentionRule, LegalHold, DisposalJob, DeletionCertificate; /v1/retention-policies, /v1/legal-holds, /v1/deletion-jobs; retention.due.v1, hold.applied.v1, deletion.verified.v1. Jobs calculate due records at tenant time-zone boundaries, batch with limits and replay tombstones after restore.

Failures/abuse: stale source blocks destructive action; query mismatch quarantines batch; processor timeout creates partial certificate; hold overbreadth alerts; admin cannot delete audit or backdate completion. Evidence: source-linked rule, approval, count/hash, destination proof, backup expiry. Metrics: due backlog, verified rate, hold age/scope, re-deletion tests. MVP: rules, holds and manual/API tasks. Later: policy-as-code/query adapters and automated certificates. Never: unreviewed global purge.

Acceptance: Given a seven-year hold and consent withdrawal, when evaluated, then optional use stops while the scoped record remains restricted and explained.

7. Personal data breach workflow

Problem/control: preserve facts and run independent clocks under uncertainty. Personas: reporter, incident commander, CISO, DPO, legal/communications reviewer.

Pages/fields: intake; timeline; affected systems/data/population; regime assessments; clocks; tasks; Principal notice; Board/CERT-In/sector reports; delivery/submission; remediation/postmortem.

Happy path: signal → timestamp/commander → contain/preserve → parallel legal tests → approve initial reports/notices → update within clocks → remediate → closure review. State: reported → triage → active → contained → notification_active → remediating → closure_review → closed, with false_positive and reopened. Severity never resets awareness.

Data/API/events: Incident, BreachAssessment, AffectedPopulation, StatutoryClock, Notification, RegulatorReport; /v1/incidents; incident.reported.v1, clock.triggered.v1, notification.sent.v1. Jobs escalate at configurable percentages and verify portal/manual receipt.

Failures/abuse: portal down → evidence attempt and fallback; unknown population → versioned estimate; channel failure → retry/alternate; compromised admin cannot suppress clock; privileged notes separated. Evidence: immutable timeline, decisions, versions, receipts and remediation. Metrics: time to acknowledge/decision/report, delivery coverage and recurrence—not incident count. MVP: manual case/clocks/templates/evidence. Later: SIEM/SOAR and regulator adapters only when documented. Never: automatic “not reportable.”

Acceptance: Given severity changes, then awareness_at and deadlines do not change.

8. Child, parent and guardian

Problem/control: proportionate age/relationship assurance and enforce child restrictions. Personas: parent/guardian, child, assisted agent, child-safety/legal/product reviewer.

Pages/fields: assurance policy/case; parent relationship; consent; exception; child processing feature/SDK inventory; age transition; conflict/manual review. State: case initiated → method_selected → verification_pending → verified|failed|manual_review → expired; exception draft/review/active/revoked.

Data/API/events: AgeAssurancePolicy, GuardianRelationship, VerificationCase, ChildProcessingException; /v1/age-assurance-cases; guardian.verified.v1, child_policy.violation.v1. Jobs expire evidence, review exceptions and trigger adulthood transition.

Failures/abuse: account takeover, false parent, conflicting guardian, excessive ID collection, SDK bypass. Store outcome/token rather than raw document by default. Evidence: method rationale, outcome, consent, exception and release test. Metrics: intrusive-method rate, manual failure, child-mode policy violations. MVP: configurable verified-parent workflow and feature blocklist. Later: external attribute providers/complex guardian transitions. Never: universal Aadhaar or covert child tracking.

Acceptance: Given child mode and an advertising SDK egress, then release approval fails.

9. Vendor and processor governance

Problem/control: govern instruction, chain, incident, evidence and exit. Personas: processor manager, procurement, legal, CISO, vendor respondent, auditor.

Pages/fields: vendor/service; role; data/systems/countries; materiality; due diligence; contract/clause map; subprocessor; finding/remediation; incident; evidence room; exit.

State: vendor prospect → due_diligence → approved → active → restricted → exiting → exited; assessment open → submitted → review → accepted|remediation → closed; contract version immutable.

Data/API/events: Vendor, Processor, Subprocessor, Contract, Assessment, Finding; /v1/vendors; subprocessor.change_proposed.v1, vendor.incident_received.v1, contract.expiring.v1. Jobs monitor evidence/contract expiry, concentration and unanswered findings.

Failures/abuse: vendor cannot self-approve; uploaded evidence malware-scanned; shared answers stay tenant-isolated; unannounced subprocessor opens breach/remediation review. Evidence: due diligence, clauses, approvals, monitoring, exit. Metrics: critical vendors with current contract/incident/exit tests; finding age. MVP: register, assessment, contract map, subprocessors. Later: evidence exchange and continuous signals. Never: scrape secret vendor portals.

Acceptance: Given a critical provider changes country, when proposed, then impacted transfer and contract controls reopen before activation.

10. DPIA, SDF and algorithmic risk

Problem/control: operate designation-dependent governance and recommended high-risk review. Personas: DPO, model/data owner, CISO, legal, independent auditor, board reviewer.

Pages/fields: SDF designation source; DPO/auditor; assessment trigger/scope; data flow; rights risk; safeguards/residual risk; model inventory/tests; findings; significant observation report.

State: assessment draft → evidence_gathering → review → remediation → approved → reassessment_due; risk acceptance needs senior checker. Data/API/events: DPIA, Audit, AlgorithmicSystem, Finding, Remediation; /v1/dpias, /v1/algorithmic-systems; dpia.approved.v1, model.material_change.v1, sdf.report_due.v1.

Jobs: annual cycle from designation, material-change triggers, remediation due, evidence stale. Failures/abuse: no notification means candidate only; model owner cannot approve residual risk; protected evaluation data is referenced, not copied. Evidence: designation, assessment, tests, approval, report. Metrics: high-risk change coverage, overdue remediation, evidence freshness. MVP: generic DPIA and SDF readiness. Later: model registry integrations. Never: automated SDF declaration or algorithmic safety certification.

Acceptance: Given a material new population, when the model changes, then reassessment opens before production approval.

11. Cross-border policy

Problem/control: model storage, traffic, keys, support and government access under DPDP orders, SDF and sector rules. Personas: legal, cloud/security architect, vendor/system owner.

Pages/fields: transfer; destination/recipient; storage/backup/log/support/key locations; instrument/rule; assessment; policy test; exception/remediation. State: discovered → assessment → allowed|restricted|blocked|uncertain → monitoring → retired.

Data/API/events: Transfer, ResidencyPolicy, PolicyEvaluation; /v1/transfers; transfer.detected.v1, residency.policy_failed.v1. Jobs compare cloud/connector inventory with signed legal policy.

Failures/abuse: unknown policy blocks automatic approval; region label is verified against actual resources; admin cannot suppress remote support/log destination; future rule creates remediation, not destructive auto-migration. Evidence: assessment, inventory and policy result. Metrics: unassessed destinations, failing workloads, stale inventories. MVP: manual register/policy. Later: cloud/IaC enforcement. Never: invented country list.

Acceptance: Given India storage and foreign support access, then the foreign destination appears in the assessment.

12. Evidence, audit and dashboards

Problem/control: make decisions reproducible and tamper-evident without claiming they prove overall compliance. Personas: control owner, auditor, legal reviewer, executive, regulator- response team.

Pages/fields: control/evidence index; collection; test; exception; audit event search; pack builder; signed manifest; executive queue. State: evidence requested → collected → validated → current → stale|revoked; pack draft → scoped → approved → generated → verified → expired.

Data/API/events: Control, EvidenceArtifact, ControlTest, Exception, AuditEvent, ExportManifest; /v1/evidence; evidence.stale.v1, export.generated.v1. Audit writes are append-only; daily roots are signed with customer/KMS key and exported to optional WORM storage.

Failures/abuse: mass export needs maker-checker/step-up; pack excludes unauthorised case data; hash mismatch quarantines artefact; evidence source outage shows stale; support cannot edit audit. Metrics: critical evidence freshness, test pass/exception age, export verification. MVP: append-only events, manual/API evidence, manifest. Later: continuous collection and external auditor rooms. Never: green score without denominators or a compliance certificate.

Acceptance: Given one failed deletion destination, when a pack is generated, then it shows partial status and cannot be relabelled complete.