Why a checklist beats a framework diagram
A framework diagram tells you that NESA / UAE IAS has six management domains and nine technical domains. It does not tell you what to actually go and look at on a Tuesday morning. The 188 controls in the Information Assurance Standards are the working unit, the things an auditor samples, the things a control owner has to be able to speak to without notes.
This is the checklist we use to run gap assessments: 15 domains, each broken into the questions we ask and the evidence we go looking for. It is not a replacement for the official IAS documentation or the IAMM questionnaire, your sector regulator issues the authoritative version and applicability varies by sector and risk profile. What this gives you is a working structure to assess yourself against before an auditor does it for you.
How to use this checklist
Three rules before you start. First, score honestly. Red, amber or green per item, not per domain, the domain score hides exactly the gaps that matter. Second, every item needs an owner and a piece of evidence, not just a "yes". A control with no named owner and no dated evidence is a control that does not exist at audit, regardless of whether the technical implementation is solid. Third, remember priority. Controls carry a priority rating from P1 (critical) through P5 (advisory), and audit enforcement concentrates on P1 and P2. If you can only fix a fraction of your red items before an audit window closes, fix the P1s and P2s first.
Management domains (M1-M6)
The management domains cover governance, the layer auditors check first because a weak governance layer puts every technical control below it in question.
M1, Information Security Governance
Checklist: a board-approved information security policy, reviewed and re-approved on a defined cycle. A named accountable executive for information security, not a committee. An information security organisation chart with defined roles and segregation of duties. Minutes from the most recent management security review, with attendance and decisions recorded. A documented exception-approval process for any deviation from policy.
M2, Risk Management
Checklist: a live risk register, not a document from a prior audit cycle, updated on a defined cadence with dated entries. A documented risk assessment methodology, consistently applied across the organisation. Risk treatment plans for every high and critical risk, with owners and target dates. Evidence that risk acceptance decisions for residual risk are made and signed off at the appropriate level. A defined risk appetite statement that the risk register is actually scored against.
M3, Information Security Awareness & Training
Checklist: a security awareness programme with a defined annual curriculum, not a one-time onboarding video. Completion records for all staff, including contractors with system access. Role-specific training for privileged users, developers and incident responders. Phishing simulation results with trend data over at least two cycles. Evidence that awareness content is updated to reflect current threats, not the same deck for three years running.
M4, Human Resources Security
Checklist: documented pre-employment screening proportionate to role sensitivity, including enhanced vetting for privileged or sensitive roles where required. Signed acceptable-use and confidentiality agreements on file for every employee and relevant contractor. A defined joiner-mover-leaver process with documented SLAs for access provisioning and revocation. Evidence that leaver access was revoked across all systems within the defined window, this is the single most commonly failed item in this domain. Disciplinary process references for security policy violations.
M5, Compliance
Checklist: a compliance calendar mapping every applicable regulatory and contractual obligation to an owner and a review date. Evidence of legal and regulatory horizon-scanning, how do you know when a sector regulator issues a new requirement. Records of any prior audit findings with remediation status, auditors will ask what happened to last cycle's findings. A data classification policy aligned to UAE-specific classification requirements. Evidence of intellectual property and licensing compliance for software in use.
M6, Performance Evaluation
Checklist: a defined set of security KPIs and metrics, reported on a regular cadence to management. Evidence of internal audits or self-assessments against the IAS conducted between formal cycles. A documented continual improvement process, with a log of improvements actioned from prior reviews. Management review outputs that feed back into the risk register and the remediation roadmap, not a one-way report that goes nowhere.
Technical domains (T1-T9)
The technical domains are where most of the evidence-sampling time goes during the on-site audit. Each one below is the version of the checklist we walk through with a client before their auditor does.
T1, Asset Management
Checklist: a complete, current asset inventory covering hardware, software, data assets and cloud resources, the most commonly failed item in any first audit. Asset ownership assigned for every entry, not "IT" as a catch-all. A data classification scheme applied consistently to information assets. An acceptable-use policy for assets, signed and on file. Evidence that decommissioned assets are formally retired, including secure data wiping records. Spot-check: pick three assets from the inventory and confirm they physically exist where the inventory says they do.
T2, Physical & Environmental Security
Checklist: access control to data centres and server rooms, with logged entry and exit. CCTV coverage of critical infrastructure areas, with a defined retention period. Environmental controls, fire suppression, temperature and humidity monitoring, with maintenance records. A visitor management process with signed logs. Power resilience, UPS and generator testing records with dates and outcomes.
T3, Operations Management
Checklist: a documented patch management process with SLAs by severity, and evidence of the last 30 days of patch deployment. A vulnerability management programme with regular scanning and tracked remediation timelines for high and critical findings. Backup procedures with evidence of a recent successful restoration test, not just successful backup jobs. Capacity management records showing trend monitoring, not reactive scaling. Change management records for the largest recent infrastructure changes, with approvals.
T4, Communications Security
Checklist: network segmentation diagrams that match the actual network, with evidence of a recent segmentation test confirming the segmentation holds. Encryption in transit for sensitive data flows, with the standards used documented. Secure remote access configuration, VPN or ZTNA, with MFA enforced. DNS security controls, filtering and monitoring. Network device configuration standards with evidence of compliance checks against the baseline.
T5, Access Control
Checklist, the most documentation-heavy domain in the framework: a documented access control policy covering provisioning, review and revocation. Evidence of joiner-mover-leaver workflows actually executed, sample three recent leavers and confirm access was revoked across every system with a timestamp. MFA enforced for remote access and privileged accounts at minimum. Privileged access management, vaulted credentials, session recording, no standing administrative access. Periodic access reviews with evidence of action taken on findings, not just a review that happened. Service account inventory with owners and rotation evidence.
T6, Third-Party Security
Checklist: a vendor inventory covering every third party with access to systems or data, including the SaaS applications procured outside central IT. Security clauses in vendor contracts, reviewed against current policy, not inherited from contracts that predate it. Vendor onboarding and offboarding workflows, with evidence they have been executed, not just documented. Evidence of vendor access reviews on the same cadence as internal access reviews. Incident notification clauses requiring vendors to report security incidents within a defined window.
T7, Information Systems Acquisition, Development & Maintenance
Checklist: a secure development lifecycle for any in-house or custom-developed systems, with security requirements defined at design stage. Security testing, code review or application security testing, as part of the release process. Separation between development, test and production environments. Evidence that third-party software and components are assessed for security before deployment. Configuration management for application environments with version control.
T8, Information Security Incident Management
Checklist, one of the most heavily tested domains: a documented incident response plan with defined roles, escalation paths and severity classifications. An incident register covering at least the last 12 months, with entries traceable from detection through to lessons learned. Evidence that incident reporting to the sector regulator met required timeframes where applicable, missed reporting windows are findings in their own right. Post-incident review records showing what changed as a result. A tested communication plan for incidents that require external notification.
T9, Information Systems Continuity Management
Checklist, the domain where evidence and reality diverge most: a documented business continuity plan with recovery time and recovery point objectives defined per critical system. Evidence of a tabletop or live recovery exercise within the last 12 months, with a participant list, scenarios tested and a post-exercise improvement plan. Backup and disaster recovery infrastructure tested against the documented RTOs and RPOs, not assumed to meet them. Dependency mapping showing how a disruption to one system cascades to others. A plan that has been updated to reflect the current environment, not the environment as it existed when the plan was first written.
Putting it together: the master control matrix
Run all 15 domains through the same five-column structure: control item, current status (red/amber/green), owner, evidence location, and last verified date. That single spreadsheet, or the equivalent in a GRC platform, is the artefact a NESA programme actually runs from. It is also the artefact that converts almost directly into your IAMM submission and, if you are running NESA and ISO 27001 together, into your Statement of Applicability.
The honest version of this exercise produces an uncomfortable first pass. Most organisations score amber or red on a meaningful share of the 188 items the first time they do this properly. That is normal and it is the point, a heatmap that is all green on the first pass almost always means the assessment was not honest, and auditors notice the difference between a rehearsed-but-thin answer and a specific, evidenced one.
Bottom line
The 188 controls are not 188 separate projects. They cluster into a much smaller number of operational investments, an asset and vendor inventory that is actually current, privileged access controls that are actually enforced, a business continuity plan that is actually exercised, and an evidence repository that is actually maintained, each of which closes gaps across multiple domains at once. Start the checklist with an honest first pass, prioritise by P1 and P2, and build the master control matrix as you go. That matrix is what turns next year's audit into the routine one.
