Information Security Framework Policy

This is the top-level policy of the stratify ISMS. It states what the organization commits to on information security, how the rest of the documentation set is structured, and where compliance monitoring and legal/regulatory tracking live. It does not restate technical control detail that belongs in a domain policy (POL-02 through POL-06) or in register/facts.md; it cites those instead.

1. Policy hierarchy

The stratify ISMS documentation set has four tiers, described in PLAN.md §3–§4:

1. **Governance (governance/GOV-*)** — the ISO 27001 clause 4–10 mandatory documents: scope,

this framework's parent commitment, roles, risk methodology, the Statement of Applicability, internal audit, management review, and nonconformity tracking.

1. **Policies (policies/POL-*)** — this tier. Twelve domain policies, each a statement of intent

and commitment against a cluster of Annex A controls, cross-referenced to the register.

1. **Procedures (procedures/PRO-*)** — the operational "how." Where a policy commits to

something, a procedure (once written) says who runs it, how often, and what evidence it leaves behind.

1. **Privacy (privacy/PRIV-*)** — GDPR/revDSG-specific documents, mostly thin ISO-formatted

wrappers around the existing docs/compliance/dsgvo-data-flow.md, which remains the operational source of truth for privacy detail.

This policy sits at the top of tiers 2–4: where a domain policy or procedure appears to conflict with this document, this document's intent governs, and the conflict is logged as a nonconformity (GOV-13) rather than silently resolved.

2. Management commitment

The ISMS Owner (Toby) is the accountable individual for information security at stratify today — a fact of the current single-engineer stage (register/facts.md, "Team / access"), not an aspiration. Management commitment is expressed concretely, not only in this document:

• The required CI check (verify, .github/workflows/dos-ci.yml) gates every merge to main on

lint, typecheck, tests, and a secret scan — a real enforcement mechanism, not a stated intention (Annex A 5.4, 5.8).

• Every elevated write in the admin surface calls recordAudit() (apps/web/lib/audit/chain.ts),

producing a tamper-evident record of privileged action regardless of who performs it.

• Security-relevant architectural decisions are recorded as ADRs (docs/adr/), not made silently —

see §6.

This is a genuine but narrow form of management commitment: it reflects what one accountable engineer enforces through tooling, not a multi-person security function. That gap is named plainly rather than implied away — see GOV-03 for the full roles picture once written.

3. Roles and responsibilities

Full detail lives in GOV-03 (Roles, Responsibilities & Authorities), not duplicated here. The confirmed assignment, per register/facts.md:

• ISMS Owner + Security Officer: Toby. Accountable for the technical control surface. This

matches the sole-committer reality of the codebase (git log shows one human identity across all commits).

• DPO / Privacy Owner: Antonios. Owns the FMA license and DSGVO workstream; already the named

owner of docs/compliance/dsgvo-data-flow.md.

• Philipp (co-founder, Structuring & Sales) is not assigned an ISMS role.

Segregation of duties (Annex A 5.3) is a real, current gap, not a nuance: CODEOWNERS exists in the repo but is fully commented out and routes nothing at Tier 1 (CONTRIBUTING.md, register/controls.yaml 5.3, status not_started). The required review on every PR today is an AI-agent /code-review run in a fresh context, not a second human reviewer. This is documented honestly as an accepted, temporary risk (register/risks.yaml RISK-002) rather than presented as a satisfied control.

4. Legal and regulatory landscape

Two regimes apply today and a third is on the horizon; this policy states that all three are tracked, not that any single document owns the full legal analysis:

• GDPR (EEA subscribers) and revDSG (Swiss controller entity) — the dual-track privacy

regime already substantively documented in docs/compliance/dsgvo-data-flow.md (Antonios, v2.1). This ISMS's privacy tier (PRIV-*) formalises that document rather than re-deriving it.

• FIDLEG / FINIG (Switzerland) and MiFID II / Liechtenstein VVG (EEA) — the regulatory ladder

