- ISO 27001 certifies a management system, not a toolset; the Statement of Applicability and the risk register are what assessors actually interrogate
- In the UAE it rarely stands alone: banks answer to CBUAE, Dubai government entities to DESC, and most sectors also map to the national IA standard that grew out of NESA
- Certification bodies test whether controls are operated and evidenced, not whether a policy document exists
- Programmes that survive year two have a named owner for every Annex A control in scope, not a GRC team that owns all of them on paper
What ISO 27001 certification actually checks
ISO 27001 is a management system standard. The certification body is not auditing your firewall rules or your encryption algorithm; it is auditing whether you have a documented, risk-based process for deciding what controls you need, whether you have implemented what you said you would, and whether you can produce evidence the process runs continuously. The clauses that matter most in practice are context and scope (clause 4), leadership and resourcing (clause 5), risk assessment and treatment (clause 6), and internal audit plus management review (clauses 9 and 10). Annex A gives a reference set of controls, 93 under the 2022 revision, grouped into organisational, people, physical and technological categories. You do not have to implement every one, but you have to justify, in the Statement of Applicability, why each is included or excluded, tracing back to the risk assessment.
The Statement of Applicability is the document that gets you certified or doesn't
Most SoAs I have reviewed in the UAE are built backwards: someone takes the Annex A list, marks everything "applicable," writes a one-line justification for each, and moves on. An assessor reading that document knows immediately the risk assessment did not drive the control selection, because it is statistically implausible that every organisation needs every control applied identically. A defensible SoA reads like it was written by someone who understands the business: a control excluded with a stated reason (no physical data centre, so certain physical controls do not apply), a control included with a stated risk driver (customer data in a shared cloud tenant, so access control and cryptography are non-negotiable), each cross-referenced to the risk register entry that justifies it.
The UAE-specific layer: NESA, IA standards, and sector regulators
ISO 27001 gives a portable, internationally recognised management system. It does not automatically satisfy every UAE regulatory expectation on its own. The national Information Assurance standard most people still call NESA, after the authority that originally issued it, sets baseline control requirements for government entities and critical infrastructure operators, and its control families map closely enough to Annex A that organisations doing both usually build one control set and cross-reference it to both rather than run two ISMS programmes in parallel. Banks additionally answer to the Central Bank of the UAE's information security requirements, Dubai government-linked entities to the Dubai Electronic Security Centre's standard, and firms in ADGM or DIFC to their own data protection regimes.
Why this matters for scoping
Organisations that get ISO 27001 wrong in the UAE usually get the scope wrong first. A GRC team scopes the ISMS around "IT" when the business needs the certificate to cover a specific product, data centre or customer-facing service, because that is what the tender or regulator is actually asking for. Scope creep the other way is just as common: teams put the whole organisation in scope to "be thorough," then spend two years evidencing controls across units that never needed to be there. Get the actual requirement in writing before drawing the scope boundary, not after.
Risk assessment is the part everyone underinvests in
ISO 27001's risk assessment methodology (clause 6.1.2) does not mandate a specific model, and that flexibility is where most implementations go wrong. A workable risk assessment identifies information assets and their owners, identifies realistic threats and vulnerabilities against each asset, scores likelihood and impact against a scale the business understands, and produces a treatment plan with an owner and a deadline for every risk above the accepted threshold. What I see instead, repeatedly, is a risk register built once during the certification project, scored on a generic matrix nobody calibrated to the organisation, and never touched again until the surveillance audit is a month away. An assessor who asks "when was this risk last reviewed" and gets a date from eighteen months ago has found a genuine nonconformity, not a paperwork gap.
Where technical validation fits into the risk picture
A risk assessment that relies entirely on interviews and questionnaires is weaker evidence than one built on actual technical findings. Vulnerability scan results, penetration test findings and configuration review output should feed directly into the risk register as evidence of likelihood, not sit in a folder nobody links back to Annex A control 8.8 (management of technical vulnerabilities). Organisations running a structured vulnerability management programme produce that evidence far more easily than ones that scan once a year before the audit. The same applies to periodic penetration testing: certification bodies increasingly expect it referenced as an input to risk treatment, not filed as a separate checkbox elsewhere in the organisation.
What actually happens during Stage 1 and Stage 2
Stage 1 is a documentation and readiness review. The auditor checks that the scope statement, risk assessment, SoA, policies and mandatory procedures exist and are internally consistent, and flags gaps before a Stage 2 date is set. Skipping a proper Stage 1, or treating it as a formality, is how organisations pick up major nonconformities at Stage 2 that could have been caught months earlier. Stage 2 tests whether the management system operates as documented: sampling access reviews, checking incident tickets against the incident response procedure, interviewing control owners, and walking through evidence trails for a sample of Annex A controls. A control that exists as a policy but has no operational evidence behind it, such as an access review policy with no completed access review, is one of the most common sources of nonconformities.
Surveillance audits are where certifications are actually lost
Initial certification gets the most attention internally because there is a project team and a deadline. Surveillance audits, run annually for the two years before recertification, get far less attention, and that is exactly when control ownership erodes: the risk register owner moves teams, the quarterly access review drifts to whenever someone remembers, and the internal audit programme meant to run twice a year runs once, late. A certification body can suspend or withdraw certification over sustained nonconformities found at surveillance, not just at the three-year recertification audit.
Common failure patterns worth naming directly
- Treating the ISMS as a one-off project with a start and end date instead of an operating model with a permanent budget line and named owners.
- Writing policies that describe an idealised process rather than the one the organisation actually follows, which guarantees a nonconformity the first time an auditor asks to see it in action.
- Centralising every control under a GRC team with no authority to make the IT, HR or facilities teams that actually operate the controls do anything differently.
- Letting the risk register and the SoA drift out of sync after the first year, so neither reflects current reality by recertification.
- Running internal audits as a box-ticking exercise that confirms documents exist rather than testing whether controls work, so the certification body's own audit becomes the first real test.
Building a programme that survives recertification
A GRC operating model that holds up in the UAE needs four things a slide deck cannot substitute for: a named owner for every control in the SoA who is measured on it, a risk register reviewed on a fixed calendar rather than before every audit, an internal audit function with the standing to report findings the business does not want to hear, and a mapping between ISO 27001 controls and whatever sector requirement (NESA-derived IA standard, CBUAE, DESC) also applies, so evidence is produced once and reused rather than recreated per framework. If you can fix only one thing before the next audit cycle, fix control ownership. Everything else, from a stale risk register to an SoA nobody can defend, traces back to nobody being accountable for keeping it current. See how NESA compliance gets treated as a paperwork exercise in practice, and the wider GRC questions UAE enterprises ask most often.
