Changelog

What we said was missing, and when it stopped being.

We publish a clause-by-clause register of where every ISO management-system requirement lives in the product, including the parts that were not built yet. This is the record of those admissions closing. 40 of them, each quoted exactly as it was published.

Generated from the registers themselves, not written afterwards. A gap gets onto this page by having been on the coverage page first, which is the only reason it is worth reading.

28 August 2026

  • 8.6Release of products and services against planned arrangementsISO 9001

    Was: No release records and no evidence of conformity to acceptance criteria, nor of the person authorising release.

22 August 2026

  • 6.2Quality objectives, measurable, monitored and planned forISO 9001

    Was: The machinery is right and the labelling is not: objectives are measurable, monitored and evidenced, but they are stored and presented as security objectives. 9001 6.2.1 asks for quality objectives at relevant functions and levels, and an auditor reads the screen. 6.2.2 also asks what will be done, with what resources, by whom, when, and how results are evaluated, and only the last of those is captured.

  • 7.1.6The knowledge the organization needs, maintained and availableISO 9001

    Was: Organizational knowledge is a 9001-only clause with no 27001 counterpart. Documents can hold the knowledge itself, but there is no way to mark a document as organizational knowledge, give it an owner, or review it for currency, so nothing answers 7.1.6 as a clause.

13 August 2026

  • 7.1.5Monitoring and measuring resources, and their traceabilityISO 9001

    Was: No calibration records, no equipment identification, no measurement traceability to international or national standards. For a manufacturer this is a routine audit finding and there is nothing here to answer it with. For a pure service company it is often not applicable, but that determination itself has to be recorded and cannot be.

  • 9.1.2Customer satisfaction, monitored as a perceptionISO 9001

    Was: A 9001-only clause with nothing behind it. It asks the organization to monitor customers' perception of the degree to which their needs have been met, and to determine the methods for obtaining and reviewing that information.

4 August 2026

  • 6.1.2How risk is assessed, on your own scaleISO/IEC 27001

    Was: Criteria are prose the system cannot evaluate against, and likelihood and impact are fixed 1–5 so an organization cannot use its own scale. The assessment event itself is now recorded (8.2).

  • 6.1.2How AI risk is assessed, including harm beyond your organizationISO/IEC 42001

    Was: Criteria are prose the system cannot evaluate against, and likelihood and impact are fixed 1–5 so an organization cannot use its own scale. 42001 additionally asks that the criteria account for consequences to individuals and to society, not only to the organization, and the register has no field that separates them.

