Cybersecurity

Inside a NESA Audit: A 5-Day Walkthrough of What Actually Happens

Attique Bhatti\u2022May 12, 2026\u202214 min
Inside a NESA Audit: A 5-Day Walkthrough of What Actually Happens

Why most teams misunderstand the audit

The most common misconception about a NESA audit is that it is a technical inspection. It is not. It is an evidence inspection. The auditor is not there to test whether your firewall blocks the right ports — they assume it does. They are there to test whether you can prove the firewall is configured to a defined standard, that the configuration is reviewed on a documented cadence, that exceptions are logged, that the engineer responsible is named, that the change history is auditable, and that all of this has been the case continuously since the last cycle.

Teams that prepare for the audit by hardening their technical environment in the last six weeks consistently underperform. Teams that prepare by hardening their evidence and their narrative consistently outperform. The technical work matters — but it is necessary, not sufficient. This post walks through what an actual NESA audit looks like, day by day, so the preparation work you do is the work that actually shows up in the audit room.

The walkthrough below is generalised from real audits we have supported across banking, energy, government and healthcare clients. The exact shape varies by sector regulator and organisation size — a federal government entity audit is structured differently than a mid-size DOH-licensed healthcare provider — but the broad pattern is consistent.

Before the audit week begins

NESA audits do not appear without warning. The sector regulator notifies you, typically 60 to 90 days in advance. The audit team — usually two to four assessors from a regulator-approved audit firm — issues an Information Assurance Maturity Model (IAMM) questionnaire roughly 30 days before the on-site visit. The questionnaire scores each applicable control on a 0 to 5 maturity scale and requires supporting evidence references.

The IAMM submission is the single most important pre-audit deliverable. It frames the entire on-site week. Auditors arrive having already read your self-assessment, decided which areas to probe and which to accept, and prepared their evidence sampling list. A well-prepared IAMM submission shortens the audit. A weak one extends it and shifts the auditor’s posture from verification to investigation — which is a meaningfully harder audit to pass.

In the week before the audit, the internal team should rehearse. Run a tabletop walkthrough with control owners presenting their controls aloud, exactly as they will in the audit room. The first attempt almost always reveals which owners are uncertain about their own controls. Fix that before the auditor sees it.

Day 1 — Opening, scope confirmation, governance walkthrough

The audit week opens with a kickoff meeting attended by the audit team, the CISO or equivalent, the compliance lead, the IT director and typically the internal audit function. The auditor confirms scope, methodology, the daily agenda and the closing meeting timing. This sounds procedural but is the single most important meeting of the week: scope creep originates here, and so does scope discipline.

The rest of Day 1 covers the management domains (M1 to M6) — governance, risk management, awareness, human resources security, compliance and performance evaluation. The auditor wants to see the information security policy, the risk register, the awareness training records, the compliance calendar and the performance metrics dashboard. They will ask for the dates of recent management reviews, the attendees, and the decisions that came out of them.

A clean Day 1 establishes the auditor’s trust early. The control narratives sound rehearsed but not scripted. The documents are dated, owned and recently reviewed. The risk register is alive, not a 2022 PDF. When the auditor asks "when did the executive committee last review the security programme", the answer is a specific date with attendance and minutes — not a vague "regularly".

Day 2 — Asset management, physical security, operations

Day 2 enters the technical domains. The auditor opens with asset management (T1) and physical security (T2). Asset management is where most first audits go sideways. The auditor will pick three sample assets from your inventory and ask to walk to them. If the inventory says you have a particular server in a particular rack and the rack is empty, the conversation gets uncomfortable fast.

Operations management (T3) covers backup, patching, configuration management, vulnerability management and capacity planning. Expect detailed evidence requests: the last 30 days of patch deployment reports, the most recent backup restoration test, the vulnerability scan results from last month with the remediation status of high and critical findings, and the change management approvals for the largest recent infrastructure change.

The pattern across Day 2 is sampling. The auditor does not review every control end to end — they sample evidence and trace it back to the control. A common technique: pick a high-severity vulnerability from a recent scan, ask who owns it, when it was discovered, when remediation was scheduled, when it was fixed, and what evidence proves it was fixed. If any one of those answers is missing, the control is scored down regardless of the underlying technical state.

Day 3 — Communications, access control, third-party

Day 3 covers communications security (T4), access control (T5) and third-party security (T6). Communications security walks through network segmentation, encryption in transit, secure remote access and DNS security. Auditors increasingly ask for evidence of segmentation testing — not just "we have VLANs", but "here is the result of the last quarterly segmentation test that confirms the segmentation actually works".

Access control is the most documentation-heavy domain in the framework. Joiner, mover and leaver workflows, privileged access management, MFA enforcement, access reviews, service accounts, emergency access, session recording. Expect sample-based testing: the auditor picks three recent leavers and asks to see when their access was revoked across all systems with a timestamp. This is the test that fails most often. Leaver access revocation is theoretically immediate; in practice it is often delayed for one to two weeks, particularly for SaaS applications managed outside central IT.

Third-party security covers vendor risk management, contractual security clauses, vendor access controls, vendor incident reporting and the vendor onboarding and offboarding workflow. The audit here usually surfaces gaps in the vendor inventory: vendors with environment access who never went through formal onboarding, contracts that pre-date the current security policy, and offboarding workflows that exist on paper but have never been executed.

