The transition window has closed. IAF MD 26 set 31 October 2025 as the deadline for certified clients to complete their transition to ISO/IEC 27001:2022. Many organisations updated documents, remapped controls and changed their certificate. The version question is therefore settled. The operational question is not.
Note: General professional guidance; not legal advice or a certification or audit guarantee.
That question is whether day-to-day operation shows that the risk assessment, treatment plan, Statement of Applicability, controls, internal audits and management review tell the same story. An updated policy can be technically correct while saying nothing about whether an access review happened on time, whether an exception was assessed or whether management turned an identified weakness into a decision.
Post-transition operational readiness is not another migration project. It is the ability to connect a management decision to its risk context, implemented measure and defensible evidence for the relevant period. An organisation that changed terminology and control numbers may have a polished façade. For a management system, that is about as useful as a freshly labelled fuse box when nobody knows which circuit still works.
“Transition complete” can be a dangerous signal
A project can close while the ISMS continues to carry unresolved assumptions. That is not always simple neglect. Transition was often organised as a bounded exercise: compare standards, adjust the SoA, revise documents and pass the audit. Live operation follows different rhythms. Suppliers change, cloud services expand, responsibilities move and business processes acquire new dependencies. Unless those events enter risk assessment and governance reliably, the revised documentation starts ageing on its first day.
One common break appears when risk treatment has been updated but the SoA does not consistently explain inclusion and exclusion decisions. Another occurs where new or merged controls appear in the mapping while processes, owners and evidence remain unchanged. Internal audits can also focus on the wrong object: they confirm that a document exists without testing control design, implementation or operation across the period. Metrics look equally professional until someone asks which value prompts which person to make which decision.
A mapping workbook full of green cells can be remarkably comforting. Unfortunately, a control does not accept colour as evidence of effectiveness; otherwise conditional formatting would be a certification body.
Moving from a standards map to a decision chain
ISO/IEC 27001 is a management system standard. ISO’s official overview emphasises establishing, implementing, maintaining and continually improving the ISMS. After transition, another broad standards map matters less than the consistency of connected management decisions.
Context, risk and decision
Changes in objectives, interested parties, regulatory requirements, technology and externally provided services need a route into risk assessment. Not every change creates a new top risk. Every material change does, however, need a traceable decision: assessed and found not relevant, accepted for treatment or escalated.
The mechanism starts not in the risk register but where change originates. An architecture board approves a new cloud service. Procurement renews a critical contract. A business team relocates a process. Operational readiness depends on whether those events have a defined handover into the ISMS. Without that handover, a risk register may be formally current while remaining operationally behind events.
Consider a clearly hypothetical example. A company moves a customer-critical service to a new platform. The project documents function, cost and schedule but does not assess the changed dependencies in the ISMS. Months later, management review still contains the old availability assumption. The issue is not merely a missing register entry. An outdated assumption affects risk evaluation, treatment, testing and escalation thresholds. Once found, several decisions may need to be checked retrospectively.
Risk, treatment and the SoA
The SoA is not a decorative control catalogue. It needs to align with selected risk treatment and make necessary control decisions traceable, including the comparison with the reference set. IAF MD 26 highlights this comparison and the potential need to update treatment plans if a necessary control was inadvertently omitted.
In practice, an SoA decision needs more than “applicable” or “not applicable”. It should reveal the treatment relationship, accountable process and actual implementation state. If the risk changes, the organisation needs to ask whether treatment and control decisions still hold. If a control changes, it must ask which treatments depend on it. That feedback loop stops the SoA and the risk register from developing separate versions of the truth.
Control, operation and evidence
A policy demonstrates an expectation, not repeated behaviour. For every material control, the organisation should know which operational event produces evidence, who reviews it, which period it covers and which deviation triggers action. Examples include access reviews, restore tests, supplier monitoring and security-event handling.
The important distinction is between an artefact and the statement it supports. An exported user list shows accounts. It does not automatically demonstrate that business owners reviewed access, assessed exceptions and removed inappropriate privileges. A restore record may show that someone started an activity. Whether the result met the defined process objective only becomes clear when the review criterion and assessment are available.
In another hypothetical operating scene, a control owner receives a user list at quarter-end. He confirms the review because every name looks plausible. Two months later, the organisation finds a technically privileged account without an active owner. The list existed, and so did the review. What was missing was a criterion for orphaned privileged accounts and documented handling of the result. That is the difference between evidence of activity and evidence of control.
Deviation, cause and improvement
Findings, incidents, metric exceptions and missed objectives must enter a controlled improvement process. The test is not whether every deviation disappears immediately. It is whether cause, risk, owner, due date, effectiveness review and escalation are connected.
An action to “repeat training” may be appropriate when lack of knowledge caused the problem. It is weak when unclear process design, unsuitable responsibilities or a technical constraint produced the behaviour. Post-transition readiness therefore does not require the greatest possible number of closed tickets. It requires defensible decisions about causes. A ticket status is, after all, an administrative condition rather than a law of nature.
Audit readiness is a time-series problem
Auditors do not inspect only today’s state. They test whether the system operated during the period under review. A record completed retrospectively in July does not repair a review that failed to happen in February. Evidence should therefore be generated by operational cadence rather than collected shortly before the audit.
A lean evidence register can connect the control and process objective with the accountable role, expected artefact or system signal, frequency, period covered, repository, review criterion, result and, where necessary, exception and approval. It need not become another large platform. What matters is an unambiguous, accessible and repeatable relationship.
The benefit is not more documentation. It is earlier visibility. If monthly evidence is missing, the gap appears that month rather than during audit preparation. If an artefact exists but no review result accompanies it, the owner can correct the process. If the same exception recurs, the organisation can see that the current action has not been effective enough.
Retention also needs a professional rationale. Not every log and export must be collected indefinitely. The relevant period, purpose, access and integrity should fit the control and audit logic. An indiscriminate evidence archive mainly creates search work. An auditor waiting three hours for a download has not acquired three additional hours of assurance.
Treat the climate amendment proportionately
ISO lists ISO/IEC 27001:2022/Amd 1:2024 as the climate-action amendment. The addition belongs in the assessment of organisational context and interested-party requirements. Organisations should be able to show that they considered whether climate change is relevant to their ISMS and whether interested parties have climate-related requirements.
That does not automatically require a separate climate risk register or turn every weather event into an information security risk. Relevant issues could include site dependencies, cooling, power, supply chains, availability or customer requirements. If the assessment finds no material relevance, that conclusion still needs a defensible rationale. The amendment is a context signal, not a licence for climate theatre inside the ISMS.
The useful assessment route is the same as for other context factors: identify possible relevance, evaluate effects on scope and risk, consider interested-party requirements and record the decision. If treatment follows, it needs to reach controls, operation and evidence. If it does not, the rationale should show which dependencies were considered. A generic “not relevant” saves two lines today and tends to generate five questions tomorrow.
A focused post-transition review
Instead of walking through every requirement again, use a sample-based vertical slice. Select three to five material risks or business services. Follow each path from relevant context through risk assessment and approval into treatment and the SoA decision. Then determine which controls actually operate, which evidence covers which period and what metrics, internal audits or incidents say about effectiveness. The final question is what reached management review and which decision followed.
A hypothetical slice might begin with a critical supplier. The organisation checks why the service is material, which dependency appears in the risk description and which treatment was approved. It then examines the supplier review, available evidence, identified deviations and escalation. If a repeatedly late assessment never appeared in management review, the break does not sit only in supplier management. The information chain to management is incomplete.
A vertical slice works better than another broad document review because it tests handovers. Those handovers are where inconsistency tends to appear: between change and risk, risk and the SoA, control and evidence, or deviation and decision. The method therefore reveals not only whether the organisation looks ready for an audit but whether the ISMS supports management decisions.
The sample should deliberately include an uncomfortable path: an overdue action, recurring exception or control with incomplete evidence. A review composed only of showcase cases mainly demonstrates the selection skills of the review team. The harder case reveals whether the system keeps uncertainty visible, forces an authorised decision and later tests whether the follow-up action was effective.
Management then receives no artificial claim of completeness but a defensible statement about the governance mechanism. If the same break appears across several samples, it points to a systemic handover problem rather than three unrelated control failures. The decision no longer belongs to the individual control owner alone. It may concern process design, resources, escalation or the quality of management information. Translating an isolated finding into a system decision is what separates operational readiness from a document repository that was tidied shortly before the audit.
What management should decide before the next audit cycle
Before the next audit, management should not ask for a generic assurance that the organisation is “ready”. A bounded decision view is more useful. Have outdated references been removed from live templates under change control? Do risk treatment, the SoA, control ownership and actual processes align for material paths? Is there period-based evidence with a review result rather than an artefact collection? Does internal audit test implementation and operation on a risk basis?
The treatment of change matters just as much. Changes in services, suppliers and technology should enter the ISMS through a planned process. Climate relevance and climate-related interested-party requirements need proportionate assessment and reasoning. Management review should expose open deviations, residual uncertainty and decision-ready options. Overdue actions require defined escalation thresholds.
This turns a checklist into a governance task. Management does not decide on every individual evidence file. It decides priority, risk acceptance, resources, escalation and whether the system is effective. Good operational readiness does not reduce that responsibility. It makes the responsibility visible early enough to act.
Conclusion and the A-R-C perspective
After 31 October 2025, the version question is settled. The operational question remains: can the organisation demonstrate that its ISMS makes, executes, tests and improves decisions consistently over time?
A-R-C makes information security governable, auditable and management-ready. A Post-Transition Operational Readiness Review connects selected risks to the SoA, controls, evidence, internal audit and management review. The outcome is not a certification promise. It is a prioritised view of the breaks that should be addressed before the next audit or management decision point.
Scope and limitations
This article does not reproduce standard text and does not replace the licensed standard, certification-body guidance, legal advice or independent assurance. It provides no certification or audit guarantee. Audit criteria, samples and findings depend on the actual scope and responsible certification body.
Primary sources
- International Accreditation Forum, IAF MD 26:2023, Transition Requirements for ISO/IEC 27001:2022, particularly the timescale and transition process: https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf (accessed 2 August 2026)
- ISO, official overview of ISO/IEC 27001:2022: https://www.iso.org/standard/27001 (accessed 2 August 2026)
- ISO, ISO/IEC 27001:2022/Amd 1:2024, Climate action changes: https://www.iso.org/standard/88435.html (accessed 2 August 2026)
About the author
Andreas Rühl supports organizations as an interim CISO and ISMS/GRC advisor. His focus is making information security manageable, auditable and fit for management decisions.