Nonconformity & Corrective Action Log
Satisfies ISO/IEC 27001:2022 clause 10.2. This is the log of nonconformities identified against this ISMS, and the corrective actions taken (or planned) in response. It is seeded with real, current entries below rather than left as an empty template — the gaps captured here are already known and cited to register/facts.md, not hypothetical placeholders.
What qualifies as a nonconformity
A nonconformity is a failure to meet a stated requirement — an ISO 27001 clause, an Annex A control this ISMS claims a status for, or Stratify's own written policy or procedure. This includes, and should not be read narrowly to exclude:
- A control in
register/controls.yamlwhose claimed status no longer matches reality (caught by
internal audit, GOV-11).
- A document in this ISMS whose
review_duehas passed without review (GOV-10). - Documentation elsewhere in the repository that has drifted out of sync with the real, running
system it describes — the entries below are exactly this case.
- A written procedure that exists but is not actually being followed in practice.
Corrective-action process
For each nonconformity:
- Description — what the nonconformity is, stated precisely enough that someone unfamiliar
with the context can understand what's wrong.
- Root cause — why it happened, not just what happened. "The document is stale" is a
description; "the infrastructure changed and nothing in the release process required a documentation update" is a root cause.
- Correction — the immediate fix that addresses the specific instance (e.g. editing the stale
line).
- Corrective action — the change that addresses the root cause so the same class of
nonconformity doesn't recur (e.g. adding a documentation-review step to the process that changes infrastructure, not just fixing this one document).
- Effectiveness check — how and when it will be confirmed the corrective action actually
worked, not just that it was performed.
- Closure — status moves to
closedonce the effectiveness check passes; it staysopen
until then, including while the correction has landed but the corrective action hasn't yet been verified to hold.
Log
New entries are appended below in the same row format. status values: open, closed.
| ID | Description | Root cause | Corrective action | Owner | Target date | Status |
|---|---|---|---|---|---|---|
| NC-001 | docs/compliance/dsgvo-data-flow.md and docs/compliance/pentest-rfp.md contain stale infrastructure/vendor references — both still describe Vercel as the hosting processor and, in dsgvo-data-flow.md's case, Resend as the transactional-email processor. Production cut over to self-hosted Hetzner on 2026-06-03 and email moved to AWS SES (eu-central-1) around the same period; neither document was updated. A reader relying on either document (a partner, an investor, a future auditor) would be given factually wrong information about where data is processed. | The 2026-06-03 Hetzner cutover and the Resend-to-SES migration were both real, deliberate infrastructure changes, but neither was accompanied by a step requiring compliance-facing documentation to be updated in step. register/schema.md's document-control convention (GOV-10) only covers docs/compliance/isms/, not the operational documents one level up where these two live — see the gap GOV-10 itself flags. | Correct both documents' hosting/vendor sections to reflect the Hetzner self-hosted architecture and AWS SES. Additionally, add a documentation-review checklist item to whatever process governs infrastructure/vendor changes going forward, so the next migration doesn't repeat this. | dsgvo-data-flow.md: DPO / Privacy Owner (Antonios). pentest-rfp.md: ISMS Owner (Toby). Split per PLAN.md §6 open decision 3. | 2026-10-01 | open |
| NC-002 | Zero required human PR reviewers exist besides Toby. CODEOWNERS is present in the repository but every line is commented out, so it routes no review requirement to anyone. The only mandated review at "Tier 1" (per CONTRIBUTING.md) is an automated code-review run in a fresh context, not a second human. This is a segregation-of-duties gap against Annex A control 5.3. | Single-engineer team at pre-seed stage — CODEOWNERS was scaffolded ahead of the team actually needing it, and no second technical committer has joined (confirmed via git log, exactly one human identity across all commits). | Document the current state as an accepted risk at today's team size (register/risks.yaml RISK-002) with an explicit trigger: activate CODEOWNERS and require human review the moment a second technical person joins, rather than leaving the decision ambiguous when that happens. Revisit at every management review (GOV-12) regardless of whether the trigger has fired. | ISMS Owner (Toby) | Reviewed at each GOV-12 cycle; no fixed closure date since the corrective action is a standing policy, not a one-time fix. | open |
| NC-003 | No dependency/SCA vulnerability scanning exists in CI. Neither the active dos-ci.yml pipeline nor the vestigial Jenkinsfile runs pnpm audit, Dependabot, or Renovate — confirmed absent by direct inspection, not merely undocumented. A known-vulnerable dependency could ship to production undetected. This is a gap against Annex A controls 5.7 and 8.8. | dos-ci.yml's required verify check was built around lint, typecheck, tests, secret-scanning (gitleaks), and build — dependency scanning was not included in its original scope. | Add pnpm audit (or, as a stretch, Dependabot/Renovate configuration) as a required job in dos-ci.yml, failing the verify gate on high/critical findings. | ISMS Owner (Toby) | 2026-11-01 | open |
Effectiveness checks
For NC-001, effectiveness is confirmed when both documents are re-read against the current production state (Hetzner, AWS SES) with no remaining discrepancy — the next internal audit cycle (GOV-11) that samples control 5.34 or 5.33 is a natural point to verify this. For NC-002, effectiveness is an ongoing condition rather than a one-time check: the trigger (second technical hire) either hasn't fired, in which case the accepted-risk position still holds, or it has, in which case CODEOWNERS activation is verified directly in the repository. For NC-003, effectiveness is confirmed by observing the SCA scan actually run and fail correctly against a known-vulnerable test dependency, not just by observing that a job was added to the workflow file.
How entries get here
Three sources feed this log: GOV-11 internal audit findings (a control's claimed status turns out not to hold), direct observation by the ISMS Owner or DPO / Privacy Owner between audit cycles (as with all three seed entries above, none of which required a formal audit to surface — they were already known from register/facts.md), and, once PRO-08 exists, post-incident reviews. A nonconformity does not need to wait for a scheduled audit to be logged; anyone with an ISMS role can add an entry the moment a gap is confirmed, using the same row format as NC-001 through NC-003.
Relationship to management review
Open entries in this log, and the status of corrective actions against their target dates, are a standing input to every GOV-12 management review. A nonconformity that has sat open past its target date without a documented reason is itself worth surfacing at that review, rather than left to age silently in this table.