3 August 2026

  • 4.1Understanding the organization and what surrounds itISO/IEC 27001

    Was: Issues are captured as text. Nothing links an issue to the risk or objective it drives, and there is no review cadence.

  • 4.2Who has an interest, and what they requireISO/IEC 27001

    Was: One free-text field conflates needs with requirements, and there is no field for which requirements the ISMS will address (4.2 c).

  • 4.3Deciding what the ISMS coversISO/IEC 27001

    Was: The scope statement is an unversioned, unapproved column outside the document module, and has no field for interfaces and dependencies (4.3 c).

  • 5.2An information security policyISO/IEC 27001

    Was: Versioning and approval are strong. No flag identifies which document is *the* policy, and there is no record of it being communicated or made available (5.2 f, g).

  • 6.1.3Choosing controls and stating which applyISO/IEC 27001

    Was: The SoA renders and hashes server-side. There is no Annex A catalogue in the database, so the 6.1.3 c) check that no necessary control was omitted cannot be performed by the system.

  • 6.2Security objectives and how they will be metISO/IEC 27001

    Was: Missing what will be done, what resources are needed, who is responsible, and how results will be evaluated (6.2 e–i).

  • 7.3Making people awareISO/IEC 27001

    Was: Activity-level only. Audience is free text with no per-person link, so 'was this named employee made aware' cannot be answered.

  • 7.5Controlling documented informationISO/IEC 27001

    Was: Creation, versioning and approval are strong. Missing review cadence, classification, distribution record, retention and disposition, and any register of externally-originated documents.

  • 8.1Planning and controlling how the ISMS runsISO/IEC 27001

    Was: Recurring obligations and machine-collected checks are real evidence of planned activity. Missing process criteria, control of externally provided processes, and review of unintended changes.

  • 8.2Assessing risk at planned intervals, and when things changeISO/IEC 27001

    Was: Assessments are recorded as events with retained results, and the interval is planned rather than inferred. But a change-triggered assessment is one someone remembered to raise, and nothing in the product detects that a significant change occurred.

  • 8.3Carrying out the risk treatment planISO/IEC 27001

    Was: Per-risk treatment plan and status. No record of the results of implementation, which 8.3 requires be retained.

  • 9.1Monitoring, measuring, analysing and evaluatingISO/IEC 27001

    Was: Measurements are captured. Missing the methods that ensure valid results, who monitors, when results are analysed, and by whom (9.1 b–f).

  • 9.3Management reviewISO/IEC 27001

    Was: Sign-off is immutable and the required inputs are prompted. Two of the 9.3.2 inputs are not prompted for, and inputs are retyped rather than derived from records the product already holds.

  • 10.2Nonconformity and corrective actionISO/IEC 27001

    Was: Strong on correction, root cause and verification. Missing whether similar nonconformities exist elsewhere, a distinct effectiveness review, and a link to the resulting ISMS change.

  • 4.1Understanding the organization and what surrounds itISO/IEC 42001

    Was: Issues are captured as text. 42001 also asks you to determine the organization's role for each AI system (provider, developer, deployer or user) and nothing here records that, so a system you deploy and a system you build carry the same context entry.

  • 4.2Who has an interest, and what they requireISO/IEC 42001

    Was: One free-text field conflates needs with requirements, and there is no field for which requirements the management system will address. For AI this omission bites harder: the parties affected by an AI system are frequently not its customers, and nothing distinguishes the two.

  • 4.3Deciding what the AI management system coversISO/IEC 42001

    Was: The scope statement is an unversioned, unapproved column outside the document module, with no field for interfaces and dependencies. It also has no place to list the AI systems in scope, which is how a 42001 scope is normally read.

  • 5.2An AI policyISO/IEC 42001

    Was: Versioning and approval are strong. No flag identifies which document is the AI policy, and there is no record of it being communicated or made available. 42001 also expects the AI policy to be reconciled with other organizational policies, and nothing models that relationship.

  • 6.1.3Choosing controls and stating which applyISO/IEC 42001

    Was: The Statement of Applicability renders and hashes server-side, in this standard's own vocabulary. The seeded 42001 pack is a starting set rather than the full Annex A control list, so the check that no necessary control was omitted cannot yet be performed by the system.

  • 6.1.4Assessing what an AI system does to the people it touchesISO/IEC 42001

    Was: This has no counterpart in ISO 27001 and is the clause 42001 is really about. Impacts can be recorded as risks today, which is where an auditor will look, but there is no dedicated impact assessment holding the affected groups, the intended purpose and reasonably foreseeable misuse per AI system.

  • 6.2AI objectives and how they will be metISO/IEC 42001

    Was: Objectives are captured and measured. Missing what will be done, what resources are needed, who is responsible, and how results will be evaluated.

  • 7.3Making people awareISO/IEC 42001

    Was: Activity-level only. Audience is free text with no per-person link, so 'was this named employee made aware' cannot be answered.

  • 7.5Controlling documented informationISO/IEC 42001

    Was: Creation, versioning and approval are strong. Missing review cadence, classification, distribution record, retention and disposition, and any register of externally-originated documents.

  • 8.1Planning and controlling how the system runsISO/IEC 42001

    Was: Recurring obligations and machine-collected checks are real evidence of planned activity. Missing process criteria, control of externally provided processes, and review of unintended changes, the last of which matters more for AI, where a model can change behaviour without anyone changing the system.

  • 8.2Assessing AI risk at planned intervals, and when things changeISO/IEC 42001

    Was: Assessments are recorded as events with retained results, and the interval is planned rather than inferred. A change-triggered assessment is still one someone remembered to raise, and nothing in the product detects that a model, its data or its purpose changed.

  • 8.3Carrying out the AI risk treatment planISO/IEC 42001

    Was: Per-risk treatment plan and status. No record of the results of implementation, which this clause requires be retained.

  • 8.4Carrying out the impact assessment, and keeping the resultISO/IEC 42001

    Was: The operational counterpart of 6.1.4, and it inherits the same gap: the result is retained as a risk record rather than as an impact assessment in its own right, so an auditor asking for the assessment of one named AI system is handed a filtered risk list.

  • 9.1Monitoring, measuring, analysing and evaluatingISO/IEC 42001

    Was: Measurements are captured. Missing the methods that ensure valid results, who monitors, when results are analysed, and by whom.

  • 9.3Management reviewISO/IEC 42001

    Was: Sign-off is immutable and the required inputs are prompted. Inputs are retyped rather than derived from records the product already holds, and the prompts are the shared Harmonized Structure ones rather than 42001's own.

  • 10.2Nonconformity and corrective actionISO/IEC 42001

    Was: Strong on correction, root cause and verification. Missing whether similar nonconformities exist elsewhere, a distinct effectiveness review, and a link to the resulting change to the management system.

1 August 2026

  • 4.4The ISMS and the processes that make it upISO/IEC 27001

    Was: No process register and no record of how the processes interact.

  • 7.1The resources the ISMS needsISO/IEC 27001

    Was: Not modelled.

  • 7.4Communicating about securityISO/IEC 27001

    Was: No record of what is communicated, when, to whom, or how.

Not closed, reclassified

2 entries changed because we decided the gap was a limit of any software rather than a shortfall of ours. Counting that as delivery would be the same overclaim in the other direction, so it is listed here instead of above.

  • 5.1Leadership actually owning the system3 August 2026

    Was: All eight demonstrations are answered from records held elsewhere in the ISMS, so the evidence is assembled rather than asserted. But no software can show that top management personally did any of it. An auditor establishes that by interviewing them.

  • 5.1Leadership actually owning the system3 August 2026

    Was: The demonstrations are answered from records held elsewhere in the management system, so the evidence is assembled rather than asserted. But no software can show that top management personally did any of it. An auditor establishes that by interviewing them.

Why this page has nothing else on it

Features shipped are easy to list and prove little, because every vendor's changelog is full of them. Gaps admitted in public and then closed are the only entries that cost something to publish, because they require having said the thing was missing while it was. The register is where the current state lives, and it is still the honest one to read first.