HR Security Policy
Satisfies Annex A 6.1 through 6.6 (screening, employment terms, security awareness, disciplinary process, termination responsibilities, and confidentiality agreements). Grounded in `register/facts.md`; statuses match `register/controls.yaml`.
1. Policy statement
Stratify's engineering team, as verified by git log --format='%an <%ae>' | sort -u, is exactly one human identity (Tobias Temmen, across two email variants) plus one AI coding agent identity, across all 181 commits — zero second human committer has ever touched the codebase (facts.md). Most of the HR-security controls this document covers are therefore honestly scored not_applicable or not_started, not because HR security doesn't matter, but because the population of people this policy would govern doesn't yet exist beyond one person who is, definitionally, the accountable party for every control here.
This does not mean the whole domain is empty. Two co-founders — Antonios Stergatos (Product & Compliance, DPO/Privacy Owner) and Philipp Sprenger (Structuring & Sales) — own real compliance and business workstreams at Stratify without touching code (facts.md, register/facts.md "Team / access"). They are outside git history, but they are not outside this policy's scope: confidentiality and information-handling obligations apply to what someone can see and discuss, not only to what they can commit.
This policy states the intended baseline for each control now, so that the first hire (or the first non-engineering co-founder agreement) has a documented standard to be measured against, rather than an improvised one.
2. Screening (6.1) — status: not_applicable
No screening process is needed today — there is no candidate pipeline, and the sole engineer is also the ISMS Owner and accountable party. This is scored not_applicable, not not_started, because the control genuinely doesn't apply to a population of one who is already fully accountable by definition.
Intended baseline, once relevant: a standard reference/background check proportionate to the role being filled. For a role with production database access or admin/compliance-role credentials, this should be more thorough than for a role without — proportionate to the elevated access described in facts.md's RBAC model (subscriber | pilot | compliance | founder | admin). Given Stratify's regulatory trajectory toward an FMA Liechtenstein VVG license (regulatory-roadmap-ch-eea.md), screening standards for any future compliance- or finance-adjacent hire should also anticipate what that license will eventually require, not just today's baseline.
3. Terms and conditions of employment (6.2) — status: not_started
No standard employment terms addressing information-security obligations exist. This is a real gap, not a deferred nicety — it needs to close before the first hire, not after. A standard employment agreement template should, at minimum, reference: acceptable use of company systems and data (once POL-02/Acceptable Use exists), confidentiality obligations (§6 below), and an acknowledgment that the employee has read and agrees to the then-current version of this ISMS's Tier 1 policy set.
4. Security awareness, education and training (6.3) — status: not_started
No security-awareness or training programme exists. This control is deliberately not elaborated further in this policy — it points to GOV-09 (Competence, Awareness & Training Plan, pending per `PLAN.md` §4), which is where the actual training content, cadence, and completion-tracking mechanism should be designed. This document's role is limited to naming the commitment and the pointer, not duplicating GOV-09's eventual content.
5. Disciplinary process (6.4) — status: not_started
No disciplinary process for security violations is documented. This is honestly scored not_started and honestly deferred: a disciplinary process presupposes a team large enough, and roles distinct enough, for the concept to mean something beyond "the founder disciplines himself." It becomes relevant, and should be written, once the team grows past the current single-engineer structure.
6. Responsibilities after termination or change of employment (6.5) — status: not_started
No offboarding procedure exists for revoking access, rotating credentials, or reassigning ownership when someone's employment or role changes. This connects directly to PRO-01 (Joiner / Mover / Leaver, pending per `PLAN.md` §4) — the access-revocation mechanics belong in that procedure, not duplicated here. What this policy commits to is the principle: termination-responsibility handling is not optional once a second person with any system access exists, and docs/secrets.md's existing rotation table (e.g. "engineer leaves → rotate every secret they could have read," docs/secrets.md:76-83) is a real, if currently aspirational-given-team-size, starting point that PRO-01 should build on rather than reinvent.
7. Confidentiality or non-disclosure agreements (6.6) — status: not_started
No standard confidentiality or NDA process exists for contractors or for the wider founder team. This is worth being specific about, because "wider founder team" is not a hypothetical future population at Stratify — it is Antonios and Philipp, today, right now:
- Antonios owns the FMA license and DSGVO/privacy workstream (named
Owner: Antonioson
dsgvo-data-flow.md) and is the confirmed DPO / Privacy Owner for this ISMS (facts.md, PLAN.md §2). He does not appear in git history, but he plausibly discusses, reviews, or has visibility into compliance findings, regulatory strategy, and — by virtue of the DPO role — potentially subscriber-data-adjacent information, all without ever touching the codebase.
- Philipp owns structuring and sales and likewise does not touch code, but plausibly has
visibility into commercial terms, pilot-strategy-author relationships, and business strategy that would be damaging if disclosed.
Neither has a documented confidentiality commitment on file today, despite both having exactly the kind of access — informational, not code-based — that confidentiality agreements exist to cover. This is a real, current gap, not a hypothetical one, and it is arguably a cheaper and more urgent fix than most other items in this policy: writing and signing a standard confidentiality agreement with two known individuals doesn't wait on a future hire.
Commitment: a standard confidentiality/NDA template should be drafted and put in place for Antonios and Philipp before this policy is marked approved, and used as the default for any future contractor or advisor who gains access to non-public Stratify information without joining as an employee.
8. Forward path
- GOV-09 (Competence, Awareness & Training Plan) — where §4's training commitment gets
actual content and cadence.
- PRO-01 (Joiner / Mover / Leaver) — where §6's offboarding mechanics get written as an
executable procedure, drawing on the existing rotation table in docs/secrets.md.
- A standard confidentiality/NDA template — the one item in this policy with no dependency
on team growth, and the most tractable near-term action (§7).
9. Related documents
docs/secrets.md§76-83 — the existing (aspirational-given-team-size, but documented)
secret-rotation table referenced in §6
dsgvo-data-flow.md— Antonios's ownership of the DSGVO/privacy workstream, referenced
in §7
regulatory-roadmap-ch-eea.md— the FMA licensing trajectory referenced in §2- GOV-03 — Roles, Responsibilities & Authorities (pending) — the RACI this policy's role
references should ultimately connect to
- PRO-01 — Joiner / Mover / Leaver (pending)
- GOV-09 — Competence, Awareness & Training Plan (pending)