An IT security audit is a systematic assessment of controls, processes and documentation against regulatory requirements (like NIS2) or a recognised standard — run by an internal team or an external auditor, ending in a report with recommendations. Preparation started early determines whether it takes days or weeks, and how many findings the report holds.
Quick Overview
What you’ll learn:
- What an IT security audit covers in the context of the NIS2 directive
- A documentation checklist worth preparing before an auditor arrives
- A table of audit areas and typical evidence of compliance for each
- Which areas most often generate the largest number of post-audit findings
- How to plan audit preparation so it doesn’t happen in the final week
Who this article is for:
- IT directors and CISOs responsible for NIS2 compliance
- Security teams preparing documentation ahead of an audit
- Leadership at companies covered by NIS2 obligations
Reading time: 6 minutes
What an IT Security Audit Covers in a NIS2 Context
The NIS2 Directive (Directive (EU) 2022/2555), adopted by the European Union, extends cybersecurity management obligations to a broader range of sectors than the earlier NIS Directive, introducing requirements around risk management, incident reporting, and management-board accountability for cybersecurity oversight. ENISA, the EU’s cybersecurity agency, notes in its implementation guidance for the directive that a compliance audit should cover not just technical controls but also risk-management processes, business continuity and the supply chain — areas organisations have historically treated as secondary to technical infrastructure itself.
That broader scope has a practical consequence for preparation: a company with well-secured technical infrastructure but no documented risk-management process or incident-response plan can still receive a lengthy list of post-audit findings — a NIS2 audit evaluates process and documentation just as heavily as technology.
IT Security Audit Areas and Typical Evidence of Compliance
| Audit area | What the auditor checks | Typical evidence of compliance |
|---|---|---|
| Risk management | Whether the organisation identifies and assesses cybersecurity risk systematically | A documented risk register, updated on a regular cycle |
| Incident response | Whether an incident-response plan and reporting procedure exist | A written response plan, records of simulated exercises carried out |
| Access control | Whether system access is granted and revoked following least-privilege principles | A permissions register, access-review logs |
| Business continuity | Whether the organisation has a contingency plan for a major incident | A business continuity plan, disaster-recovery test results |
| Supply chain security | Whether vendors and partners are assessed for cybersecurity risk | Contracts with security clauses, vendor assessment results |
| Awareness and training | Whether employees undergo regular cybersecurity training | A training register, phishing-simulation test results |
Missing documentation in any of these six areas matters just as much for the audit outcome as an actual technical gap — an auditor evaluates what can be verified, not what an organisation claims it does.
A Documentation Checklist Before an Auditor Arrives
- Pull together a current cybersecurity risk register — with the date of its last update; a register from two years ago suggests to an auditor a lack of a systematic process, even if the actual risk assessment is current.
- Prepare a written incident-response plan along with exercise records — a plan on its own with no evidence it was ever tested raises questions about its real effectiveness.
- Assemble an access-permissions register with a recent review — showing who has access to what and when permissions were last checked for accuracy.
- Gather vendor contracts containing security clauses — an auditor checks not only an organisation’s own controls but whether risk from vendors is formally addressed.
- Prepare a cybersecurity training register for employees — with dates and topics covered, showing regularity rather than a one-off onboarding session from years ago.
- Run an internal review of all six areas before the real audit — a self-assessment before the audit closes obvious documentation gaps before an external auditor spots them, genuinely shortening the resulting list of findings.
Which Areas Most Often Generate the Most Post-Audit Findings
Two areas keep coming back as the biggest source of findings in NIS2 compliance audits. First: supply-chain security — organisations have historically focused on their own infrastructure, skipping a formal risk assessment of vendors and partners, even though NIS2 explicitly extends accountability into that area. Second: evidence of testing the incident-response and business-continuity plans — many organisations have a written plan but have never actually tested it through a simulation, which an auditor treats as effectively unconfirmed. Focusing preparation on exactly these two areas usually delivers the largest reduction in findings relative to the effort invested.
Read Also
- The NIS2 Directive: What Do Companies Need to Know and How to Prepare — the broader context of obligations arising from the NIS2 directive
- Cyber Security in the Company: The NIS2 Directive, DORA and Building Resilience — how a security audit fits into a broader compliance strategy
Build Your Skills
This topic connects to the The NIS2 directive in practice: preparing your organization course. Check the program and sign up to build your skills with EITT’s experts.
Frequently Asked Questions (FAQ)
Does an IT security audit only evaluate technical controls?
No — in a NIS2 context, an audit also covers risk-management processes, incident response, business continuity, supply-chain security and employee training. A company with strong technical infrastructure but no documented processes in these areas can still receive a lengthy list of findings.
Which area most often generates the most post-audit findings?
Supply-chain security and evidence of testing the incident-response plan — organisations have historically focused on their own infrastructure, skipping a formal assessment of vendor risk and actual testing of response plans through simulations.
How far ahead should you start preparing for an audit?
The earlier the better — documentation like a risk register or training register needs systematic updates over time; it can’t be credibly “caught up” the week before an audit. An internal review of all areas before the real audit closes obvious gaps ahead of time.
Is a written incident-response plan on its own enough for an audit?
Not entirely — an auditor also expects evidence that the plan was actually tested through a simulation or exercise. A plan with no such evidence is treated as unconfirmed in terms of real effectiveness, one of the more common sources of post-audit findings.