Security Objectives & Metrics

Satisfies ISO/IEC 27001:2022 clause 6.2. These are the concrete, measurable objectives the ISMS is working toward over the next 12 months from this document's baseline date (1 August 2026). Every baseline number below is cited to register/controls.yaml, register/risks.yaml, or register/facts.md — none are estimated.

Each objective states a baseline, a target, an owner, and a target date. Progress against these objectives is a standing input to management review (see GOV-12); objectives themselves are reviewed and, where needed, re-baselined at each management-review cycle rather than left static for a full year.

1. Close the dependency/SCA scanning gap in CI

• Baseline: 0 dependency/SCA scans run in either pipeline today. Neither dos-ci.yml nor the

vestigial Jenkinsfile runs pnpm audit, Dependabot, or Renovate — confirmed absent, not merely undocumented (register/facts.md, register/risks.yaml RISK-003, control 8.8).

• Target: An SCA scan (pnpm audit at minimum, Dependabot/Renovate config as a stretch) wired

into dos-ci.yml as a required job, failing the verify gate on high/critical findings.

• Owner: ISMS Owner (Toby).
• Target date: 2026-11-01 (3 months) — flagged in controls.yaml's own judgment on 8.8 as

"cheap to close," so prioritized ahead of heavier objectives below.

2. Complete the first backup-restore drill

• Baseline: Never tested. docs/runbooks/db-recovery.md's own setup checklist has "restore

tested manually" unchecked; the decision log's last row reads "TBD — Erster vollständiger Hetzner-Restore-Drill abgeschlossen" (RISK-004).

• Target: One full restore drill executed against the nightly pg_dump backups, results and

timing logged in db-recovery.md's decision log (actual RTO measured against the stated ≤60 min SLO).

• Owner: ISMS Owner (Toby).
• Target date: 2027-02-01 (6 months) — aligned to the "Quartalsweiser Test verpflichtend"

cadence already stated in the runbook, so the first drill anchors the recurring schedule.

3. Reduce the not_started control count

• Baseline: 35 of 93 Annex A controls are not_started as of the Phase 0 gap analysis

(1 August 2026) — alongside 5 implemented, 39 partial, 13 not_applicable, 1 planned (register/controls.yaml meta, GOV-06-statement-of-applicability.md).

• Target: Reduce not_started to 20 or fewer, driven by the Tier 0 governance set (this

document set), Tier 1 policies, and the priority-ordered Tier 2 procedures in PLAN.md §4 landing on schedule. This is a realistic reduction, not a claim of closing the majority of gaps in one cycle — a pre-seed, single-engineer team writing its first ISMS should expect most controls to stay partial rather than jump straight to implemented.

• Owner: ISMS Owner (Toby).
• Target date: 2027-08-01 (12 months).

4. Send the pentest RFP and triage first findings

• Baseline: docs/compliance/pentest-rfp.md has been at "Vendor-Shortlist + RFP-Brief" stage

since 2026-05-19 — drafted, never sent, infra-scope section still references "Vercel EU" (RISK-006).

• Target: Infra-scope section corrected to reflect the Hetzner self-hosted architecture, RFP

sent to the drafted 4-vendor EU shortlist, and the first round of findings triaged (P0 findings either remediated or explicitly risk-accepted with an owner and date).

• Owner: ISMS Owner (Toby).
• Target date: 2027-05-01 (9 months) — gated on objective 5 below (the stale infra-scope

reference has to be fixed before the RFP can honestly go out).

5. Correct stale hosting/vendor references in compliance documents

• Baseline: 2 known-stale documents. docs/compliance/dsgvo-data-flow.md still lists Vercel as

hosting processor and Resend as the transactional-email processor; docs/compliance/pentest-rfp.md scopes its target environment against "Vercel EU"/"Supabase EU." Both predate or were not updated after the 2026-06-03 Hetzner cutover and the AWS SES migration (register/facts.md, RISK-001).

• Target: 0 stale hosting/vendor references across both documents — corrected to Hetzner

self-hosted infrastructure and AWS SES (eu-central-1) respectively.

• Owner: DPO / Privacy Owner (Antonios) for dsgvo-data-flow.md (document owner of record);

ISMS Owner (Toby) for pentest-rfp.md (infra author) — split per PLAN.md §6 open decision 3.

• Target date: 2026-10-01 (2 months) — a low-effort, high-credibility-cost fix, prioritized

ahead of most other objectives. Tracked as the first entry in GOV-13.

6. Close the MFA gap for elevated roles

• Baseline: No MFA is offered for any role today, including admin/founder/compliance

roles that carry elevated data access (GDPR export, erasure, subscriber management) — single factor is the 6-digit email OTP throughout (register/facts.md, RISK-005, control 8.5).

• Target: MFA (TOTP or equivalent second factor) required for admin, founder, and

compliance role accounts. Subscriber-facing MFA is out of scope for this objective — the elevated-role gap is the higher-impact one given what those roles can do.

• Owner: ISMS Owner (Toby).
• Target date: 2027-08-01 (12 months).

7. Establish a segregation-of-duties position for code review

• Baseline: Zero required human PR reviewers besides Toby; CODEOWNERS exists but is fully

commented out (RISK-002, control 5.3). This is a real, current gap on a single-engineer team, not a process failure.

• Target: Either (a) a second technical reviewer is engaged and CODEOWNERS is activated, or

(b) the current state is formally documented as an accepted risk with an explicit trigger condition (second technical hire) for when it must change — reviewed at every management-review cycle in the meantime rather than left as a silent gap.

• Owner: ISMS Owner (Toby).
• Target date: 2027-08-01 (12 months), reviewed at each GOV-12 cycle regardless of outcome.

Review

These objectives are reviewed as a standing input to management review (GOV-12), on whatever cadence GOV-12 establishes — expected annual once a first review has been held, more frequently during Phase 1-3 while the governance and procedure set is still being written. Baseline numbers are re-pulled from register/controls.yaml and register/risks.yaml at each review rather than carried forward from memory, since both registers are expected to change materially as documents land.