Day 4 — Acquisition and development, incident management, continuity

Day 4 covers systems acquisition and development (T7), information security incident management (T8) and business continuity (T9). Acquisition and development is short in most organisations — secure development lifecycle, security testing in releases, third-party code review. Banking and government audits go deeper here than other sectors.

Incident management is one of the most heavily tested areas. The auditor will ask for the incident register — usually a 12 to 24 month view — and sample two or three incidents to trace through the lifecycle: detection, classification, response, containment, eradication, recovery, lessons learned and reporting to the regulator where required. The reporting timing is critical. UAE Central Bank and TDRA both have specific incident reporting windows that, if missed, become audit findings in their own right regardless of how well the incident itself was handled.

Business continuity is the area where evidence and reality diverge most often. Almost every organisation has a BCP document. Far fewer have evidence of a real tabletop or live recovery exercise in the last 12 months. The auditor wants to see the exercise log, the participant list, the scenarios tested, the outcomes and the post-exercise improvement plan. If the BCP has not been exercised, it has not been validated, regardless of how thorough the document looks.

Day 5 — Closing meeting, findings, next steps

Day 5 morning is reserved for clarifications, follow-up evidence requests and any controls the auditor wants to re-examine. The closing meeting in the afternoon is where the audit team presents preliminary findings, scored against the IAMM. Final findings are issued in a formal report 2 to 4 weeks later, but the closing meeting tells you almost everything you need to know.

Findings are usually categorised as major (significant control failures that require formal remediation plans and regulator notification), minor (lower-severity gaps with shorter remediation timelines) and observations (advisory items, not enforced but tracked). The goal is zero majors, manageable minors and a credible response plan for both.

The closing meeting is also where the next audit cycle is anchored. Most NESA audits run annually with surveillance touchpoints in between; some sectors run more frequently. The dates set in the closing meeting drive the next 12 months of compliance calendar planning.

What separates a clean audit from a messy one

Five patterns consistently separate the audits we see go well from the ones that drag.

Named control owners who can speak to their controls without notes. Auditors mark down ambiguity. They mark up specificity. An owner who says "the privileged access policy is reviewed every six months by me, last reviewed on March 14, here are the meeting minutes" outperforms one who says "yes, we review it regularly". The content is the same; the audit experience is not.

A single evidence repository with consistent naming and dating. Auditors waste time searching for evidence. They mark organisations down for it. A well-organised SharePoint, Confluence or evidence platform with date-stamped controls in a consistent folder structure is one of the highest-leverage pre-audit investments you can make.

A live IAMM submission, not a one-time document. Organisations that maintain the IAMM as a living artefact between audits walk into the next cycle 80 percent prepared. Those that rebuild it from scratch each cycle pay the full preparation cost every time.

A culture of recent evidence. Auditors do not penalise evidence that is "old" if the control runs on an annual cadence. They penalise evidence that is stale relative to its defined frequency. If your patch review is supposed to be monthly and the last evidence is from three months ago, that is a finding. Define the cadence and meet it.

A relationship with the auditor, not just a transaction. Auditors are professionals doing a job. Treating them with respect, answering questions directly, and not arguing every finding produces better outcomes. Arguing every minor finding to defend internal politics costs goodwill that you spend later when a closer call goes against you.

Common surprises

The SaaS shadow IT problem. Almost every organisation discovers in their first audit that the asset and access inventories miss several SaaS applications, often containing significant data, that were procured outside central IT. The fix is straightforward but takes time: a SaaS discovery exercise, formal onboarding into the control framework and ongoing identity-driven discovery via cloud access security broker tooling.

The leaver access problem. Even mature organisations rarely revoke access cleanly within the required window across every system. The fix is identity-driven joiner-mover-leaver automation, not stronger HR-to-IT handoff processes.

The contractor and third-party access problem. Auditors increasingly probe long-running third-party access — vendors who were granted access three years ago and still have it, often for a contract that ended.

The board reporting problem. Many organisations cannot produce dated, attended minutes of executive committee security reviews on demand. The auditor will ask, and "we discuss it informally in the leadership team" is not an answer that scores well.

Bottom line

The NESA audit is structured, predictable and largely about evidence. The preparation that pays off is not last-minute technical hardening — it is named owners, dated evidence, defined cadences and a rehearsed narrative. Organisations that invest in those four things consistently walk into the audit room with the auditor’s default disposition being verification rather than investigation, and that is the single biggest factor in how the week goes.

For the next cycle, start the day after the closing meeting. Capture every finding, observation and improvement opportunity in a working plan. Maintain the IAMM as a living document. Run quarterly internal control reviews against it. The compounding effect over two or three cycles is real: each audit becomes shorter, the findings smaller, and the operating burden lower.

NESA Compliance Services
See how IP Care runs end-to-end NESA compliance and audit support →
Related: NESA vs ISO 27001
Want the framework comparison? Read NESA vs ISO 27001 →
Related: NESA in 90 Days
Working a 90-day audit window? The emergency NESA playbook →
Share
AB
Attique Bhatti

Senior contributor to the IP Care Knowledge Base.

Newsletter

Monthly insights, zero spam.

Enterprise IT analysis delivered to your inbox once a month.

Chat with us on WhatsApp