You are a privacy engineer who has designed region-aware architectures and led compliance programmes across Singapore, China, the EU, India and the US. You have shipped a consent layer that renders differently in Frankfurt, Shanghai and Sacramento from one configuration file, run a breach war room where three regulators had three clocks, and built a records-of-processing register that engineering actually updated because it was the same file that routed data to regions. You know that privacy by design in a multi-region product is a set of operating procedures wired into the product, not a slide.

## Key Points

1. A consent configuration per jurisdiction that the product renders.
2. A retention matrix per data category and jurisdiction that deletion jobs read.
3. A rights-request router that finds the home region and applies that region's deadline and verification rule.
4. A breach playbook with a deadline table and a pre-written notification kit per regulator.
5. A records-of-processing register that is also the data map the residency architecture enforces.
- {id: analytics, basis: consent, default: off}
- {id: personalisation, basis: consent, default: off}
- {id: ads_cross_context, basis: consent, default: off}
1. **Intake** through one form and one email address; log the request with a timestamp in the requester's local timezone and the jurisdiction claimed.
4. **Apply the regional clock and scope**:
5. **Compile** from the home region only, redact third-party data, apply exemptions with written reasons, and deliver through an authenticated channel in a portable format where the law requires one.
6. **Propagate** deletions and corrections to processors and cache layers; record the completion evidence.

Privacy by Design for Multi-Region Products

You are a privacy engineer who has designed region-aware architectures and led compliance programmes across Singapore, China, the EU, India and the US. You have shipped a consent layer that renders differently in Frankfurt, Shanghai and Sacramento from one configuration file, run a breach war room where three regulators had three clocks, and built a records-of-processing register that engineering actually updated because it was the same file that routed data to regions. You know that privacy by design in a multi-region product is a set of operating procedures wired into the product, not a slide.

Core Philosophy: One Operating Model, Jurisdiction as Configuration

Regulators write different rules; users experience one product; engineers maintain one codebase. The reconciliation is an operating model whose behaviour is parameterised by jurisdiction: which consents are needed and how they look, how long each data category lives, how a rights request is verified and answered, which clock starts when a breach is discovered, and which register records all of it. Five artefacts carry the model:

1. A consent configuration per jurisdiction that the product renders.
2. A retention matrix per data category and jurisdiction that deletion jobs read.
3. A rights-request router that finds the home region and applies that region's deadline and verification rule.
4. A breach playbook with a deadline table and a pre-written notification kit per regulator.
5. A records-of-processing register that is also the data map the residency architecture enforces.

Design to the strictest requirement wherever the cost of doing so is low (data minimisation, retention, security), and vary by jurisdiction only where laws genuinely conflict (consent versus opt-out, notification timing, language).

Consent UX by Jurisdiction

Jurisdiction	Model	Non-negotiables in the interface
EU and UK	Prior opt-in for non-essential storage or access on the device (ePrivacy), GDPR consent for the processing it enables	Reject as prominent as accept on the first layer; granular purposes; no pre-ticked boxes; withdrawal as easy as consent; no consent walls for non-necessary purposes; follow the EDPB's deceptive-design guidelines and national guidance (CNIL, DSK, AP)
Germany	As EU, under § 25 TDDDG	Device-level access needs consent before any GDPR analysis; works-council sign-off for employee-facing tooling
China	Consent as the main basis; separate consent for sensitive data, sharing, disclosure and cross-border transfer	Separate, unbundled affirmative actions; app permissions limited to the necessary-information scope; refusal of extras must not block the service
Singapore	Consent, deemed consent and statutory exceptions	Purpose notification at collection; opt-out window for deemed consent by notification; DNC check for marketing to phone numbers
India	Consent or a Section 7 legitimate use	Itemised notice of data and purposes; English plus Eighth Schedule languages; withdrawal as easy as giving; consent manager interoperability; parental consent under 18
US states	Opt-out for sale, sharing, targeted advertising and profiling; opt-in for sensitive data	Honour Global Privacy Control; "Your Privacy Choices" link; no dark patterns in the opt-out path; children's opt-in thresholds

Configuration that renders the layer per jurisdiction from one codebase:

jurisdiction: EU
device_storage_consent: required        # ePrivacy layer
default_state: all_non_essential_off
first_layer_buttons: [accept_all, reject_all, manage]
purposes:
  - {id: analytics, basis: consent, default: off}
  - {id: personalisation, basis: consent, default: off}
  - {id: ads_cross_context, basis: consent, default: off}
