Internal audit programme

Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Review cycle: annual for this programme; monthly for the reviews it schedules. Companion to the scope statement and the statement of applicability (controls A.5.29, A.5.35, A.5.36). Not a certification document.

1. The problem this solves

Every management system claims it is reviewed. Almost none can show you when, or what was found. “We review this annually” is not a checkable statement — it is a promise about the future, and a promise is not evidence.

This service already publishes a daily signed technical audit that a stranger can verify: it asserts the logging posture on the host itself, signs the result, and fails loudly when a check regresses. The same discipline is applied here, turned inward. The technical audit proves what the infrastructure does. This programme proves what the management system does — and produces a dated artifact that a third party can check, rather than an assurance they must take on trust.

2. The review cycle

Cycle	When	What is reviewed	Output
Monthly	Within the first seven days of the month	The previous month’s incidents; the state of every ISMS document; the control counts; any open findings and their age	A dated internal review record
Quarterly	January, April, July, October	A control-level sample — a subset of controls marked applied re-examined against the running system, to test whether the marking is still true	Findings appended to that month’s record
Annual	September	Full review: every Annex A control re-assessed, the risk register re-scored, the scope statement re-confirmed, this programme itself reviewed	A new version of each affected document

The monthly cycle is the load-bearing one. Quarterly sampling exists because a control marked applied a year ago is a claim about the past; the only way to know it is still true is to check it again.

3. What the monthly record contains

Each monthly review produces a record at a stable, dated path containing:

1. Date and period — when the review was performed and what it covers.
2. What was reviewed — the documents examined and the checks run.
3. Findings — what was found to be wrong, incomplete, or no longer true.
4. Control counts — applied / partial / planned / excluded / not applicable, with the movement since the previous month.
5. Incidents — S1 and S2 incidents from the period, with severity and resolution.
6. Open items — findings carried forward, with their age. An item open for more than two cycles is escalated into the risk register, because a finding that keeps not being fixed is a risk being silently accepted.
7. Changes made — the commits arising from this review.

Findings are real

The record has a findings section and it is expected to contain findings. A review that reports nothing wrong is treated as an incomplete review, not a clean one — the same rule the post-incident review carries.

Findings are recorded even when unflattering, and specifically including the case where a control is marked applied but nothing enforces it. That is the most valuable class of finding this programme can produce: a gap between what the statement of applicability claims and what the infrastructure does. Where such a gap is found, the control is re-marked to partial and the correction is recorded. The document is corrected to match reality, never the reverse.

4. Who performs the review

The operator performs the review, assisted by automation for the parts that can be automated (control counts, incident collation, document change detection). This is self-assessment, and it is not an independent audit.

That is a real limitation and it is recorded as an accepted risk. It is mitigated, not eliminated, in three ways:

• The findings are published. A self-assessment that publishes its own adverse findings is harder to game than one that stays private.
• The claims are independently checkable. The technical assertions in this management system point at artifacts a stranger can verify without trusting the operator — the signed audit, the public configuration repository, the escrow files.
• The record is dated and append-only in practice. A review record that appears only when convenient is visible as a gap in the sequence.

What it cannot provide is the assurance of a second pair of eyes. Organisations that need that must engage an external auditor, and this document exists partly so that such an auditor has something real to examine.

5. How a third party verifies a review happened

The verification path is deliberately the same shape as the technical audit:

1. The record exists at its dated path for the period in question.
2. The record is signed, and the signature verifies against a pinned public key — the same trust-on-first-use pinning used for the daily audit.
3. The claimed counts match the documents. A record asserting a control count that disagrees with the statement of applicability is a falsifiable inconsistency, and reconciling the two is a mechanical check. (This is not hypothetical: the first version of the statement of applicability carried theme summaries that did not sum to its own table. Checking caught it.)
4. The changes the record claims are real. Findings cite commits, and commits are in the public repository.

A record that fails any of these checks is worse than no record, because it claims verification that does not hold.

6. What this programme does not claim

• It is not an independent audit. Self-assessment only; disclosed above.
• It is not a certification. There is no certificate and no accredited body has assessed this management system. The phrase used throughout is aligned with ISO/IEC 27001:2022.
• It does not cover physical controls, which are excluded in the scope statement because the infrastructure is rented rather than operated.
• Completeness is not guaranteed. A monthly review examines what it lists and can miss what it does not think to look for; quarterly sampling reduces but does not eliminate that.