ISO 27001:2013 certificates have expired — including the ones with later dates on them

ISO/IEC 27001:2022 was published on 25 October 2022, and the International Accreditation Forum set a transition period of three years. IAF MD 26 — the mandatory document that accreditation bodies and certification bodies are themselves bound by — states that all certifications based on ISO/IEC 27001:2013 expire or are withdrawn at the end of that period.

That is not guidance and it is not per-certificate discretion. It is the instruction your certification body operates under, which is why the outcome was uniform across bodies and countries rather than something an individual auditor could soften.

The transition audit that was available during the window — the cheaper, add-on assessment that moved an existing certificate to the new edition — went with it. There is no late transition.

This is the part that catches people, and it is worth being blunt about because the physical document actively misleads.

Certificates run on three-year cycles that began whenever your certification decision was made, so a 2013-edition certificate issued in, say, early 2024 carries a printed expiry date well beyond October 2025. That date is now irrelevant. The withdrawal applies to all certifications based on the 2013 edition regardless of what is printed on them.

The practical consequence is a document in your sales pack, your trust page or your supplier questionnaires that looks valid to anyone who reads it and is not. If a customer calls your certification body to verify it — which is exactly what a careful procurement team does — they will be told it is no longer valid. That conversation is much better had by you, first.

Here is the part most summaries skip, and it is the expensive part. An organisation whose certificate lapsed is treated by a certification body as a new client. That means a full initial certification audit — Stage 1 and Stage 2 — rather than the shorter recertification audit an existing holder would have had.

So the cost is not "a transition audit, a bit late". It is the full initial audit sequence, with the planning, the fees and the elapsed time that implies, and the Stage 2 observation of controls actually operating.

The honest good news sits on the other side of that ledger, and it is substantial: the preparation is nothing like a first implementation. The management system clauses — context, leadership, planning, support, operation, evaluation, improvement — are substantially unchanged between the two editions. Your risk assessment methodology, your evidence, your internal audit and management review records and your habits all carry. What genuinely needs doing is remapping the Statement of Applicability onto the restructured Annex A, and closing the controls that are new rather than renamed.

Treat it as a re-audit of a system you already run, not a rebuild. But budget for the full initial audit, because that is what you are buying.

The 2013 edition had 114 controls in 14 clauses; the 2022 edition has 93 in four themes. The reduction came from merging 24 controls, not from dropping requirements, and 11 controls are new.

Because controls were merged, several old rows in your Statement of Applicability collapse into single new ones that are often broader than either original — so an implementation status inherited from the old row can be wrong in the new one. The eleven new controls have no predecessor to inherit from at all, and they are where most organisations find genuine gaps rather than paperwork: threat intelligence, cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding.

A lookup table from old numbers to new ones will get you started and will not get you finished. Treat the SoA as a fresh determination that happens to reuse most of your existing evidence.

This cuts both ways, and the verification side is worth knowing because a lot of 2013 certificates are still circulating in vendor files and on trust pages.

Read the edition, not just the standard. A certificate saying ISO/IEC 27001:2013 evidences nothing today, however recent its printed dates look. Then read the scope statement, which is the part that decides whether the certificate covers the service you are actually buying — a certificate scoped to a head office tells you little about a product hosted elsewhere.

Then verify rather than assume. Accredited certificates are traceable: the certification body maintains a register or will confirm validity on request, and the accreditation body behind them does too. A certificate is a claim about a system, and the claim is checkable in about five minutes.

And ask for the Statement of Applicability. The certificate names a scope and a standard; the SoA is what tells you which controls the organisation actually determined it needed and which it excluded.

If your certificate lapsed: stop circulating it, and say so before someone discovers it. A supplier who reports the position and shows a dated plan to re-certify is in a materially better commercial situation than one whose customer finds a withdrawn certificate during a renewal review.

Then work out the gap honestly. In most organisations that were genuinely operating a 2013 management system, the system is still running — it is the certificate that stopped, not the controls. Establish what remapping the Annex A changes requires, confirm internal audit and management review are current, and talk to a certification body about dates early, because the initial audit sequence takes longer to schedule than a recertification would have.

If you never transitioned because the system had quietly stopped being maintained, that is a different and more honest starting point — and worth saying internally now rather than discovering at Stage 1.