Skip to content

Soon ISMS — Masterplan & Operating Model

How we (Olaf + Andrea) run this repository to get ISO/IEC 27001:2022 certified (the primary goal) — with the least friction, and in a way that stays maintainable for the long term. A SOC 2 report can follow later, reusing the same controls and evidence.

Operating principle: Claude Code is the main interface. Both Olaf and Andrea prepare, review and maintain every document by talking to Claude Code in this repo. The files are the source of truth; Claude Code is how we work on them; a small script keeps everything honest.

1. The big picture

                ┌──────────────────────────────────────────────┐
                │                 Claude Code                   │
                │      (Olaf + Andrea's single interface)       │
                │                                               │
                │  /isms:draft   /isms:review   /isms:gap       │
                │  /isms:new     /isms:approve  /isms:status     │
                │  /isms:evidence /isms:meeting                 │
                └───────────────┬───────────────┬──────────────┘
                                │ reads/writes  │ runs
                                ▼               ▼
        docs/*.md  (policies, procedures)   tools/isms.py
        each with YAML front-matter         ├─ build → REGISTER.md + STATUS.md
        = the single source of truth        └─ check → validates (gates CI)
                                │
                                ▼
                 GitHub  (version history, PRs, read-only auditor access)
                                │
                                ▼
                 GitHub Actions  → runs isms.py check on every change

Three moving parts, nothing more: 1. Markdown documents with structured front-matter (docs/). 2. Claude Code commands that do the repetitive work consistently (.claude/commands/isms/). 3. One script (tools/isms.py) that generates the register/dashboard and validates — run locally and in CI.

2. Who does what

Olaf (internal, technical) Andrea (external consultant, CyberSquad)
Primary role Owns repo, tooling, evidence from the real app/infra, approvals Drafts/adapts policies, audit structure, SOC 2/pentest sourcing
Works via Claude Code Claude Code
Typical commands /isms:status, /isms:evidence, /isms:approve, /isms:gap /isms:draft, /isms:review, /isms:new
Cannot do alone — Approve documents (owner sign-off is a Soon employee)

Auditor (later): gets read-only access to this repo. Reads README.md → REGISTER.md (what exists) → the Statement of Applicability → individual documents and their evidence:. They never need write access or the app code.

Access rule (agreed): this repo is policies only, kept separate from application code; collaborators/auditor get scoped or read-only access.

3. The daily/weekly workflow

Authoring or updating a document

  1. In Claude Code: /isms:draft A.8.13 (tailors the backup policy to Soon) or /isms:new ISMS-FORM-06-2 "Statement of Applicability" for a new one.
  2. Claude grounds the document in Soon's real context, inserts TODO(owner:) for anything it shouldn't guess, and fills the evidence: list.
  3. /isms:review <doc> — Claude pressure-tests it as an auditor would.
  4. Human answers the TODOs; Olaf gathers evidence (/isms:evidence).
  5. /isms:approve <doc> once the owner signs off → status approved, review date set.

Every Thursday (13:00 CEST standing meeting)

  • Run /isms:meeting. Claude produces the agenda: what moved since last week, the status snapshot, this week's priority documents, proposed Olaf/Andrea split, open decisions (pentest scope, SOC 2 provider), and blockers.
  • Optionally save the note as a dated record (evidence of management oversight).

Anytime

  • /isms:status — where do we stand, what's overdue, what's next.
  • /isms:gap — what's missing for SOC 2 / ISO, prioritised.

4. How a document becomes "real" (the lifecycle)

template ──▶ draft ──▶ in-review ──▶ approved ──▶ (annual review) ──▶ approved …
  • Only approved documents count toward certification.
  • approved requires approved_by, approved_date, and next_review — enforced/encouraged by the tooling.
  • An approved document with claims that can't be evidenced is a finding waiting to happen — hence the evidence: field and /isms:evidence verification.

The status of every document is visible at a glance in STATUS.md and listed in REGISTER.md, both auto-generated — never hand-edited.

Version control: every change lands on main through a branch → PR → review → merge, so main is always the live, authoritative version and the history is fully auditable. A bot keeps the register/dashboard in sync on merge. Full rules in CONTRIBUTING.md → "How updates work".

5. "Check the policies" & "enforce with AI" — what's realistic

You asked for a simple way to check policies and possibly enforce them against the codebase. Here's the honest, working version:

Want How it works here What it is / isn't
Check documents are complete & consistent tools/isms.py check (local + CI) Deterministic. Catches missing fields, bad status, dup IDs, broken links.
Check coverage vs the standard /isms:gap AI reasoning over REGISTER/ROADMAP + the standard. A strong assistant, confirm its output.
Check a policy matches reality (the codebase) /isms:evidence run in the app/infra repo AI verification of drift, with file:line evidence. Not enforcement — a human confirms & fixes.
Keep the register/dashboard current tools/isms.py build (CI fails if stale) Fully automated.

True "enforcement" (blocking a deploy if a control regresses) lives in the application repo's CI, not here — e.g. a check that TLS/MFA/encryption settings match policy. The /isms:evidence workflow is how we connect the two without mixing policy and code in one repo. We can add hard enforcement gates later; start with verification.

6. ISO 27001 first — one document set, optional SOC 2 later

Decision: ISO/IEC 27001 is the primary goal and comes first, certified by an accredited auditor. A SOC 2 report can follow later and reuses ~80% of the same work, so we don't do it twice.

  • Prioritise the ISO management-system spine → Statement of Applicability, risk assessment & treatment, asset inventory, internal audit, management review, objectives, roles — these are what an ISO Stage 1/Stage 2 audit checks first.
  • Then the Annex A controls → tailor the A.5–A.8 policies (already drafted as templates) to Soon, with evidence for each.
  • The pentest (Andrea sourcing in Utrecht) strengthens the technical controls (A.8) and is reusable evidence for a later SOC 2.
  • The same policies satisfy most SOC 2 Trust Services Criteria too. Front-matter carries both iso27001_controls and soc2_criteria; we fill soc2_criteria opportunistically so a SOC 2 later is a short add-on, not a restart.
  • /isms:gap lists what ISO needs next; /isms:gap soc2 when we turn to SOC 2.

See ROADMAP.md for the full phased plan, timeline, and document register.

7. Long-term maintenance (staying certified, not just getting certified)

  • Annual reviews are scheduled per-document via next_review; /isms:status and the dashboard surface what's due. Nothing silently goes stale.
  • Change management: every change is a git commit/PR with history — exactly what auditors want to see. CI validates each change.
  • Recurring ISMS activities (risk review, access review, internal audit, management review) are tracked as their own documents/records and surfaced in the weekly /isms:meeting.
  • Evidence stays linked to the controls it proves, so surveillance audits are a re-run of /isms:gap + /isms:evidence, not a fire drill.
  • Onboarding a new collaborator = give them this repo + tell them to use the /isms:* commands. CONTRIBUTING.md and CLAUDE.md carry the rest.

8. What exists now vs next

In place: repo structure, all templates converted to Markdown with front-matter, authored Context & Scope, the register/dashboard tooling, CI, the Claude Code command set, contributor + AI guides, and the certification roadmap.

Next (and how): 1. /isms:new ISMS-FORM-06-2 "Statement of Applicability" — the #1 missing artefact. 2. /isms:new ISMS-DOC-A05-9-2 "Information Asset Inventory" then drive the risk assessment from it. 3. /isms:draft through the high-priority A.5–A.8 policies (already drafted as templates) to make them Soon-specific. 4. Stand up incident response, access management, internal audit, management review. 5. /isms:evidence against the app/infra repo to start collecting proof. 6. Operate ~3 months, then internal audit + management review → book the audit.

Run /isms:status now to see the live picture.