Skip to main content

CC3.1 — Specifies suitable objectives and identifies risks to those objectives

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 specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. The control covers the documented business + technical objectives, the linked risk-identification process, the analysis of those risks (likelihood, impact, owner), and the loop back into mitigation planning.

How ZeroAuth meets this control​

Objectives are documented at three altitudes. The product-level objective ("zero-knowledge identity verification layer for India's regulated industries — BFSI, healthcare, government") is stated in CLAUDE.md and elaborated in docs/plan/bfsi-v1/00-README.md (phase map) and docs/plan/bfsi-v1/01-pain-points.md (the 10 BFSI pain points that ZeroAuth solves). The phase-level objective is the Phase 0 exit gate (close 21 audit findings) and the Phase 1 exit gate (Anchor Bank demo runs end-to-end without intervention). The ticket-level objective is the Done-when + Verify pair on each agent ticket in docs/plan/bfsi-v1/agents/.

Risk identification is structured around two complementary catalogues. docs/threat_model.md is the technical-risk catalogue — every A-NN row carries a class (STRIDE), a surface, a description, a mitigation, a test status, and an audit-signal status. It is required reading for the security-reviewer and cryptographer-reviewer sub-agents at session start. The opening note instructs every contributor to extend the document on each new endpoint, new secret-or-PII dependency, new circuit change, or new audit-log write path. The threat model has been updated in commit 573ff5d ("track audit findings and update threat model for Phase 0 closures") as the Phase 0 findings closed — demonstrating the maintenance rhythm.

The compliance-risk catalogue lives at docs/compliance/compliance-roadmap-v1.md §7. Eight named risks (R-COMP-01 through R-COMP-08) each carry a class (regulatory shift, vendor-selection slip, cross-line schedule dependency, customer dependency, regulator decision, technical/security, vendor-side disruption, regulatory shift), a likelihood, an impact, an owner, and a mitigation plan. R-COMP-01 (DPDP rules notification mid-evidence-period) has the weekly-Friday-check mitigation; R-COMP-02 (evidence collector tool not finalised) has a hard week-10 deadline; R-COMP-03 (trusted-setup ceremony slip) has a 26-week-of-contingency mitigation; R-COMP-06 (smart-contract audit Critical finding) has a 4-week remediation buffer; the others each have explicit named mitigations.

The closed-loop process is captured in 06-ways-of-working.md "Documentation hygiene": every PR is responsible for updating docs/threat_model.md (new attack vector mitigated or identified) and docs/security/audit-findings.md (finding closed with closing commit hash). The compliance roadmap §8.4 mandates the quarterly update cadence on the roadmap itself.

Risk assessment is owned but not single-pointed. Each A-NN threat-model row has an implicit mitigation owner via the path-to-role map in 06-ways-of-working.md "Sub-agent rules" — A-01 (cross-tenant data read) sits with Role 7 (tenancy), A-02 (replayed proof) with Roles 6 + 11, A-14 + A-22 (audit-chain attacks) with Role 8, etc. Each R-COMP-NN compliance risk has an explicit named owner. The dual coverage means a risk falls into a control-failure-blame-game gap only if both layers fail simultaneously.

The Phase 0 demonstration of the loop: 21 findings identified in the readiness audit, 5 P0 + 5 P1/P2/P3 closed in 2 weeks, status published in docs/security/audit-findings.md with closing commit hash per finding, threat-model rows extended (A-27, A-28 added in commit 573ff5d for the demo-bypass + access-token-query findings).

Evidence references​

  • docs/threat_model.md — technical-risk catalogue with A-NN entries, class, surface, mitigation, test status, audit-signal status per row.
  • docs/compliance/compliance-roadmap-v1.md §7 — 8 named compliance risks with class + likelihood + impact + owner + mitigation.
  • docs/security/audit-findings.md — 21 Phase 0 findings with status + closing commit (5 P0 closed, demonstrating the loop).
  • docs/plan/bfsi-v1/01-pain-points.md — 10 BFSI pain points = business-level objectives.
  • docs/plan/bfsi-v1/00-README.md — phase map + 10 standing constraints.
  • Commit 573ff5d — threat model + audit findings updated as findings closed.
  • Commit 5e3b79d — plan tree (objectives encoded) landed.
  • docs/plan/bfsi-v1/06-ways-of-working.md "Documentation hygiene" — closed-loop rule.

Open gaps + remediation roadmap​

  • Enterprise-wide risk register — docs/team/risk-register.md is referenced in compliance-roadmap-v1.md §7 as the future authoritative copy. Target Phase 1 week 8 (2026-07-20), owner Agent #40 (risk lead). Until then §7 is the authoritative compliance-risk source.
  • Quarterly risk-register review — the 15th-of-the-month review with Role 40 lands in the cadence (per 06-ways-of-working.md). First formal review 2026-06-15 (week 4).
  • Threat-model linkage to test suite — test-from-threat-model skill is named in docs/threat_model.md opening note as "to be installed". Target week 14 (2026-08-24).

Test or audit query​

grep -E "^### A-[0-9]" docs/threat_model.md | wc -l should return ≥ 22 (the Phase 0 starting set of A-NN entries). grep "owner" docs/compliance/compliance-roadmap-v1.md | grep "R-COMP-" returns 8 named owners for the 8 R-COMP risks. Cross-check the count against docs/security/audit-findings.md open-rows + threat-model-row count.