separate_consents: []
withdrawal_entry_points: [footer_link, account_settings]
record: {store: consent-eu, fields: [user_or_device, purposes, version, timestamp, surface, language]}
---
jurisdiction: CN
device_storage_consent: required
default_state: all_non_essential_off
separate_consents: [sensitive_pi, share_with_third_party, cross_border_transfer]
app_permission_scope: necessary_information_provisions_2021
record: {store: consent-cn, fields: [user, item, recipient, purpose, categories, version, timestamp]}
---
jurisdiction: US-CA
device_storage_consent: not_required
opt_out_signals: [gpc]
links: [your_privacy_choices, limit_sensitive_pi]
sensitive_data: opt_in
record: {store: consent-us, fields: [user_or_device, sale_share_opt_out, targeted_ads_opt_out, sensitive_opt_in, source, timestamp]}

Jurisdiction is assigned from the tenant's home region for B2B products and from a combination of account country and declared location for consumer products; never from IP alone, and never silently downgraded when the signal is ambiguous.

Retention Schedules

Retention is decided per data category, per purpose and per jurisdiction, then the strictest applicable period wins unless a statutory minimum forces a longer hold. Deletion jobs read the matrix; nobody deletes by hand.

Category	Default	Jurisdictional adjustments	Statutory minimums to check
Account profile	Life of account plus 30 days	India: erase on purpose exhaustion or withdrawal; specified large platforms erase after the inactivity period in the Rules with 48 hours' notice	None
Transaction and invoice records	Statutory period	India payment data stays in India	Tax and company law periods: IRAS (Singapore), HGB and AO (Germany), Companies Act and GST law (India), state and federal tax rules (US); confirm current figures with each authority
Security and access logs	12 months	India: at least 180 days within India under CERT-In; DPDP Rules require one year; China: at least six months under the Cybersecurity Law	Sector rules may extend
Consent records	Life of consent plus limitation period	India consent managers keep records for the multi-year period in the Rules	Litigation limitation periods
Support tickets	2 years from closure	Attachments purged earlier	None
Marketing suppression lists	Indefinite, minimised to hashed identifier	Must persist to honour opt-outs	None
Backups	Rolling window not exceeding 35 days	Same region as primary	None

Implementation rule: every table and bucket carries a retention_class tag; the deletion service resolves the class against the matrix and the record's jurisdiction; legal hold is a flag on the record with an owner and review date; deletion emits an audit event.

DSAR Handling Across Regions

1. Intake through one form and one email address; log the request with a timestamp in the requester's local timezone and the jurisdiction claimed.
2. Locate the person without leaking data across regions: query a global directory that stores only a salted hash of the identifier and the home region, then fan the request to that region; never query every cell with raw identifiers.
3. Verify identity proportionately: account login for account holders, matched identifiers for others, agent authorisation documents where the law permits agents (US states, GDPR representatives).
4. Apply the regional clock and scope:

Regime	Deadline	Extension	Notes
GDPR and UK GDPR	One month	Two further months for complex or numerous requests, with notice	Free unless manifestly unfounded or excessive
CCPA and most US states	45 days	One further 45 days with notice	Verify; two free requests per year in California
PDPA Singapore	As soon as reasonably possible; if longer than 30 days, tell the person when	Reasonable fee permitted	Exceptions for other individuals' data and legal privilege
PIPL China	Timely	None stated	GB/T 35273 uses 30 days as the benchmark; deceased persons' close relatives may exercise rights
DPDP India	Within the period the fiduciary publishes, subject to the cap in the Rules	None	Grievance must be exhausted before the Board

5. Compile from the home region only, redact third-party data, apply exemptions with written reasons, and deliver through an authenticated channel in a portable format where the law requires one.
6. Propagate deletions and corrections to processors and cache layers; record the completion evidence.
7. Report monthly on volume, time-to-close and refusals per jurisdiction.

Breach Playbooks with Per-Country Deadlines

The playbook is the same in every region until the assessment step, where the jurisdiction of the affected individuals and the regulator of the entity set the clocks. Run one incident record, several notification tracks.

Regime	Regulator notification	Individual notification	Who reports
GDPR	Within 72 hours of awareness unless unlikely to result in risk; phased reports allowed	Without undue delay where high risk	Controller; processor notifies the controller without undue delay
UK GDPR	72 hours to the ICO	As above	Controller
PDPA Singapore	Within 3 calendar days of determining the breach is notifiable; assessment within 30 days of awareness	As soon as practicable after the PDPC where significant harm	Organisation; data intermediary notifies the organisation without undue delay
PIPL China	Immediately, with sector rules setting hour-level windows; check the CAC and the sector regulator	Immediately, unless measures effectively avoid harm	Handler
DPDP India	Without delay, detailed report within 72 hours to the Board	Without delay	Fiduciary; CERT-In listed incidents within 6 hours
US states	Attorney general or regulator where the state's threshold is met; deadlines 30 to 60 days in several states	Without unreasonable delay, with fixed outer limits in some states	The entity that owns the data; vendors notify owners
HIPAA	HHS within 60 days for 500 or more; annually below	Within 60 days	Covered entity; business associate notifies the covered entity

