The Annex A remap is not a one-to-one exercise

I took an ISMS from ISO 27001:2013 to 27001:2022 and out the other side with three observations and zero nonconformities. The single biggest risk in that project was a misconception I see repeated constantly: that the Annex A remap is a mapping exercise.

It isn't. Treating it as one is how transitions produce findings lists.

What people think the remap is

The 2013 standard had 114 Annex A controls across 14 domains. The 2022 revision has 93 across four themes — organizational, people, physical, and technological. Because the count went down, the intuitive reading is that controls were consolidated, and the job is to find where each old control landed.

So teams build a spreadsheet. Old control on the left, new control on the right, tick each row as it's matched. When every row has a match, the remap is declared done.

That spreadsheet is where the trouble starts.

What the remap actually is

Controls didn't just merge. They merged, split, changed scope, and in eleven cases appeared for the first time. Four things happen in the transition, and only one of them is a simple match:

• Merges. Several 2013 controls collapse into one 2022 control. Your existing evidence for each of them now has to satisfy a single control statement that may be broader than any of the originals.
• Splits. One old control becomes several. Evidence that covered it fully may now cover only part.
• Scope changes. Same subject, different requirement. This is the dangerous category, because the control looks familiar and the mapping looks obvious.
• New controls. Threat intelligence, cloud service security, ICT readiness for business continuity, data masking, data leakage prevention, and others. There is nothing to map from. You are implementing, not transitioning.

The failure mode

A tidy mapping spreadsheet creates a feeling of completeness that the underlying work hasn't earned. Every row has a match, so the remap looks finished. Then Stage 2 arrives and the auditor doesn't ask about your mapping. They ask how a specific 2022 control operates, and sample evidence against that control's requirement.

Where a control's scope quietly widened, the evidence you carried forward covers part of it. Where a control split, you have one artifact where two are needed. Where a control is new, you may have nothing but a mapping row pointing at the nearest old control that felt similar.

None of that shows up in the spreadsheet. All of it shows up in the audit.

What I'd do instead

Work forward from the 2022 standard, not backward from 2013. Take each of the 93 controls, read what it actually requires, and ask what evidence in your environment satisfies it. Use the mapping to find candidate evidence, never to conclude that a control is covered.

Separate the new controls out immediately. They aren't a remap task, they're an implementation project, and they need real time. Discovering that in month four is how transitions overrun.

Write the Statement of Applicability last. The SoA is where an auditor looks first, and every exclusion needs a defensible justification. Writing it before you've worked through control-by-control means writing justifications for positions you haven't tested.

Confirm your certification body's transition expectations early. Requirements around audit scheduling and evidence periods vary, and they drive your calendar more than your own workplan does.

What it costs to get right

My transition took over a year. Most of that was not technical difficulty — it was the absence of an executive sponsor who could make a risk acceptance decision, compounded by running an ISO 20000-1 service management system in parallel. Under normal conditions with a decision-maker available, five to six months is a realistic target for a small or mid-sized organization.

What the year did buy was a clear view of where transitions actually fail. It isn't the mapping. It's assuming that the mapping was the work.