ISO/IEC 27001:2022 After the Transition: What Auditors Look For and How to Stay Audit-Ready

Since 31 October 2025, every accredited ISO/IEC 27001 certificate refers to the 2022 edition. With transition audits behind them, certification bodies are testing whether the new controls actually operate.

ISO/IEC 27001:2022 was published on 25 October 2022 with a three-year transition period ^[3]. That period ended on 31 October 2025. Certificates issued against the previous edition (ISO/IEC 27001:2013, published in Europe as EN ISO/IEC 27001:2017) expired at that date and are no longer valid ^[3]. One year on, most certified organisations have completed their first surveillance cycle under the 2022 edition. This article looks at where audit attention has moved and how to keep an information security management system (ISMS) audit-ready throughout the year.

A quick recap of what changed

Clauses 4 to 10

The management system clauses were aligned with ISO’s harmonised structure. The changes are modest but auditable ^[1]:

• 4.2: determine which requirements of interested parties will be addressed through the ISMS.
• 4.4: the ISMS includes the processes needed and their interactions.
• 6.2: information security objectives must be monitored.
• 6.3 (new): changes to the ISMS must be carried out in a planned manner.
• 8.1: establish criteria for processes and control externally provided processes, products and services relevant to the ISMS.
• 9.3: management review considers changes in the needs and expectations of interested parties.

The climate amendment

In February 2024 ISO published Amendment 1 to ISO/IEC 27001:2022, “Climate action changes” ^[2]. It requires organisations to determine whether climate change is a relevant issue in their context (clause 4.1) and notes that interested parties can have climate-related requirements (clause 4.2). Auditors generally expect to see that the question has been considered and the conclusion documented, not a climate programme.

Annex A

Annex A was restructured from 114 controls in 14 domains to 93 controls in four themes: organisational, people, physical and technological ^[4]. Most controls were merged or renamed. Eleven are new ^[4]:

Control	Title
5.7	Threat intelligence
5.23	Information security for use of cloud services
5.30	ICT readiness for business continuity
7.4	Physical security monitoring
8.9	Configuration management
8.10	Information deletion
8.11	Data masking
8.12	Data leakage prevention
8.16	Monitoring activities
8.23	Web filtering
8.28	Secure coding

Implementation guidance for each control is in ISO/IEC 27002:2022 ^[5].

Transition audits asked whether the new controls were in your Statement of Applicability; surveillance audits ask whether they work.

Where audit attention has moved

During transition audits, auditors mainly checked that the Statement of Applicability (SoA) reflected the new Annex A, that the risk treatment plan had been updated and that the new controls had been considered. Surveillance and recertification audits ask a different question: is the control operating, and can you show it?

The following areas are where gaps typically show up, because the controls are new and evidence is not always produced as a by-product of daily work.

Threat intelligence (5.7)

Subscribing to a feed is not the control. Auditors look for how threat information is collected, analysed and acted upon: for example, a periodic threat summary that has led to a change in risk ratings, detection rules or patch priorities. Smaller organisations can rely on sources such as national CSIRT advisories, provided they show that the information is reviewed and used.

Cloud services (5.23)

The control covers the lifecycle of cloud use: acquisition, use, management and exit. Expect questions on how cloud services are approved, how the shared responsibility model is documented for key providers, how provider security is reviewed and what exit arrangements exist. This links directly to supplier controls 5.19 to 5.22.

Data leakage prevention (8.12)

The standard does not require a particular DLP product. It requires measures proportionate to the risk, applied to systems, networks and devices that process sensitive information. Auditors usually want to see the link between data classification, the channels considered (email, web uploads, removable media, cloud sharing) and the technical or procedural measures chosen, plus evidence that alerts are reviewed.

Configuration management (8.9) and monitoring activities (8.16)

Both require ongoing evidence: defined secure baselines, a way to detect drift, and monitoring of networks, systems and applications for anomalous behaviour with documented review. These controls fail when they exist only as policy statements.

ICT readiness for business continuity (5.30)

Auditors look for recovery objectives tied to business impact analysis and evidence that ICT recovery has been tested, not only planned.

Secure coding (8.28) and information deletion (8.10)

For organisations that develop software, auditors expect secure coding principles, code review or testing evidence, and handling of third-party libraries. For deletion, they look at retention rules and proof that data is deleted when no longer required, including at suppliers.

Clause 6.3 and change

A frequent finding is that significant changes, such as a new cloud platform, an acquisition or a reorganisation, were made without assessing their effect on the ISMS. A simple change record that references the ISMS addresses this.

Keeping the ISMS audit-ready year-round

Build a control calendar

Assign every applicable control an owner and a review frequency, such as monthly, quarterly or annually. Access reviews, backup restore tests, supplier reviews, vulnerability scans and threat summaries then produce evidence on schedule rather than in the weeks before an audit.

Collect evidence continuously

Store evidence where it is generated, with a date and owner, and link it to the control it supports. Where controls are shared with other frameworks, such as NIS2 risk-management measures or DORA ICT requirements, link the same evidence to each requirement instead of producing it twice.

Keep the risk register live

Review risks when something changes, not only once a year: new threats, incidents, suppliers or services. Auditors check that risk assessment results flow into the SoA and the treatment plan.

Spread the internal audit programme

Clause 9.2 requires a planned internal audit programme ^[1]. Covering a few clauses and control themes each quarter gives a full cycle over the year, finds issues early and gives the certification body a credible picture of self-assessment.

Run a meaningful management review

Clause 9.3 lists the required inputs ^[1]. A short, well-evidenced review with decisions and actions is more valuable than a long presentation without outcomes.

Track corrective actions to closure

Nonconformities, incidents and audit findings should all feed one corrective action log with root cause, owner and due date. Open actions from the previous audit are among the first things an auditor checks.

Closing note

Secrato helps organisations manage frameworks such as NIS2, DORA and ISO 27001 in one EU-hosted platform, with shared controls, evidence and audit trails.