Supplier & Cloud Security Policy

This policy covers how stratify handles security in its supplier and cloud-infrastructure relationships. The honest summary: the supplier list itself is real and tracked, and one specific review practice already exists for privacy purposes — but nothing in this domain has been formalised as a security policy, and two of the most operationally important suppliers today (Hetzner, AWS SES) are not yet reflected in the document that's supposed to track them.

1. Supplier register (5.19)

register/suppliers.yaml is the living supplier register for this ISMS — 12 seeded entries, covering Supabase (self-hosted), Hetzner, AWS SES, the historical Resend integration (kept for audit-trail continuity, no longer live), Stripe, PostHog, Sentry, the Vercel AI Gateway → Anthropic path, and the three push-notification vendors (APNs, FCM, Expo). It was built directly from register/facts.md's verified sub-processor table, cross-checked against the DPA-tracking practice already in docs/compliance/dsgvo-data-flow.md §10.

Control 5.19 is scored partial: the register exists and is accurate as of its seed date, but there is no systematic supplier-security-review policy beyond it — no standard set of security questions asked before onboarding a new supplier, no documented minimum bar (e.g. SOC 2, ISO 27001 certification, or an equivalent) a new vendor must meet.

2. DPA tracking — real practice, real gaps (5.20)

docs/compliance/dsgvo-data-flow.md §10 already tracks DPA links per processor, and Antonios reviews that table quarterly per the document's own text (register/facts.md). This is a genuine, existing practice — not something this policy is inventing. It is adopted here as the current baseline for control 5.20 (Addressing information security within supplier agreements), which is scored partial on that basis: a review cadence exists for the privacy angle, but there is no standard security-clause template applied when a new supplier is onboarded — DPA tracking today is reactive documentation of what's already in place, not a checklist run before a new integration ships.

Two real, current gaps in that DPA table, both already flagged in register/facts.md and carried into register/risks.yaml as RISK-009:

• Hetzner — now the actual infrastructure host for the entire production stack since the

2026-06-03 cutover — is not yet in `dsgvo-data-flow.md`'s processor table at all (register/suppliers.yaml SUP-002 marks this "URGENT").

• AWS SES (eu-central-1) — now the actual transactional-email vendor, having replaced

Resend — likewise has no confirmed DPA on file in that table; dsgvo-data-flow.md still names Resend.

Both are open items, not resolved by this policy's existence. Closing them means: (a) confirming Hetzner's data-processing terms for the physical/infrastructure hosting role it now plays, (b) confirming AWS's standard DPA under the AWS Customer Agreement covers SES usage as needed, and (c) updating dsgvo-data-flow.md §10 to reflect both. This policy commits to that being done as part of Phase 4 of the ISMS build (PLAN.md §5), not to it already being done.

3. ICT supply-chain security (5.21)

Scored not_started. No process exists for managing information-security risk when a supplier in the ICT supply chain changes — for example, a future change of the underlying model behind the Vercel AI Gateway path, or the addition of a new push or email vendor. This is not a hypothetical gap: it has already happened once, informally. The Resend → AWS SES migration (register/facts.md, register/suppliers.yaml SUP-003/SUP-004) was a real vendor swap for a system that touches subscriber email addresses and message content, and it was not run through any documented review process — no risk assessment, no DPA-status check before cutover, no stakeholder sign-off recorded anywhere in the repo. The migration itself appears to have been handled competently (the code confirms Resend is fully removed, no dangling references), but the *process* gap is real: nothing would have stopped a lower-quality vendor swap from happening the same way. This policy's commitment is that the next such change — including a future AI-model vendor change — goes through a documented review before cutover, once procedures/PRO-10 (Sub-processor onboarding & review) exists to define what that review looks like.

4. Monitoring, review and change management of supplier services (5.22)

Scored not_started. Beyond the quarterly DPA-link review described in §2, no periodic supplier review process exists — no scheduled check of a supplier's security posture, incident history, or continued fit for purpose. procedures/PRO-10 is the planned home for this once written.

5. Cloud-security policy (5.23)

Stratify's production architecture is a deliberate, real architectural decision that has not yet been written up as policy — this control (5.23, status partial) exists to close that gap, not to introduce new practice. The facts as they stand:

• Production runs self-hosted on a single Hetzner box (128.140.8.187, region nbg1) —

Docker + Traefik + a self-hosted Supabase stack (Postgres, Auth/GoTrue, Realtime, Storage) — cut over from Vercel/Supabase-Cloud on 2026-06-03. This was a deliberate move away from managed cloud platforms toward a self-hosted model, and it changes stratify's security posture in ways that should be stated as a going-forward requirement, not just described as a historical fact:

• The host's public IP is firewalled to Tailscale-only access (docs/runbooks/deploy.md).

This is a real, meaningful network-security control, and this policy states it as a baseline requirement for any future infrastructure change, not merely an observation about today's setup: no production administrative surface should be reachable from the open internet without an equivalent access-control layer. Any future change to this network boundary (opening a port publicly, replacing Tailscale with something weaker) should be treated as a security-relevant architecture decision requiring the same rigor as the original cutover. This baseline is stated in more technical detail under Annex A 8.20 in POL-06's sibling technical controls, and is cross-referenced rather than duplicated here.

• Deployment itself is pull-based (a systemd timer polling the Hetzner host every 2 minutes),

not push-based CI/CD — a real, current architectural fact, not a target state. The former GitHub Actions deploy workflow "is gone. It never once succeeded" (docs/runbooks/deploy.md).

• Supabase's own upstream cloud dependencies (as the software layer stratify self-hosts) are in

active use without a documented cloud-security policy layered on top of the self-hosting decision — the architectural choice was made and executed well, but not accompanied by written policy at the time.

6. Control summary

7. Review

This policy is reviewed on the cadence set at approval, and immediately upon: any change to the production network-access boundary described in §5, onboarding of any new supplier processing personal or signal data, or closure of the Hetzner/AWS SES DPA gaps described in §2.