ISO/IEC 27001 common mistakes: the ten that fail audits, why they happen, and the fix for each

What failing an ISO/IEC 27001 audit looks like

Failure takes three forms. Stage 1, the certification body's readiness review, finds the information security management system (ISMS) unready, and Stage 2 moves. Stage 2 raises major nonconformities, and the certificate waits until corrections and corrective actions are verified; beyond six months from the last day of Stage 2, Stage 2 is repeated. Or the audit is passed, and a customer rejects a certificate whose scope misses its service.

Grading and closure are covered in the nonconformities guide, the audit days in the Stage 1 and Stage 2 guide.

Mistakes 1 to 3: scope, risk assessment and the SoA

1. A scope that leaves out what customers rely on

• Why: a narrow boundary looks cheaper, so the head office goes in and the production platform stays out.
• In the audit: clause 4.3 asks you to consider interested parties' requirements and interfaces and dependencies with other organisations, so the auditor tests the boundary. If it holds, the customer later finds its service missing.
• Fix: scope the services customers rely on and document each interface; the scope guide explains how.

2. A risk assessment done once and filed

• Why: the register came from one kick-off workshop and a generic threat list.
• In the audit: clause 8.2 requires assessment at planned intervals and when significant changes are proposed or occur, so the auditor looks for a recent change or incident in the register, and for risk owners' approval of the treatment plan (6.1.3 f).
• Fix: approved criteria, a reassessment calendar and change triggers, as the risk assessment guide sets out.

3. A Statement of Applicability copied from a template

• Why: the template arrives with all 93 controls completed, so the SoA looks finished before any risk is assessed.
• In the audit: the auditor asks why included controls are there and excluded ones are not, as 6.1.3 d) requires. Identical wording on every row, or secure coding excluded at a software company, gives it away.
• Fix: derive controls from risk treatment, then compare them with Annex A; the Statement of Applicability guide shows how.

Mistakes 4 to 6: controls on paper, in the cloud and in access lists

4. Controls declared but not operating

• Why: the SoA said "implemented" when a control was designed, not when it began to run.
• In the audit: Stage 2 tests implementation and effectiveness, so the auditor asks for output: the last restore test (A.8.13 requires regular testing), the log review, the fixed vulnerability. Without it, nothing shows the treatment plan implemented (8.3).
• Fix: an owner, a record and a frequency per control. The SoA may show a control as not yet implemented (6.1.3 d), and an accurate "planned" beats a false "implemented".

5. The cloud provider assumed to cover everything

• Why: the platform holds its own ISO/IEC 27001 certificate or SOC 2 report, so cloud controls are marked "covered by the provider".
• In the audit: that evidence covers the provider's side. The auditor asks about yours: console administrators, configuration, logging, backups and exit, since A.5.23 requires processes for acquiring, using, managing and exiting cloud services.
• Fix: map the shared responsibility for each platform and evidence your own half.

6. No access reviews

• Why: joiners and leavers run through tickets, and nobody owns the periodic check of who still holds what.
• In the audit: A.5.18 requires access rights to be reviewed, not only granted and removed, and A.8.2 covers privileged rights. The auditor checks HR's recent leavers against the directory and sampled applications.
• Fix: a risk-based review schedule per system, run by its owner, recording what was checked and removed.

Mistakes 7 to 9: awareness, suppliers and the internal audit

7. Awareness as a one-off

• Why: everyone attended a kick-off session, and the attendance sheet became the evidence.
• In the audit: clause 7.3 requires awareness of the policy, each person's contribution and the implications of not conforming; A.6.3 adds regular updates. Auditors ask staff how they would report a suspicious e-mail, and sample recent joiners.
• Fix: induction, refreshers and role-based training, with a measure of what people retained; see the training guide.

8. Suppliers without security clauses

• Why: contracts pre-date the ISMS, and large vendors' terms looked non-negotiable.
• In the audit: the auditor picks a supplier with access to your information, such as payroll or IT support, and asks for the agreed security requirements (A.5.20) and the last review of its security practices (A.5.22).
• Fix: tier suppliers by access and add requirements to contracts; where terms cannot change, assess the supplier's report and have the risk owner accept the rest.

9. The ISMS lead auditing their own work

• Why: a small team asks the person who built the ISMS to audit it.
• In the audit: clause 9.2.2 requires auditors and audits that ensure objectivity and impartiality. A risk method audited by its author fails that test; a report with no findings suggests nobody looked hard.
• Fix: auditors from other functions, the whole scope covered across the programme and outside help for small teams, as the internal audit guide explains.

Mistake 10: evidence assembled the week before

• Why: the work happened, but its traces sit in tickets, chats and consoles, so records are gathered, or rebuilt, late.
• In the audit: auditors sample across the operating period. Reviews, assessments and minutes all dated in one week suggest controls that never ran, and a back-dated record does far more damage than a real gap.
• Fix: records kept as work happens, in one controlled place (in a Sterling engagement, Effivity, included with the engagement, at no additional cost), and a Stage 2 date set once there is history to sample; the timeline guide explains why.

The shortcuts, and what they really cost

We have advised on management systems since 2003, and offers to skip this list return yearly in new packaging. We understand the pull of a questionnaire with a contract behind it.

• The policy pack. Policies with your logo look like progress, yet deliver mistakes 3 and 4 in one download.
• The dashboard that turns green. Tools that read cloud settings help, which is why Effivity is part of every engagement we run, but no tool decides which risks you accept or chairs a management review.
• The certificate in days. No control builds an operating history in days, and a certificate from a body without accreditation recognised through the Global ACI arrangement fails the first check an enterprise customer runs. You then pay twice; learn to verify a certificate and choose a certification body.

We would rather give a realistic range and fix the audit date once the gap analysis has sized the treatment plan. It is slower, deliberately: that certificate survives due diligence, and its controls survive the first real incident.

ISO/IEC 27001 common mistakes: questions buyers ask