Docs / security-iso27001.md · mirrored from the repo

Security & ISO/IEC 27001 compliance

Status: guidance, not a certificate. How to make this stack ISO/IEC 27001:2022-ready and what’s already in place. ISO 27001 certifies a management system, not a product — you cannot “install” it. This doc maps our Cloudflare + agentic architecture to the standard and gives a path to certification. Get an accredited auditor for the certificate and legal review for DPDP/GDPR — this is engineering guidance. Companion to ARCHITECTURE.md §5 (auth), INFRASTRUCTURE.md.

1. What ISO 27001 actually requires

Two halves:

1. The ISMS (clauses 4–10) — the management system: define scope + context (4), **leadership
   • policy** (5), risk assessment + treatment planning (6), resources + competence + awareness (7), operational controls (8), monitoring, measurement, internal audit, management review (9), nonconformity + continual improvement (10). This is the part auditors weight most — evidence that you run a security program, not just have controls.
2. Annex A controls (the SoA) — 93 controls in 4 themes (5 Organizational · 6 People · 7 Physical · 8 Technological). You produce a Statement of Applicability justifying each control as applicable/implemented or excluded-with-reason. Controls are risk-driven, not a fixed checklist.

Certification path: Stage 1 (documentation review) → Stage 2 (implementation audit) by an accredited body → certificate → annual surveillance + 3-yearly recertification.

2. Shared responsibility — inherit the cloud

Most Physical (A.7) and platform controls are inherited from providers you build on — you don’t run a datacentre. Collect and file their attestations as evidence, and scope your ISMS to the application layer:

Maintain a supplier register + subprocessor list (A.5.19–A.5.22) and route new vendors through a security/DPA check.

3. Data classification — the spine of the risk model

Classify first; controls follow (A.5.12–A.5.13):

• Public content plane — greetings/devotional assets, catalog, embeddings. Low confidentiality (they’re meant to be shared), but integrity + availability matter.
• PII plane — server-side per-user profiles, taste vectors, phone numbers, engagement/behaviour. This is the sensitive tier. Architecture already isolates it: region-pinned, minimized, retention-bounded (DISTRIBUTION DS-15, CREATIVE-PLANE §14). Privacy-by-design: we log only in-app share-intent and stop at the OS share-sheet (DS-10) — no off-platform tracking.
• Secrets — credentials/tokens. Highest handling tier (§4, A.8.24).
• Operational/audit — RBAC, audit log, config, agent runs.

4. Control mapping — what’s already in place vs gaps

Strong foundations exist from day one; the gaps are mostly ISMS process + formalization, not missing tech.

Agentic-AI-specific controls (don’t skip these)

Autonomous agents acting on data widen the attack/assurance surface:

• Least-privilege service bindings — each agent gets only the D1/R2/KV/queues it needs; no ambient god-token. Review bindings per agent.
• Human-in-the-loop + Control DO gate — autonomy is a policy the Control DO governs; sensitive actions escalate. Every agent action is auditable (runs + steps + audit log).
• Prompt + secret hygiene — prompts in Langfuse (versioned); secrets never in prompts; provider keys BYOK inside AI Gateway, not in code.
• Model-provider data processing — content sent to OpenAI Batch / captioning is a processing activity: DPA, retention, residency documented; keep PII out of prompts where possible.
• Trace data — Langfuse traces can capture content/PII → classify + retention-bound them.
• Supply chain (A.5.21, A.8.28) — pin/scan npm deps; treat MCP servers as privileged integrations (they hold tokens — .mcp.json gitignored); review before adding.

5. Roadmap to certification

1. Scope + context (cl.4) — define the ISMS boundary (product, org, cloud) and interested parties (users, regulators — DPDP Act India, GDPR for EU reach).
2. Asset inventory + classification (A.5.9/5.12) — extend §3 into a living register.
3. Risk assessment + treatment plan (cl.6) — threats × assets → treatments; accept/mitigate/ transfer with owners.
4. Statement of Applicability — all 93 controls, applicable/excluded + justification + status.
5. Core policies (A.5.1) — InfoSec, Access Control, Cryptography/Key Mgmt, Supplier, Incident Response, Business Continuity/DR, Secure Development, Data Retention & Privacy, Acceptable Use.
6. Implement + evidence — most tech exists (§4); close the CI/monitoring/backup gaps; start collecting evidence (audit logs, review records, access reviews, DR test results).
7. Operate the ISMS (cl.9) — metrics, internal audit, management review, log/alert review cadence.
8. External audit — Stage 1 (docs) → Stage 2 (implementation) → certificate → surveillance.

6. Near-term hardening (do these regardless of certification)

• Turn on secret scanning (GitHub) + a CI SAST + dependency-audit step; keep the “CI fails on tracked secret files” check.
• Enforce MFA on GitHub, Cloudflare, Google, OpenAI, Langfuse accounts; document account access.
• Write and test a D1 + R2 backup/restore procedure (export cadence + a restore drill).
• Add retention + deletion jobs for the PII plane and Langfuse traces (DPDP/GDPR data-subject rights).
• Stand up centralized log retention + alerting (audit log, AI Gateway logs, Worker logs) with a defined retention window.
• Keep a vendor/subprocessor register with DPAs; add a lightweight vendor-review gate.
• Quarterly access review of RBAC roles + CF Access policies + API-token scopes; rotate tokens.

7. Decisions / notes