Skip to main content

CC3.3 — Identifies changes that could significantly impact internal control

Status: Implemented Owner: Agent #38 (Senior Compliance Lead, SOC 2 + ISO 27001) Last reviewed: 2026-05-28 Next review: 2026-08-28

Trust Services Criteria reference​

The entity identifies and assesses changes that could significantly impact the system of internal control. The control covers monitoring of external regulatory changes, internal organisational changes, business-model changes, technology changes, and the linkage of those into the risk assessment + control activities loop.

How ZeroAuth meets this control​

Change identification is partitioned along four axes — regulatory, technical, organisational, vendor — and each has a named monitoring channel.

Regulatory change is owned by Agent #37 (DPDP + RBI lead) and Agent #36 (CCO). The compliance roadmap §7.1 R-COMP-01 mandates a weekly check of DPB / MeitY rule-notification feeds, with the output landing in the Friday status post. The same risk row pre-negotiates a "re-attestation clause" in the SOC 2 + ISO engagement letters so a mid-period regulatory shift can be absorbed without an audit re-do. R-COMP-08 (cross-border-transfer rule tightened under DPDP §13) has a documented swap-out plan in docs/compliance/dpdp/cross-border-fallbacks.md (to be written week 8, per compliance roadmap §7.8).

Technical change is mediated by the ADR process under /adr/. Any architectural change of consequence requires a written decision record before the implementing commit merges — see 06-ways-of-working.md "Documentation hygiene". The current ADR count is 17 (0000-grandfather-initial-deps.md through 0016-zod-input-validation.md landed 2026-05-26). For circuit + verifier changes specifically, ADR 0015 (commit 27ed93c) pins the circuit version and mandates an ADR + trusted-setup ceremony + verifier redeploy for any version bump. The boot-time vkey hash check (src/services/zkp.ts, commit e98d158) is the technical-enforcement layer — a verifier with a mismatched vkey refuses to start.

Plan-mode trigger is the impact-radar for changes that touch 5+ files OR any of: src/services/zkp.ts, src/services/identity.ts, src/services/api-keys.ts, src/services/audit.ts, src/middleware/tenant-auth.ts, src/routes/v1/zkp.ts, src/routes/v1/identity.ts, circuits/**, contracts/**, mobile/prover/**, mobile/keystore/**. These paths are the load-bearing surfaces; a change to any of them gets explicit plan-mode review and (per the sub-agent rules in 06-ways-of-working.md) security-reviewer + cryptographer-reviewer mandatory approval.

Organisational change is monitored via the monthly cadence in 06-ways-of-working.md: the 1st-of-month phase progress review (Role 1 + Role 28 + Role 36 + Role 42) flags scope-of-control shifts; the 15th-of-month risk-register review (Role 40) updates the enterprise risk picture; the last-Friday cost / spend review (Role 50) catches headcount + vendor cost drift. Phase exit gates are the formal organisational checkpoints (Phase 0 → 4).

Vendor change is named in compliance-roadmap-v1.md §6 — eight external vendor / counsel relationships each with a SoW, deliverables, cost envelope, owner, and conflict-of-interest check. The quarterly vendor review (compliance roadmap D-Q2-13, D-Q3-16, D-Q4-07) is the formal moment for vendor-change capture. R-COMP-07 (auditor key-personnel change mid-engagement) is the named risk; the mitigation is the named-lead-auditor clause + quarterly relationship calls.

The change-control hand-off into the SOC 2 + ISO scope is governed by the "change-in-scope memo" mechanism in compliance-roadmap-v1.md §3.4 (mainnet contract deployment week 46) — the auditor receives a memo and re-confirms scope. The same pattern handles the HSM signer migration (week 48) and the Hyderabad DR failover (week 47).

The Phase 0 demonstration: the closure of audit finding C-1 (demo bypass, commit 02e1734) involved touching src/services/proof-pairing.ts — a load-bearing surface — and required (a) the ADR-or-equivalent trail in 04-commits.md, (b) security-reviewer and cryptographer-reviewer sub-agent approval, (c) the closing-commit row in docs/security/audit-findings.md, and (d) the threat-model row A-27 update in commit 573ff5d.

Evidence references​

  • /adr/ directory — 17 ADRs (0000–0016), each a captured technical-change decision.
  • docs/plan/bfsi-v1/06-ways-of-working.md "Plan mode" — the impact-radar trigger list.
  • docs/plan/bfsi-v1/06-ways-of-working.md "Sub-agent rules" — path-to-reviewer authority map.
  • docs/plan/bfsi-v1/06-ways-of-working.md "Documentation hygiene" — closed-loop rule for threat model + audit findings.
  • ADR 0015-circuit-version-pinning.md (commit 27ed93c) — formal upgrade procedure for the circuit.
  • Commit e98d158 — boot-time vkey hash check, technical-enforcement of ADR 0015.
  • Commit 573ff5d — threat-model update on Phase 0 closure (closed-loop demonstration).
  • docs/compliance/compliance-roadmap-v1.md §7.1 (R-COMP-01), §7.8 (R-COMP-08) — named regulatory-change monitoring.
  • docs/compliance/compliance-roadmap-v1.md §6 — vendor-change calendar.
  • docs/compliance/compliance-roadmap-v1.md §3.4 — change-in-scope memo mechanism.

Open gaps + remediation roadmap​

  • docs/compliance/dpdp/cross-border-fallbacks.md — referenced in compliance-roadmap-v1.md §7.8 R-COMP-08 mitigation; not yet seeded. Target week 8 (2026-07-20).
  • Quarterly internal change-management walkthrough — first cycle target week 14 (2026-08-24), captures the quarter's ADRs + sub-agent reviews into a board-ready summary.
  • Automated alert when CLAUDE.md / 06-ways-of-working.md is modified — to flag changes to the control framework itself. Target Phase 1 sprint 2.

Test or audit query​

ls /adr/*.md | wc -l returns ≥ 17 (Phase 0 ADR count). git log --oneline -- adr/ should show a steady cadence of ADRs landing. git log --grep="ADR " --oneline cross-references commits with ADR references.