Competence, Awareness & Training Plan

Satisfies ISO/IEC 27001:2022 clauses 7.2 (competence) and 7.3 (awareness). Written honestly for what the team actually is today — two people with ISMS roles, one of whom (Toby) touches the codebase, and no dedicated security or compliance headcount.

Baseline

No formal security-awareness training has ever been run. There is no learning-management system, no completion tracker, and no onboarding checklist that names information security explicitly. This is expected and unremarkable for a single-engineer, pre-seed team — the honest baseline is "informal competence, no documented record of it," not "no competence."

Current people with an ISMS role (register/facts.md):

• Toby — ISMS Owner + Security Officer. Sole engineer/committer across all 181 commits in git

history (one human identity, per git log).

• Antonios — DPO / Privacy Owner. Owns the FMA license and DSGVO workstream, named

Owner: Antonios on docs/compliance/dsgvo-data-flow.md.

• Philipp — co-founder, Structuring & Sales. Not assigned an ISMS role and does not touch the

codebase (register/facts.md).

Competence requirements by role

ISMS Owner (Toby)

Needs working knowledge of the Annex A control set this ISMS is built against — not memorized, but able to read a control (register/controls.yaml), judge whether a status claim is still true, and know where the corresponding evidence lives in the repo. This is largely already demonstrated by having authored the Phase 0 gap analysis (93 controls judged against register/facts.md), but that is a one-time exercise, not a standing competence record. PLAN.md §6 open decision 2 recommends buying the ISO 27001 and 27002 texts (~CHF 380) before Tier 1 policy drafting begins — that purchase, once made, becomes the primary reference material this role's competence is built on.

DPO / Privacy Owner (Antonios)

Needs working GDPR/revDSG knowledge — legal bases, subject-rights handling, breach-notification clocks, sub-processor/DPA obligations. This competence already exists informally: Antonios owns docs/compliance/dsgvo-data-flow.md (a substantive, actively maintained privacy document covering data categories, Art. 6 legal bases, cross-border transfers, and subject-rights procedures) and the FMA-license workstream. What's missing is not the competence itself but a documented competence record — this plan is the first point at which that informal expertise is named as satisfying clause 7.2, rather than assumed.

Philipp (no ISMS role)

No ISMS competence requirement applies, since no ISMS responsibility is assigned. If that changes (e.g. Philipp takes on a role touching subscriber or partner data), this document should be updated before the role assignment, not after.

Onboarding checklist — for any future hire or contractor

Nobody has been onboarded under this checklist yet; it is written ahead of the first hire rather than retrofitted after one, since Stratify's own CONTRIBUTING.md and docs/secrets.md already describe most of the substance. A future hire/contractor onboarding should cover, at minimum:

1. Secure coding basics — walkthrough of CONTRIBUTING.md's Tier 1 conventions (required

verify CI check, Conventional Commits, PR-based workflow) and the CI gate itself (.github/workflows/dos-ci.yml: lint, typecheck, tests, gitleaks secret-scan, build).

1. Secrets handling — docs/secrets.md's policy (no secrets in .env files; macOS Keychain in

development, environment variables injected into the Hetzner Docker containers in production) and the rotation table it defines (e.g. "engineer leaves → rotate every secret they could have read"). Note for whoever runs this session: docs/secrets.md itself still has a stale line referencing "Vercel project envs in production" (see GOV-13) — correct that before using it as onboarding material, or flag it explicitly during the walkthrough.

1. Incident-reporting path — how to report a suspected security event. No formal channel exists

yet beyond direct contact with the ISMS Owner; this section should be filled in once PRO-08 (incident response) is written, and this document updated to point to it.

1. Access provisioning — what access is granted, by whom, and what its removal looks like on

departure. Ties to the future PRO-01 (Joiner/Mover/Leaver) procedure.

1. Acknowledgement — a dated, named acknowledgement that the above was covered, kept as the

onboarding's completion record.

Minimal recurring awareness activity for a team of one

A single-engineer team cannot run a training program in any conventional sense, but "no awareness activity at all" is not defensible either. The minimum viable recurring activity:

• Annual self-review against the OWASP Top 10 and this ISMS's own gap list. Once a year, the

ISMS Owner walks the current OWASP Top 10 against the codebase's actual attack surface (auth, RLS, admin actions, partner API), and separately reviews the not_started/partial controls in register/controls.yaml as a standing "what am I not doing yet" checklist. The output is a dated note — not a certificate, but a record that the review happened and what it found.

• This activity is intentionally cheap to run so it actually happens, rather than an ambitious

program that quietly lapses on a team of one.

Records

No competence or awareness records exist yet. Once produced (onboarding acknowledgements, the annual self-review note), they should be dated and kept under docs/compliance/isms/evidence/, consistent with the evidence-handling approach described in GOV-10.

Review

This plan is reviewed annually, tied to the GOV-12 management-review cadence, and revisited immediately if a new hire or contractor is engaged — the onboarding checklist above should be treated as a living draft until it has actually been run once.