ISO 27001 nonconformities: why firms fail Stage 2

The moment an ISO 27001 certification is decided takes less than a minute. The auditor opens the Statement of Applicability, picks a control marked "fully implemented" at random and asks for evidence that it worked over the past three months. If the answer is "that is how we work, but we do not document it", you have just earned a nonconformity. If it repeats across several controls, you have earned a major one — and the certificate slips.

The context makes it more uncomfortable. As of 31 December 2024 Romania held 792 valid ISO/IEC 27001 certificates against 12,065 ISO 9001 certificates (ISO Survey 2024), so most companies entering the process today enter it without any internal reflex — while over 6,000 entities carry NIS2 obligations and more corporate clients demand certification contractually. Globally, ISO Survey 2024 counts 96,709 valid certificates. The good news: the reasons firms fail are predictable and almost all of them are fixable before the audit.

You do not fail for doing nothing. You fail for not being able to prove it

The difference between a company that certifies on the first attempt and one that collects a major nonconformity is rarely the actual level of security. Both usually have firewalls, backups, antivirus and competent people. The difference is that one can lay out, in order, the chain of decisions and the evidence behind them, and the other cannot.

The distinction is worth understanding because the consequences are very concrete. A minor nonconformity is an isolated deviation: you get an agreed deadline for correction, you submit evidence of closure and the certification process moves on. A major nonconformity means a requirement is entirely absent or a process has broken down systematically — and it blocks certification until it is remediated and verified. Certification bodies typically allow 30–90 days for corrective action and schedule a follow-up audit, usually within 90 days.

Translated into business terms: a major nonconformity is not a technical remark, it is a lost quarter. Usually the exact quarter in which you were supposed to sign the contract that made you start certifying in the first place.

The areas where nonconformities appear are remarkably consistent from one audit to the next:

• No clear risk assessment methodology — assessments done "from experience", with no written criteria (clause 6.1.2).
• Risk treatment without evidence: decisions taken, but no records that the measures were actually implemented (clause 6.1.3).
• Internal audit and management review missing, incomplete, or not covering all ISMS processes (clauses 9.2 and 9.3).
• A Statement of Applicability that is incomplete, outdated or lacks justification for including and excluding controls (clause 6.1.3 d).
• No performance indicators for the system — nobody measures whether security is working (clause 9.1).
• An incident management process that exists only as a document, with no records of incidents actually handled (control A.5.24).
• Access control without periodic reviews: accounts of former employees, rights accumulated over time (controls A.8.2 and A.8.3).
• Supplier security left untreated — no classification, no security requirements in contracts (control A.5.19).
• Inconsistent training and awareness, with no record of who attended and when (control A.6.3).
• An incomplete asset inventory, or one with no assigned owners (control A.5.9).

Notice the pattern: most of these points are not technical. They are management-system issues. They are solved with discipline and records, not with a hardware budget — which is why companies with excellent IT sometimes fail harder than companies with modest but well-documented IT.

The auditor is not assessing your security. They are assessing traceability

This is the reframe that changes the rest of your preparation. ISO 27001 does not certify a firewall, a cloud provider or a configuration. It certifies an information security management system. The auditor is not really asking "are you secure?" but "can you demonstrate that this decision was made rationally, applied in practice and reviewed periodically?".

In practice, every control has to sit in a chain with five links: an identified asset, an assessed risk against it, a decision recorded in the Statement of Applicability, a control actually operating, and dated evidence that it worked — plus a review confirming the chain is still valid. Break a single link and the control disappears from the auditor point of view, no matter how well it is configured technically.

A control without dated evidence is not a control. It is an intention.

That chain also explains the most common cause of major nonconformities at Stage 2: a Statement of Applicability that overstates reality. You mark a control as "fully implemented" because the policy exists and the intent is clear, and the auditor samples precisely those claims. An honest SoA that says "partially implemented, due next quarter" is infinitely safer than an optimistic one: the first shows a system that knows itself, the second shows a system that does not know what it is doing.

