# DPDPA Zero Trust Architecture — Implementation Checklist Six-week phased rollout. Each phase has acceptance gates; do not advance until gates pass. --- ## Phase 1 — Foundation (Weeks 1–2) ### 1.1 Personal Data Inventory - [ ] Enumerate all datastores containing personal data (databases, object storage, message queues, logs) - [ ] Map data flows: which services read, write, or transmit personal data - [ ] Classify each asset: personal data / pseudonymous / anonymised / non-personal - [ ] Identify Significant Data Fiduciary triggers (volume, risk profile) **Acceptance Gate:** Data flow diagram approved by DPO; all personal-data systems tagged in CMDB. ### 1.2 IAM Baseline Audit - [ ] Export all IAM role bindings for personal-data systems - [ ] Identify over-provisioned accounts (roles granting more than least privilege) - [ ] Flag service accounts with persistent production-database access - [ ] Document the target least-privilege state for each principal-resource pair **Acceptance Gate:** Over-provisioned account report reviewed; remediation backlog created and prioritised. --- ## Phase 2 — Identity Pillar (Weeks 2–3) _DPDPA: Rule 6(1)(b) — control of access to computer resources (implemented as least privilege)_ - [ ] Deploy OPA server with `policies/dpdpa_least_privilege.rego` - [ ] Wire OPA as an external authorisation point for personal-data APIs (envoy ext-authz or sidecar) - [ ] Populate `data.permissions` store: map each service account to exact required actions - [ ] Implement JIT access for human access to production databases (Vault, AWS Identity Center, or equivalent) - [ ] Enforce MFA for all privileged sessions accessing personal data - [ ] Verify deny-by-default: confirm that a net-new service account is denied access until explicitly provisioned **Acceptance Gate:** - OPA policy deployed and reachable by all personal-data services - Access denied for unprovisioned test identity (automated smoke test passes) - JIT flow exercised end-to-end for at least one production-database operation --- ## Phase 3 — Network and Device Pillars (Weeks 3–4) _DPDPA: Rule 6(1)(b) — access control at network and device layer; Rule 6(1)(d) — continued processing_ - [ ] Segment personal-data systems into dedicated network zone (`personal_data_zone`) - [ ] Deploy `policies/dpdpa_network_policy.rego` as network policy decision point - [ ] Block all unapproved cross-zone flows; create explicit allow rules only for approved services - [ ] Enable device posture evaluation: EDR compliance, patch level, disk encryption - [ ] Configure per-session re-authorisation: sessions to personal-data zone do not persist beyond approved duration - [ ] Deploy certificate-based mutual TLS for all intra-zone service communication **Acceptance Gate:** - Network segmentation verified: unapproved source cannot reach `personal_data_zone` (network probe test) - Device posture fail-close tested: a non-compliant device is denied access - mTLS handshake verified between all personal-data services (certificate validation log) --- ## Phase 4 — Data Pillar (Weeks 4–5) _DPDPA: Rule 6(1)(a) — encryption, obfuscation, masking, virtual tokens_ - [ ] Verify AES-256-GCM encryption at rest on all personal-data stores - [ ] Enforce TLS 1.3 minimum on all service-to-service calls in the personal-data segment - [ ] Verify encryption key separation: KMS-managed keys distinct from the data store - [ ] Implement pseudonymisation for analytics pipelines: replace direct identifiers with reversible tokens - [ ] Store token-to-identity mapping in access-controlled vault separate from analytics store - [ ] Run encryption coverage report: confirm no personal-data field is stored in plaintext **Acceptance Gate:** - Encryption-at-rest confirmed for all classified personal-data stores (scan report) - TLS 1.3 verified on internal service mesh (cipher suite audit) - Pseudonymisation end-to-end tested: analytics query returns tokenised identifiers; reversal requires vault access --- ## Phase 5 — Visibility (Weeks 5–6) _DPDPA: Rule 6(1)(c) — logs, monitoring and review; Rule 6(1)(e) — one-year retention; Rule 6(1)(g) — effective observance_ - [ ] Deploy `src/zt_audit_logger.py` (or equivalent) at every personal-data system entry point - [ ] Confirm audit events capture: principal, resource, action, outcome, device_id, session_id, timestamp, integrity_hash - [ ] Route audit events to centralised SIEM - [ ] Configure SIEM alert: any `deny` outcome for personal-data access within 15 minutes - [ ] Configure SIEM alert: access from non-compliant device to personal-data zone - [ ] Set log retention policy: minimum 1 year for security logs (Rule 6(1)(e)) and for personal data, traffic data and processing logs (Rule 8(3)); apply any longer sectoral requirement, naming the law - [ ] Schedule quarterly control-effectiveness reviews (Rule 6(1)(g)) - [ ] Schedule annual penetration test against ZTA boundary **Acceptance Gate:** - Audit event emitted and received in SIEM for at least one allow and one deny access event - Integrity hash verified: stored event hash matches re-computed hash over canonical fields - SIEM alert fires within 15 minutes of a test deny event - Log retention policy documented and applied --- ## Ongoing | Activity | Frequency | Owner | DPDPA Anchor | |----------|-----------|-------|-------------| | IAM role binding audit | Monthly | Security Eng | Rule 6(1)(b) | | OPA policy change review | Each deployment | Security Arch | Rule 6(1)(b), S.8(5) | | Device posture review | Quarterly | IT/SecOps | Rule 6(1)(b) | | Control effectiveness assessment | Quarterly | CISO | Rule 6(1)(g) | | Penetration test | Annual | Third-party | Rule 6(1)(g), S.8(5) | | Encryption coverage scan | Quarterly | Data Eng | Rule 6(1)(a) | --- ## Breach Intimation Readiness (Rule 7) In parallel with the ZTA rollout: - [ ] Draft Data Principal intimation template (Rule 7(1)(a)–(e): description, likely consequences, mitigation, safety steps, contact person) - [ ] Draft initial Board intimation template (Rule 7(2)(a): nature, extent, timing, location, likely impact) - [ ] Draft 72-hour detailed Board report template (Rule 7(2)(b)(i)–(vi)) - [ ] Designate the person who answers Data Principal queries (Rule 7(1)(e); published contact under Rule 9 / S.8(9)) - [ ] Define internal escalation path: SIEM alert → triage → legal → Board notification - [ ] Test the path end-to-end with a tabletop exercise **Note:** Rule 7 has two clocks. Affected Data Principals (Rule 7(1)) and the Board (Rule 7(2)(a)) get an initial intimation "without delay". The detailed report to the Board is due within 72 hours of becoming aware of the breach, or a longer period the Board allows on a written request (Rule 7(2)(b)). Rule 7 applies from 13 May 2027.