Skip to main content

CC1.3 — Organisational structure, reporting lines, authorities, and responsibilities

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​

Management, with board oversight, establishes structures, reporting lines, and appropriate authorities and responsibilities in pursuit of objectives. The control covers the documented organisational chart, the assignment of role-level authorities, the segregation-of-duties matrix, and the alignment of authority with accountability.

How ZeroAuth meets this control​

ZeroAuth's organisational structure is published in machine-readable form alongside the production codebase. docs/plan/bfsi-v1/03-team.md enumerates a 50-person target roster.

The roster breakdown:

  • Roles 1–5 — engineering line VPs (CTO, VP backend, VP frontend, VP mobile, VP infra).
  • Roles 6–13 — backend and crypto engineers (verifier, tenancy, audit, admin, plus cryptography roles 11–13).
  • Roles 14–20 — frontend + mobile (dashboard, console, marketing site, Android prover, IoT bridge).
  • Roles 21–24 — DevOps + QA.
  • Roles 25–27 — blockchain + security (contracts, security-reviewer, cryptographer-reviewer).
  • Roles 28–31 — product.
  • Roles 32–35 — design + tech writers.
  • Roles 36–41 — compliance + risk + privacy (CCO, DPDP lead, SOC 2 lead, privacy engineer, risk owner, DPO).
  • Roles 42–49 — sales + GTM (head of partnerships, BD, customer success, marketing).
  • Role 50 — operations.

Every role has a numbered slot, a title, a reporting line, and a KPI block. The agent-tickets directory (docs/plan/bfsi-v1/agents/agent-<NN>-*.md) further turns each role into a daily Mon-Fri ticket list for weeks 1–4 with a 5-field Definition of Done per ticket (Done-when, Output, Verify, Reviewer, Depends-on).

Reporting lines are explicit in every per-agent file. As an example from this control's owner: agents/agent-38-compliance-soc2.md opens with "Reports to: Agent #36." The line VPs report to the CTO (Agent #1). The CCO (Agent #36) reports to Agent #1 alongside the line VPs but has independent escalation authority to the board-equivalent on compliance matters (per 06-ways-of-working.md "Escalation"). The DPO (Agent #41) reports to the CCO but has a statutory independent-judgement carve-out under DPDP §17 — captured in docs/compliance/privacy/data-inventory-v1.md and the §17 filing referenced in compliance-roadmap-v1.md D-Q1-19.

Authority is mapped to repository paths through the sub-agent rules in 06-ways-of-working.md "Sub-agent rules". Touching src/services/audit.ts requires both security-reviewer and cryptographer-reviewer sub-agent approval; touching src/middleware/tenant-auth.ts requires security-reviewer; touching circuits/** requires cryptographer-reviewer; touching contracts/** requires both. The two sub-agents are installed at .claude/agents/security-reviewer.md and .claude/agents/cryptographer-reviewer.md per CLAUDE.md "Subagents available".

The branching workflow (ADR 0011, commit 51bc705) backs the authority-by-path map with technical enforcement: every PR to main requires CI green + sub-agent APPROVE before merge. --no-verify is forbidden. A reviewer that posts REQUEST_CHANGES blocks the merge until addressed, with a 24-hour escalation to Role 1 if ignored.

Segregation of duties is encoded both in role definitions and in technical access controls. The compliance roadmap §6 ("Vendor and counsel calendar") names the agent owner for each external relationship — Agent #37 owns DPDP counsel, Agent #27 owns the external cryptographer, Agent #38 owns the SOC 2 + ISO auditor relationships. No single agent both signs an external engagement and reviews its deliverables; the reviewer is always a separate role. Production deploy access on the VPS at 104.207.143.14 is restricted to the zeroauth-deploy user (CI key) and the founder's laptop key (root) per the threat model surface inventory.

Authority alignment with accountability is reinforced by the commit-trail rule: every commit subject references the pain-point ID it closes (docs/plan/bfsi-v1/01-pain-points.md), and 04-commits.md lists the commit ID against the owning role. This means an auditor can ask "who closed P-4 (insider abuse risk)?" and find Agent #6 + Agent #8 (audit-chain implementation, commits a475ed8 + d634b2d) on a single grep.

Evidence references​

  • docs/plan/bfsi-v1/03-team.md — 50-person roster + KPIs.
  • docs/plan/bfsi-v1/05-agents.md — per-agent week-by-week tickets.
  • docs/plan/bfsi-v1/agents/agent-38-compliance-soc2.md — example role-reports-to declaration.
  • docs/plan/bfsi-v1/06-ways-of-working.md "Sub-agent rules" — authority-by-path mapping.
  • .claude/agents/security-reviewer.md, .claude/agents/cryptographer-reviewer.md — sub-agent definitions referenced from CLAUDE.md.
  • ADR 0011-branching-workflow.md (commit 51bc705) — dev + main only; PR + CI + sub-agent approval gates.
  • docs/threat_model.md "Threat surface inventory" — VPS access pinned to two principals.
  • Commit 5e3b79d — plan tree (org chart + ticket DoD) landed.

Open gaps + remediation roadmap​

  • Quarterly RACI refresh — the 50-role plan is static today; a quarterly review with Agent #1 + #36 to catch drift lands as a recurring item in 06-ways-of-working.md monthly cadence (next refresh 2026-08-28).
  • Hire-vs-AI-agent attribution — the plan does not yet mark which roles are filled by human hires vs. AI agents. Target week 13 (2026-08-17) alongside the DPB §17 filing, since the filing requires named human DPO and processors.

Test or audit query​

ls docs/plan/bfsi-v1/agents/ | wc -l returns at least 50; every agent file opens with a "Reports to:" line. Cross-check with docs/plan/bfsi-v1/03-team.md — role numbers must match exactly.