The second SoA trap is the missing link to risk. A table with 93 ticked controls and no reference to the risk register tells the auditor you filled in a template. They want to see the path in reverse: this control exists because this risk was assessed at this level, and the mitigation cost was justified.

Recent changes that can catch you off guard

The 2022 version reorganised Annex A into 93 controls grouped in four themes, down from 114 in the old structure, and introduced 11 new controls. Companies starting from a 2013-era SoA template frequently omit exactly those new controls. All 93 must be explicitly addressed — including the ones you exclude, which need a written justification, not an empty cell.

The transition period ended on 31 October 2025. Certificates issued against ISO 27001:2013 expired on that date. If you missed the deadline you are no longer doing a certificate "update": you re-enter the process as a new organisation, with a full initial audit, Stage 1 and Stage 2. It is worth checking which version your certificate is issued against before promising anything to a client.

February 2024 also brought Amendment 1, which touches clauses 4.1 and 4.2: the organisation must determine whether climate change is a relevant issue for it, and take into account that interested parties may have climate-related requirements. The practical impact is small if you already run a serious context analysis — but the absence of a documented determination is exactly the kind of gap an auditor records without hesitation.

The eight things to do before Stage 2

Order matters: the first four points close most major nonconformities, the last four stop minor ones from piling up.

1. 1Re-read the SoA line by line and downgrade every optimistic status. Any control marked "fully implemented" for which you cannot produce evidence in 60 seconds becomes "partially implemented", with a deadline and an owner.
2. 2Link every included control to a concrete risk in the register, assessed on impact, likelihood and mitigation cost. Every excluded control gets a written justification of two or three lines.
3. 3Collect dated evidence from the last three months for the controls declared operational: logs, reports, meeting minutes, tickets, attendance lists. An evidence pack organised by control shortens the audit and changes the tone of the conversation.
4. 4Run a real internal audit covering all ISMS processes and a sample of controls, then hold the management review with every input the standard requires and record the decisions taken. Clauses 9.2 and 9.3 are among the most frequently missed precisely because they look like formalities.
5. 5Define three to five performance indicators for the system and measure them for at least one quarter before the audit. Without history, clause 9.1 stays a promise.
6. 6Test the processes that exist only on paper: simulate an incident and record how it was handled, run a full access rights review, check the continuity plan. Untested processes are the first to collapse under questioning.
7. 7Check the supplier chain: who has access to your data, what security requirements sit in the contract, when they were last assessed.
8. 8Close the findings from your internal audit with root cause analysis, not with a patch on the symptom. External auditors frequently check exactly the quality of previous corrective actions.

What preparation looks like in practice

Our ISO 27001:2022 Implementation Kickstarter package, available in the package shop, is built exactly around this traceability chain: 14 prioritised Annex A controls implemented, a risk register assessed on impact × likelihood × mitigation cost, a Statement of Applicability consistent with that register, more than 8 policies (security, access, incident response, business continuity) and a simulated internal audit. Duration ranges from 3-4 weeks for an environment under 50 devices to 8-12 weeks for organisations above 100 devices.

The piece that changes the outcome most is the simulated internal audit, run like a certification audit: the same questions, the same evidence requests, the same sampling. It is far cheaper to hear "I cannot prove that" from us than from the certification body. The rest of the preparation rests on our cybersecurity practice, because a control that is documented but poorly operated is still a nonconformity.

In the last 30 days before the audit, the short list looks like this:

• Leave enough time between Stage 1 and Stage 2 — the usual recommendation is at least six weeks, so you can close what Stage 1 surfaced.
• Confirm that the approved SoA version is the current one and that approval dates are visible.
• Assign an owner for each major area who can open the evidence in real time.
• Check that all 93 controls have a status and a justification, with no empty cells.
• Document your determination on the relevance of climate change, per Amendment 1.

Conclusion

ISO 27001 certification is not won with more security, but with demonstrable security: every control tied to a risk, operating in reality and backed by dated evidence. If you have an audit scheduled, or you are just building the system and want an honest opinion on where you stand, let us talk for 30 minutes — book a conversation and we will walk through your SoA exactly the way the auditor will.