Security Awareness Training Delivery Procedure

Delivers the plan defined in governance/GOV-09-training-plan.md. State plainly: no security-awareness training has ever been run at stratify. This procedure exists so the first run has a defined, repeatable shape, sized for what the team actually is — one to a few people, not an organisation with an LMS.

1. Who this applies to

Today: Toby (ISMS Owner + Security Officer, sole engineer). Extends to any future hire or contractor from their first week, and to Antonios (DPO / Privacy Owner) for the privacy/compliance-specific content in §2, even though his existing work on dsgvo-data-flow.md already demonstrates the underlying competence informally (GOV-09 §"DPO / Privacy Owner").

2. Content scope

Three fixed topics for the first pass, each tied to something real rather than generic security advice:

1. Secure coding basics, via a real incident. Walk through

docs/adr/0002-email-code-auth-instead-of-links.md end to end: magic links were completely broken in production for weeks — Traefik returned 503 on /auth/v1 because GoTrue's mailer links dropped the reverse-proxy base path, and the mobile deep-link target couldn't work either because mail clients open links in an embedded WebView that won't hand off to a custom URL scheme. Zero magic-link logins ever succeeded before this was caught. The lesson to internalise: a configuration that looks correct in isolation (API_EXTERNAL_URL, emailRedirectTo) can be silently broken end-to-end behind infrastructure like a path-prefixed reverse proxy, and the fix that shipped (6-digit OTP codes, no link dependency at all) is a concrete example of removing a whole class of failure rather than patching around it.

1. Secrets handling, per docs/secrets.md and procedures/PRO-11-secrets-key-management.md:

no secrets in .env files, ever; Keychain for dev, Docker env vars for prod (not Vercel, despite docs/secrets.md's stale line); what the rotation triggers are and why none has been exercised yet.

1. Incident-reporting path, per procedures/PRO-08 (incident response, once written). Until

PRO-08 exists, the interim content is: report a suspected security event directly to Toby (ISMS Owner), and for anything touching subscriber data specifically, also to Antonios (DPO). Update this section to point at PRO-08 once it's written, per GOV-09's own note that this gap is expected to close there.

3. Delivery format

Self-directed review plus a logged completion record — not a formal course. Appropriate for a one-to-few-person team where building or buying a training platform would be disproportionate to the audience. Concretely:

1. The trainee reads the three source materials in §2 directly (the ADR, docs/secrets.md, and the

incident-reporting section once it exists) rather than a derived summary — reading the primary document is the point, since these are real incidents and real policies, not abstracted lessons.

1. The trainee writes a short reflection: one specific thing they'd watch for or do differently

given what they just read, and one open question if they have one. This is the engagement check, not a scored exam — the goal is evidence the material was actually read and connected to real practice, not a pass/fail test.

1. The reflection plus a completion record (name, date, materials covered) is kept as the evidence

of record.

4. Steps for running the first pass

1. Identify the trainee (initially: Toby, self-administered, since there is no one else to run it

for him yet; extend to Antonios for §2 item 2, and to any new hire from day one going forward).

1. Assign the three materials in §2, plus this ISMS's own

governance/GOV-06-statement-of-applicability.md as a standing overview of what is and isn't covered by the wider control set — useful context for understanding where the three specific topics sit within the bigger picture.

1. Trainee completes the self-directed review and writes the reflection (§3, step 2).
2. Trainee records completion: dated entry under docs/compliance/isms/evidence/, naming the

trainee, the date, and the materials covered, with the reflection attached or referenced.

1. ISMS Owner spot-checks the reflection — not to grade it, but to confirm it engages with the

specific material rather than being generic filler, and to catch anything worth updating in the underlying policy documents if the trainee's open question exposes a real gap.

5. Cadence

Annual for everyone with an ISMS role, and triggered immediately for any new hire or contractor as part of onboarding (GOV-09's onboarding checklist, item 1, already references this procedure by name). A trigger-based re-run also applies whenever one of the three source documents materially changes (e.g. PRO-08 is written for the first time, or docs/secrets.md is corrected) — the training content should track the current state of the underlying policy, not a frozen snapshot.

6. Evidence this procedure produces

Dated completion records under docs/compliance/isms/evidence/, one per trainee per run: name, date, materials covered, and the written reflection. This is the record that satisfies ISO/IEC 27001:2022 clause 7.3 (awareness) for whichever cycle it covers — there is no certificate or external attestation, by design, since none would be meaningful at this team size.

7. Review

This procedure is reviewed annually, and revised the first time it is actually run — the content scope in §2 and the format in §3 are a first-pass design, not something validated by a real execution yet.