ISO/IEC 27001:2022 — Every Control Change That Matters (and the Audit Evidence Behind Each One)

The 2022 revision of ISO/IEC 27001 is the most consequential update since 2013. Annex A controls were restructured from 14 domains into four themes — Organizational, People, Physical, and Technological — and 11 new controls were introduced to address modern realities such as cloud services, threat intelligence, and secure coding.

If your ISMS still carries 2013 muscle memory, surveillance audits in 2026 will expose it. This piece is the practical map every CISO and GRC engineer should be using to defend the certification without re-running the entire implementation.

The 11 new controls — and where they hurt the most

The 11 new controls reflect the threat landscape after 2017 and the supply-chain breaches of 2020. They are not bolt-ons. Each one ties back to either an Identify/Protect/Detect/Respond function in NIST CSF 2.0 or to a clause in the EU NIS2 directive — meaning the same evidence often satisfies more than one regulator.

What auditors will probe first — three controls, 60% of findings

From dozens of recertification audits we have shepherded through 2024 and 2025, three controls account for over 60% of nonconformities. Each one fails for the same reason: the policy exists but the daily evidence does not.

1. 01A.5.7 Threat Intelligence — auditors expect a documented intake (feeds, ISACs, government bulletins), an internal triage workflow with named owners, and evidence that intelligence reaches detection engineering or vulnerability management within a defined SLA. A 'we read CISA alerts' answer is a major nonconformity.
2. 02A.8.9 Configuration Management — they will ask for the configuration baseline of a sampled production system, then request the drift report for the past 30 days. If you cannot produce both within minutes, the finding writes itself. Drift detection is now the load-bearing technical control.
3. 03A.8.28 Secure Coding — auditors will sample three pull requests and ask for the linked security review evidence: SAST result, peer review comment chain, and the secure-coding standard the team is held to. 'We use SonarQube' is not an answer; the evidence trail is.

Evidence-by-design — the pattern that scales

The single biggest predictor of a clean audit is whether each control produces an artifact in the normal course of operations — not when the audit is announced. Below is the minimum evidence cadence we recommend per control type.

A repeatable evidence query — the auditor-friendly view

Below is the kind of saved query we deploy in client SIEMs to give an auditor a one-click answer. It surfaces every secure-coding gate decision, with pull request, reviewer, and SAST verdict, for any sampled time window. Build the equivalent for each high-difficulty control and the audit conversation changes shape entirely.

-- Auditor-ready evidence: Secure Coding (A.8.28)
-- Returns one row per merged PR with the security gate verdict.

SELECT
  pr.merge_ts,
  pr.repo,
  pr.number,
  pr.author,
  reviewer.login   AS security_reviewer,
  sast.tool        AS sast_tool,
  sast.verdict,                 -- pass | warn | block
  sast.findings_high,
  sast.findings_critical,
  policy.standard  AS coding_standard
FROM   pull_requests           pr
JOIN   pr_reviews              reviewer ON reviewer.pr_id = pr.id
JOIN   ci_results              sast     ON sast.pr_id     = pr.id
                                       AND sast.kind      = 'sast'
JOIN   appsec_policy_snapshot  policy   ON policy.repo    = pr.repo
                                       AND pr.merge_ts BETWEEN policy.from_ts
                                                           AND policy.to_ts
WHERE  pr.merge_ts >= :sample_window_start
  AND  pr.merge_ts <  :sample_window_end
ORDER  BY pr.merge_ts;

Mapping 27001:2022 to your other obligations

Most 27001 programs already carry a parallel reporting obligation — SOC 2, NIST CSF 2.0, NIS2 in the EU, DORA for financial services. The 2022 revision was deliberately structured to map cleanly to these. Maintaining a single 'risk register of record' that ties each significant risk to its 27001 control AND its NIST CSF sub-category collapses the dual-framework reporting burden by 40–60% in our experience.

• 0127001:2022 → NIST CSF 2.0: published informative-references mapping, defensible for board reporting
• 0227001:2022 → SOC 2: TSC mapping is direct for Security; CC1–CC9 satisfied largely by Annex A.5 + A.8
• 0327001:2022 → NIS2 (EU): A.5.30 + A.5.7 + A.8.16 cover the heart of NIS2 Article 21 requirements
• 0427001:2022 → DORA: ICT risk management chapter aligns with 27001 Clauses 6 + 8 plus A.5.30

A 90-day uplift plan that survives the audit

1. 01Days 0–15 — Run the official Annex B mapping from 2013 to 2022 across your existing Statement of Applicability. Identify the 11 new controls and assign each to a single accountable owner with a named technical implementer.
2. 02Days 15–45 — Implement evidence pipelines for the three highest-difficulty controls (A.5.7, A.8.9, A.8.28) using the cadence table above. Wire the artifacts into a tagged folder or GRC system the auditor can sample.
3. 03Days 45–75 — Stand up the remaining 8 new controls. For each, write the one-page operating procedure, run it once for two weeks, then prove the evidence cadence is producing artifacts.
4. 04Days 75–90 — Internal audit dry-run with an external assessor or your own internal audit function. Treat the rehearsal findings as binding; close all of them before the certification body arrives.

Closing — controls-uplift, not re-implementation

The most common failure mode we see is treating 27001:2022 as an excuse to re-implement the entire ISMS. It is not. The Clauses 4–10 management system requirements are largely unchanged. The work is in Annex A, and most of it is in the 11 new controls. Map carefully, instrument the evidence, and the recertification becomes a 90-day engineering project — not the 9-month consulting engagement you remember from 2014.