Information Security Policy

Satisfies ISO/IEC 27001:2022 clause 5.2 (policy). This is the top-level policy statement the rest of the Tier 1 policy set (POL-01 through POL-12, see PLAN.md §4) sits under. Where this document references a control, the underlying fact is cited to register/facts.md; this document does not introduce new claims beyond it.

1. Policy statement

Stratify handles real personal data and financial-signal data for real subscribers, on production infrastructure that is live today. Management — in practice, the ISMS Owner, who is also the sole engineer — commits to protecting the confidentiality, integrity, and availability of that data, and to meeting Stratify's obligations under GDPR, revDSG, and the regulatory regime it is building toward (FIDLEG today, FINIG/FMA Liechtenstein VVG at Phase C).

This commitment is not aspirational language sitting above an empty technical layer. Three mechanisms already enforce it in production, independent of this document:

• A required CI check (verify in dos-ci.yml) gates every change with lint, typecheck,

automated tests, and a gitleaks secret scan before it can reach main — security-relevant regressions are structurally harder to ship than to catch.

• Row-Level Security is enforced at the database layer on 23+ tables, with explicit

deny-by-default policies (no SELECT policy at all) on the two most sensitive tables, audit_log and signal_deliveries — access control that survives an application-layer bug, not just a convention followed in code review.

• The audit log is append-only at the database layer, not by application discipline: a

Postgres trigger raises on any UPDATE/DELETE attempt against audit_log, and every entry is SHA-256 chain-hashed so tampering is detectable even if the trigger were somehow bypassed.

Naming these here is deliberate: a policy that only states intent, with no evidence that intent survives contact with the codebase, is not worth the document. These three are real, already-operating enforcement mechanisms this policy stands on, not controls this policy is promising to eventually build.

2. Objectives

This policy exists to:

1. Protect subscriber and partner data — personal data (subscriber profiles, onboarding

fields), authentication credentials, and B2B partner API keys/webhook secrets — from unauthorized access, disclosure, or loss.

1. Maintain the integrity of the audit log, which is the evidentiary backbone Stratify relies

on to demonstrate to partners, investors, and eventually a regulator that signal publication, corrections, admin actions, and data-subject-rights fulfilment happened as claimed.

1. Meet GDPR and revDSG obligations for the EEA and Swiss subscriber base this product

serves, including lawful basis, data-subject rights, and breach notification timelines.

1. Prepare for FMA Liechtenstein licensing requirements ahead of Phase C, so that the security

posture required for MiFID-II-equivalent conduct is a natural extension of what already exists, not a scramble triggered by the license application.

1. Give an honest, current account of security posture to anyone who relies on it — a

subscriber, a partner integrating against the API, or an investor doing diligence — rather than a certification-shaped document detached from what the running system actually does.

3. Scope

This policy applies to the ISMS scope defined in GOV-01: the stratify web app, mobile app, B2B API, and the Hetzner-hosted infrastructure behind them. It does not extend to the wait, what. Advisory entity's other ventures.

4. Roles

Detailed in GOV-03. In summary: the ISMS Owner (Toby) is accountable for this policy and for the technical control surface it governs; the DPO / Privacy Owner (Antonios) is accountable for the privacy-specific obligations (GDPR/revDSG) this policy references. Both roles are currently held by co-founders who are also the only two people with any ISMS responsibility at Stratify.

5. Policy review cadence

This policy is reviewed annually, or immediately following any material infrastructure change — a change to hosting, the identity/auth provider, the database platform, or a sub-processor handling personal data at scale.

The Vercel → Hetzner cutover on 2026-06-03 is the concrete example of exactly this kind of material change, and it is worth stating plainly that it did not trigger a compliance-document review at the time: dsgvo-data-flow.md, pentest-rfp.md, and several other documents still describe the pre-cutover architecture months later (register/facts.md, tracked as RISK-001). This is precisely why GOV-13 (Nonconformity & Corrective Action Log) exists as a standing governance document rather than an afterthought — a documented process for catching this class of drift the next time a material change happens, instead of relying on someone remembering to update every downstream document by hand.

6. Enforcement and exceptions

Enforcement today is structural where possible (the CI gate, RLS, the audit-log trigger) rather than procedural, because a procedural control that depends on a second reviewer does not exist yet at Stratify's current team size (see GOV-03 §4 on the segregation-of-duties gap). Where a control in this policy's supporting Tier 1/2 documents cannot yet be met — because the team is one engineer, because a scanning tool isn't wired up, because a pentest hasn't been sent — the honest status is recorded in register/controls.yaml (not_started / partial) rather than claimed as met. Exceptions to stated policy require the ISMS Owner's documented rationale; there is no committee to route them through at this stage.

7. Related documents

• GOV-01 — ISMS Scope & Context
• GOV-03 — Roles, Responsibilities & Authorities
• GOV-06 — Statement of Applicability
• GOV-13 — Nonconformity & Corrective Action Log (pending)
• docs/compliance/dsgvo-data-flow.md — the operative GDPR/revDSG data-flow document this policy

defers to for privacy specifics