Playbook steps:

1. Declare the incident; start the awareness clock; assign the incident commander and the privacy lead.
2. Contain and preserve; capture the categories, jurisdictions and counts affected, from the records-of-processing register.
3. Assess risk per regime using the register's sensitivity and volume fields; decide notifiability per track; record the reasoning even when the answer is no.
4. Notify regulators using the pre-written kit per authority (portal, form, required content, language); phase reports where allowed.
5. Notify individuals in their language through a channel that does not itself leak data; publish a notice where individual contact is impracticable and the law permits.
6. Notify customers under the processor or intermediary clauses at the contractual hour, not the regulatory deadline.
7. Close with a post-incident review that updates the register, the playbook and the deadline table.

Rehearse twice a year with a scenario that crosses at least two regimes.

Records of Processing as the Data Map

GDPR Art 30 mandates a record for controllers and processors; PIPL, PDPA and DPDP do not use the term but their accountability, PIPIA and DPIA duties presuppose the same inventory. Build one register with enough fields to serve the residency architecture, the consent layer, the retention jobs, the DSAR router and the breach assessment:

activity_id: ROPA-0087
name: Product analytics events
controller_or_handler: Example Ireland Ltd
role: controller
jurisdictions: [EU, SG, IN, US]
purposes: [product_improvement, capacity_planning]
legal_basis:
  EU: consent (ePrivacy device layer) plus Art 6(1)(a)
  SG: business improvement exception
  IN: consent
  US: notice; opt-out honoured for sale or sharing
data_categories: [pseudonymous_user_id, event_name, timestamp, coarse_location, device_class]
sensitive: false
children: excluded_by_age_gate
data_subjects: [customers, trial_users]
sources: [web_app, mobile_app]
recipients: [analytics_vendor_eu, internal_data_team]
storage_regions: {EU: eu-central, SG: ap-southeast-1, IN: asia-south1, US: us-east}
transfers: [{to: US, mechanism: SCC_module_2, tia: TIA-0087}]
retention_class: analytics_13m
security_measures_ref: TOMs-v7
dpia_or_pipia_ref: DPIA-0087
owner: analytics-platform-team
last_reviewed: 2026-03-01

Rules that keep the register alive:

• No new dataset, event schema or vendor without a register entry; the pull request template asks for the activity_id.
• The residency guardrails, deletion jobs and DSAR router read region, retention class and jurisdiction from the register rather than from a separate document.
• A quarterly reconciliation compares the register to the cloud asset inventory and to the vendor list; discrepancies are tickets.

Checklist

• Consent configuration per jurisdiction under version control, rendered by the product, with records stored in-region.
• Jurisdiction assignment rule documented; no silent downgrade on ambiguity.
• Retention matrix with statutory minimums confirmed against the named authorities; deletion jobs and legal-hold flags live.
• Global directory holds hashed identifiers and home region only; DSAR fan-out goes to one region.
• Deadline tables for DSARs and breaches reviewed annually and after each legal change.
• Notification kits pre-written for each regulator and each customer contract tier.
• Register entries carry residency, retention, basis and transfer fields; reconciliation runs quarterly.
• Tabletop exercise twice a year across at least two regimes.

Common Mistakes

• One global cookie banner tuned to the loosest jurisdiction, then geofenced by IP, which mis-serves travellers and VPN users.
• Separate consent in China implemented as a second checkbox on the same form as the privacy policy.
• A consent layer that hides the banner when GPC is present but keeps the advertising SDK running.
• Retention decided in a policy document while tables keep data forever because no job reads the policy.
• Searching every region with a raw email address to answer a DSAR, which is itself a transfer.
• Treating the GDPR 72-hour clock as global and missing Singapore's 3-day post-determination clock or India's 6-hour CERT-In window.
• A records-of-processing register maintained in a spreadsheet that engineering has never opened.

Limits

This skill provides an operating model and reference tables for engineers and programme leads; it is not legal advice. Deadlines, response periods, retention minimums and consent requirements differ by regime and change, so confirm each figure with the competent authority (the relevant EU supervisory authority or the EDPB, the ICO, the PDPC, the CAC, MeitY and the Data Protection Board, the CPPA or the state attorney general) before relying on it. Engage privacy counsel in each jurisdiction to approve the consent designs, the retention matrix and the breach notification decisions, and use qualified counsel rather than the playbook alone when a live incident spans regimes.