stratify climbs as its product moves from today's non-personalized, research-publication posture toward personalized advice and eventually discretionary asset management (docs/compliance/regulatory-roadmap-ch-eea.md). Today's posture — Stufe 0 / E0, "Research + Tippgeber," bewilligungsfrei — is a deliberate, operationally maintained boundary (no per-recipient personalization, no discretionary execution), not an accident of not having grown yet. Crossing that boundary (e.g. profile-driven allocation, or discretionary mandates) triggers the next rung of the ladder and must be treated as a change requiring legal review before it ships, not after.

• DORA-equivalent operational-resilience obligations become live once the FMA Liechtenstein

license lands (Phase C) — not yet applicable, tracked as a future trigger in the same roadmap document.

This ISMS does not maintain a separate legal register today; register/controls.yaml control 5.31 (Legal, statutory, regulatory and contractual requirements) is scored partial for exactly this reason — the two regimes are each well-documented individually, but not consolidated into one register spanning both. Consolidating them is a GOV-04-adjacent task, not yet done.

5. Compliance-monitoring approach

Compliance monitoring today is narrow and mostly automated rather than a scheduled review programme (Annex A 5.36, status partial):

• The CI gate enforces secret-scanning and lint/typecheck compliance structurally on every PR —

a policy that can't be silently skipped in the merge path itself (though local --no-verify bypasses the equivalent pre-commit hook, self-documented as such in .pre-commit-config.yaml).

• Beyond that, no scheduled policy-compliance review, internal audit (5.35, not_started), or

management review currently runs. GOV-11 (Internal Audit Programme) and GOV-12 (Management Review) are the governance documents that will close this gap; until they exist and run at least once, this ISMS should not claim an operating monitoring cadence.

• Threat intelligence (5.6, 5.7) is not tracked at all today — no special-interest-group

membership, no CERT relationship, and (concretely) no dependency/vulnerability feed wired into CI. This is the same underlying gap documented in more technical detail under POL-06 (8.8) and register/risks.yaml RISK-003.

• Contact with authorities (5.5) — EDÖB, a cantonal DPA, or a CERT — has no documented procedure.

The closest existing precedent is the P0 audit-chain-corruption runbook's counsel-notification step (docs/runbooks/db-recovery.md §3.3), which names a notification path for one specific scenario but is not a general authority-contact procedure.

6. Documented operating procedures (5.37)

Stratify already has real, substantive documented operating procedures at the engineering level — this control does not start from zero:

• CONTRIBUTING.md is the single source of truth for how the repository is built: branching,

testing, commit conventions, review, merge, and deploy rules, each marked as enforced or advisory.

• docs/adr/ holds Architecture Decision Records for security-relevant choices, e.g. ADR-0001

(adopting the development operating standard) and ADR-0002 (moving web sign-in to email-OTP codes after magic links proved completely broken in production).

What doesn't yet exist is the ISMS-level procedure tier (procedures/PRO-* in this repo) — security-specific operating procedures such as access review, incident response, or backup-restore testing, distinct from the general engineering process CONTRIBUTING.md governs. Control 5.37 is therefore scored partial in register/controls.yaml: real documented procedures exist at the codebase-process layer, not yet at the ISMS-procedure layer.

7. Privacy commitment (5.34)

Stratify's privacy programme is materially ahead of a typical pre-seed baseline and control 5.34 is scored implemented in register/controls.yaml on that basis — a rare unqualified status in this control set. The substance lives in docs/compliance/dsgvo-data-flow.md (controller/processor map, data categories, Art. 6 legal bases, subject-rights table, Art. 32 measures, DPA tracking) and in working code: buildGdprExport() for Art. 15 export and eraseSubscriberData for Art. 17 erasure/anonymization (register/facts.md). This policy does not duplicate that material — the privacy/PRIV-* tier of this ISMS is where it gets formalised with ISO-shaped front matter and Annex A linkage. Two known staleness corrections in dsgvo-data-flow.md (Vercel → Hetzner, Resend → AWS SES) are tracked as a GOV-13 nonconformity candidate, not silently carried forward as current fact by this policy.

8. Control summary

9. Review

This policy is reviewed on the cadence set at approval (review_due in front matter, typically 12 months) and additionally whenever the regulatory ladder in §4 is crossed, whenever GOV-03 role assignments change, or whenever a GOV-13 nonconformity is logged against it.