Stratify
Legal and compliance

Control of Documented Information

docs/compliance/isms/governance/GOV-10-document-control.md

Source updated 03. Aug. 2026

Control of Documented Information

Satisfies ISO/IEC 27001:2022 clause 7.5. Describes the mechanism this ISMS actually uses to manage its own documents — not a GRC tool or a document-management system, but git plus a fixed Markdown front-matter convention. This is a deliberate choice, documented in register/schema.md, and it is the mechanism in effect for every file under this ISMS, including this one.

The mechanism

Every document under docs/compliance/isms/{governance,policies,procedures,privacy}/ opens with a YAML front-matter block:

---
id: GOV-10
title: Control of Documented Information
owner: "ISMS Owner"
version: 0.1
status: draft
approved: null
review_due: null
controls: []
regulations: []
---

The document then lives in the stratify git repository, under version control, subject to the same commit and (when a second reviewer exists) pull-request history as the codebase itself.

How this satisfies clause 7.5

Clause 7.5.2/7.5.3 ask for documented information to be identified, appropriately formatted, reviewed and approved before issue, kept under version control, and controlled in its distribution, access, storage, and retention. Each of those maps directly onto the mechanism above:

  • Identification — the id field (GOV-nn / POL-nn / PRO-nn / PRIV-nn) plus title

gives every document a stable, unique identifier independent of its filename. The numbering scheme itself (governance / policies / procedures / privacy) encodes the document's tier.

  • Format — a single consistent structure (front matter, then Markdown body) across all four

tiers. No document deviates from this shape; a reader who knows the convention can navigate any document in the set the same way.

  • Review and approval before issue — the status field (draft → approved → superseded)

plus approved (null until an approval date is set) is the approval record. A document is not "issued" in the ISO sense until status: approved and approved carries a real date. Until then, a document like this one is explicitly draft — a working position, not yet a controlled commitment.

  • Version control — the version field plus git commit history together satisfy this without

needing a separate versioning tool. Git gives, for free, exactly what clause 7.5 asks for: every change to a document has an author, a timestamp, and a diff against the previous version (register/schema.md §"Why YAML + git, not a GRC tool"). The version field is bumped on substantive revisions; trivial fixes (typos, link corrections) don't require a version bump but do still show up in git history.

  • Controlled distribution, access, storage, retention — distribution and access control are

inherited from the repository's own access model: whoever has read access to the stratify repo has read access to the ISMS document set, and nothing here has a separate, weaker access boundary. Storage and retention are git's — nothing is deleted; superseding a document leaves its prior versions recoverable from history rather than physically removed.

Document lifecycle

  • draft — the document exists, states a position, but has not been reviewed and accepted as the

organization's current commitment. approved and review_due stay null.

  • approved — the document has been reviewed (informally, given team size — see

GOV-11 and GOV-12 for how review actually happens on a two-person team) and accepted. approved is set to the acceptance date, and review_due is set per the default below.

  • superseded — a newer version or a replacement document has taken over. The superseded

document is not deleted; it stays in git history and, ideally, gets an explicit note in its own front matter or body pointing to what replaced it.

Review cadence

Default: review_due = approved + 12 months, unless a document states a shorter cadence explicitly (per register/schema.md). A document whose review_due has passed without being re-reviewed is itself a nonconformity candidate under GOV-13 — this is the enforcement mechanism, even though no automated check for it exists yet (see gap below).

Location

Documents live under docs/compliance/isms/, split by tier:

  • governance/ — GOV-nn, the ISO clause 4-10 mandatory documents.
  • policies/ — POL-nn, Annex A grouped into domains.
  • procedures/ — PRO-nn, operational how-to documents.
  • privacy/ — PRIV-nn, GDPR/revDSG documents.

The register itself (register/facts.md, register/schema.md, register/controls.yaml, register/risks.yaml, register/assets.yaml, register/suppliers.yaml) is not front-matter'd the same way — it is data (YAML) and reference material (Markdown), not a controlled document in the 7.5 sense, though it is still git-versioned and subject to the same authorship/history guarantees.

What this control does not cover — a known gap

This document-control mechanism applies to docs/compliance/isms/ only. It does not extend to the operational compliance documents one level up, in docs/compliance/ directly — dsgvo-data-flow.md, pentest-rfp.md, signalgeber-classification.md, regulatory-roadmap-ch-eea.md, and similar. Those documents are real, substantive, and actively used (dsgvo-data-flow.md in particular is the primary privacy document this ISMS's PRIV-nn tier cites rather than duplicates, per PLAN.md §2), but they carry no status, version, approved, or review_due discipline. Nothing currently flags when one of them drifts out of date.

That gap is not hypothetical: dsgvo-data-flow.md and pentest-rfp.md are both already known-stale relative to the real infrastructure (Vercel → Hetzner, Resend → AWS SES; see register/facts.md and register/risks.yaml RISK-001) precisely because nothing enforced a review trigger when the underlying infrastructure changed. This is logged as the first entry in GOV-13 rather than silently worked around here. Extending the same front-matter convention to docs/compliance/*.md — or at minimum adding a "last verified against production" date to each — is a reasonable future scope extension of this control, not something this document claims to already do.

Not yet built

A CI check that fails a merge when review_due has passed, or when a document claims status: approved with an empty approval date, is described in PLAN.md but not yet wired. Until it exists, review-due enforcement is manual and depends on the ISMS Owner noticing — worth stating plainly rather than implying an automated gate exists.