- Auditors fail organisations on process gaps: an unowned risk register, a Statement of Applicability that does not match deployed controls, or no evidence of internal audit and management review.
- ISO 27001:2022 carries 93 Annex A controls. Certification tests whether each applicable one is implemented, monitored, and reviewed, not whether the organisation owns every security product on the market.
- The evidence trail built for the initial certificate tends to stop growing once the certificate is issued, and surveillance and recertification audits exist specifically to catch that lapse.
What the Audit Actually Tests
ISO 27001 certification does not test a security stack. It tests whether the Information Security Management System, the governance structure defined across clauses 4 through 10, actually runs. An assessor works through a fixed sequence: is the ISMS scope documented, is a risk assessment method applied consistently within it, does the Statement of Applicability match what is genuinely deployed, is there evidence of internal audit and management review, and are prior nonconformities closed. A firewall, an EDR agent, or a SIEM licence only matters to the auditor once it traces back to a control the organisation claimed in its SOA.
The Statement of Applicability Is Where Most Certifications Fail
The SOA lists all 93 Annex A controls from the 2022 revision and states, for each, whether it applies, why, and how it is implemented. The recurring failure: an SOA carried over from a template or an earlier certification cycle, claiming controls the organisation does not actually run, or excluding controls that plainly apply given its outsourcing footprint, such as supplier risk management under A.5.19 to A.5.22. Assessors cross-check the SOA against the risk assessment and against direct evidence. A gap between what the SOA claims and what a control test shows becomes a documented nonconformity, not a warning to fix later.
Risk Assessment: The Method Auditors Actually Check
Clause 6.1.2 requires a risk assessment methodology, applied consistently, that names risk owners and produces levels an assessor can trace back to a rationale. The common failure pattern in the region is a generic register: "ransomware" or "data breach" listed as a top risk with no link to specific assets, no likelihood rationale, and a "medium" rating with nothing behind it. A register that survives scrutiny ties each risk to an asset in the inventory, a named owner, a documented likelihood and impact scale, and a treatment decision: accept, mitigate, transfer, or avoid. ISO does not mandate a specific scale. It does require the same scale applied the same way across every business unit, with the working shown, not just the final score.
Risk Treatment and Ownership
A treatment plan without a named owner is not a plan. Clause 6.1.3 ties the SOA back to specific treatment decisions, and each decision needs a person, not a department, accountable for it. The gap that shows up repeatedly: a risk register signed off by someone with no authority to accept residual risk, or a treatment plan that assumes a control, network segmentation against a ransomware risk, for example, that was never actually implemented. Assessors ask to see the sign-off record, not just the register entry.
The Evidence Auditors Actually Ask For
Three areas generate more nonconformities than any technical gap.
Internal Audit (Clause 9.2)
A planned internal audit programme covering the full ISMS scope, with documented findings, not a checklist completed the week before the certification body arrives.
Management Review (Clause 9.3)
Minutes showing top management reviewed ISMS performance: audit results, risk trends, incident metrics, resourcing decisions. A signature on a policy document is not a management review.
Corrective Action
A closed-loop process for nonconformities, with root cause analysis recorded, not a one-line remediation note. Assessors check prior findings first. An unresolved finding from the last surveillance audit escalates the current one.
Where Governance Meets the Technical Layer
GRC is not separable from what security operations teams do day to day. A.8.8, vulnerability management, needs a live programme with tracked remediation timelines, not a scan report from six months ago cited as evidence; the mechanics of running one properly are covered in this vulnerability management programme guide. A.5.15 and A.8.2, access control and privileged access, need periodic access reviews with sign-off, not a policy stating that reviews happen. A.8.15, logging and monitoring, is where the technical-to-governance gap shows up most often in the region: an organisation stands up a platform like FortiSIEM to collect logs and treats the control as satisfied, but the assessor wants evidence someone reviews the alerts and reports on them, not just that ingestion is running. Instrumentation without a review process behind it is not evidence.
Common Nonconformities Across UAE Certification Audits
The same patterns repeat across banking, government, and healthcare certifications: an SOA that does not match deployed controls, a risk register nobody has updated since a cloud migration or new vendor onboarding, access reviews without sign-off, supplier risk assessments that stop at a signed NDA, and awareness training with no completion tracking. These are governance failures, not technology gaps, and they line up with what shows up in the GRC fundamentals FAQ and in the broader pattern covered in why UAE audits keep failing on governance.
Sector Regulation Overlaps, It Does Not Replace ISO 27001
Sector regulators increasingly reference or expect ISO 27001-aligned controls: DIFC data protection obligations for organisations in that jurisdiction, ADHICS requirements for Abu Dhabi healthcare providers, and CBUAE guidance for banks. None of them substitute for the certification process. The honest way to read this: assessors in regulated sectors expect the same governance evidence ISO 27001 already demands, often on a tighter reporting cycle, not a separate parallel framework.
Recertification Is Where Governance Actually Decays
The three-year certification cycle runs on annual surveillance audits, and the evidence base an organisation assembled for its initial certificate rarely keeps pace on its own. The reason is structural: the risk register gets frozen at the point of first certification and never re-run against subsequent business change, a new cloud platform, a new outsourced function, a merger. Tie risk reviews to change events rather than a calendar reminder, and the register stays defensible between full recertification cycles instead of decaying quietly until the next assessor finds it.
What to Fix First
- Reconcile the Statement of Applicability against controls actually deployed before touching anything else.
- Assign a named owner to every entry in the risk register, with sign-off required to accept residual risk.
- Run an internal audit against the full ISMS scope on a written schedule, and keep the findings on file.
- Produce management review minutes that record decisions, not attendance.
- Close prior nonconformities, with root cause documented, before the next surveillance audit.
