The management system

We hold no certificate and have not been audited by anyone. These documents exist because a security claim you cannot inspect is just marketing. They are the management-system substrate that makes the phrase “aligned with ISO/IEC 27001:2022” a defensible statement rather than an aspiration. For the full position — what we claim, what we do not, and the words we refuse to use — see Standards.

The documents

Document	What it establishes
Information security policy	The primary policy: management commitment, the policy set and the owner of each part, the review cycle, and the dated approval record. Everything below hangs from it.
ISMS scope statement	What the management system covers, what it deliberately excludes, and why. Defines the subject of every other document here.
Risk register	Fifteen identified risks with assessed likelihood and impact, the controls that treat each, and the residual risk carried afterwards. Includes the risks we accept rather than mitigate.
Statement of applicability	All 93 ISO/IEC 27001:2022 Annex A controls, assessed one by one: applied, partial, planned, excluded or not applicable — with the basis for each.
Change management statement	How a change reaches production, and how a bad change is reverted automatically.
Incident response plan	Severity levels, the response process, and the post-incident review that closes each incident — including the single-operator constraint, disclosed rather than papered over.
Supplier review	All six providers we depend on — hosting, storage, payments, email, DNS, registrar — assessed on what each receives, where it goes, what breaks without it, and why the position is what it is. Includes the honest limits: we assess our side, not theirs.
Internal audit programme	The dated, signed review cycle for this management system itself: what is reviewed, how often, what a review record contains, and how a third party checks that a review actually happened.

The position in one paragraph

Our technological controls are in genuinely good shape — 18 of 34 Annex A technological controls fully applied, backed by evidence stronger than most organisations can produce (a signed daily audit that asserts the logging posture on the host itself and publishes the result). Our organisational controls are partial, and our physical controls are almost entirely excluded because we rent our infrastructure rather than operating a facility. There is no separation of duties, because one person operates the service; that is recorded as an accepted risk rather than disguised with a paper control. Twenty-seven controls are fully applied, forty are partial, and the remaining work is process and paperwork rather than engineering.

Why publish this at all

Most small operators describe their security posture in prose and hope. The purpose of writing it down control-by-control is that it can be checked — and that where we fall short, the shortfall is visible in a document we published voluntarily, rather than discovered by someone who trusted a claim we should not have made.

An honest gap register is worth more than an impressive-sounding one. The statement of applicability marks controls partial where a vendor page would say compliant, and marks ten physical controls excluded because that is the truth about rented infrastructure.

Progress

This is version 1.3 (2026-09-18). The largest remaining documented gaps, in priority order:

A produced review history: the programmes are written and scheduled, and the first supplier review record now exists, but the internal audit programme has not yet produced a cycle record and the daily audit history is days old, not months. Until the series exists, the management cycle is mostly a plan rather than evidence.
Independent review: this management system is self-assessed. An external auditor would close the gap that the internal audit programme explicitly cannot. This is a business decision, not an engineering gap.
Bespoke supplier agreements (A.5.20): the supplier review records as open finding (1) that we operate on standard provider terms without negotiated security schedules. Documented is not closed.

Closed since the first publication (all 2026-09-18)

Supplier review (A.5.19, A.5.22) — the supplier review assesses all six suppliers with a dated review record and a defined annual cycle. A.5.22 moves from planned to partial: the cycle exists and the first record is written, but it is the initial baseline and no supplier is actively monitored for security events. A.5.20 stays partial, with the reason recorded as an open finding rather than implied.
Information security policy (A.5.1) — the information security policy consolidates the policy set, names the owner of each part, defines the review cycle, and carries a dated approval record. It remains marked partial rather than applied: the approval is an owner’s approval in a one-person organisation, and no review has been performed under it yet. The document states both limits itself.
Incident response (A.5.24–A.5.27) — the incident response plan now defines severity levels, the response process, and the post-incident review. It does not claim an on-call rota or an escalation matrix, because one operator cannot staff one; that constraint is disclosed in the document and carried as an accepted risk.
Operating the system (A.5.29, A.5.35, A.5.36) — the internal audit programme defines the dated, signed monthly review cycle, the quarterly control sampling, and an annual full re-assessment.

Note what these two documents are: a written process and a schedule, not a history. No monthly review record has yet been produced, because the programme is new. The first record is the point at which the cycle becomes evidence rather than intention — and until a few cycles exist, these controls remain marked partial in the statement of applicability for exactly that reason.