A cybersecurity audit checks whether the organisation can stop, spot and recover from attacks on its systems and data. A practical way to structure it is the six functions of the NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover. Internal audit does not need to be a technical expert on every tool. It needs to ask who owns each risk, what evidence proves the control works, and what happened the last time it was tested.
Last reviewed: 17 October 2026. Facts checked. We searched for the NIST CSF 2.0 function names and for audit programs built on it. The search showed that ISACA publishes a cybersecurity audit program based on CSF 2.0 and that Govern is new in version 2.0. We did not open the NIST framework or the ISACA program. The checklist below is our own practical layout, not a copy of either. Vendor checklists found in the search are generic starting points.
Before you start: scope and approach
Decide the scope before you test anything.
- Which systems and data matter most to the business? Start there, not with every server.
- Is this a full review or one theme, such as access or incident response?
- Who are the technical contacts, and who owns the risk (not the same person)?
- Which earlier reports can you use? An outside test or a SOC 2 report from a key vendor can save work, if you read its scope.
Cybersecurity audit overlaps with IT audit but they are not the same thing. See IT audit vs ITGC vs cybersecurity audit if the boundary is unclear.
The checklist by function
1. Govern
Is cybersecurity run as a business risk, with clear owners?
- Board or audit committee receives cyber reporting. Ask for the last two packs.
- A named senior owner for information security, with defined authority.
- Policies are approved, dated and reviewed on a stated cycle.
- Roles and responsibilities written down, including who decides during an incident.
- Third-party risk is managed (see our AI vendor due diligence checklist for a model approach to vendors).
2. Identify
Does the organisation know what it has and what could go wrong?
- Asset inventory: hardware, software, data stores, cloud accounts. Test completeness by picking items from the network or from invoices and tracing them to the list.
- Data classified by sensitivity, with owners.
- A current cyber risk assessment, with actions and dates.
- Critical suppliers listed, with the services they provide.
3. Protect
Are safeguards in place and working?
- User access: joiner, mover and leaver samples; privileged accounts listed and reviewed.
- Strong authentication on remote access and admin accounts.
- Patching: compare the list of known vulnerabilities with patch dates for a sample.
- Secure configuration baselines for servers, laptops and network devices.
- Data protection: encryption where the policy requires it, backups and removable media rules.
- Staff awareness training and phishing exercises, with completion records.
4. Detect
Would the organisation notice an attack?
- Logging switched on for key systems, with retention stated.
- Someone actually reviews alerts. Ask for evidence of review and follow-up.
- Monitoring covers cloud and remote access, not just the office network.
- Vulnerability scanning on a defined schedule, with results tracked to closure.
5. Respond
Does the organisation know what to do when something happens?
- A written incident response plan with contacts and escalation steps.
- Past incidents logged, classified and closed, with lessons recorded.
- A tabletop exercise or similar test in the recent past. Ask for the report.
- Reporting duties known: regulators, customers, law enforcement where applicable. Check current requirements for your sector, since we have not listed any here.
6. Recover
Can the business get back to work?
- Backup jobs run and failures are followed up.
- A restore test actually performed, not only planned.
- Recovery targets agreed with the business and compared with real test results.
- Communication plan for staff and customers during an outage.
How to test rather than just ask
| Weak audit | Stronger audit |
|---|---|
| "Do you have a patching policy?" Yes. | Pick ten servers and show the patch history. |
| "Are leavers removed?" Yes. | Get the HR leaver list and compare to active accounts. |
| "Do you test backups?" Yes. | Ask for the last restore test record and the time it took. |
| "Do you have an incident plan?" Yes. | Walk through the last real incident against the plan. |
Compare lists from two independent sources wherever you can. That is how gaps show up.
Reporting findings
State the risk in business terms: what could happen, to what, and how likely. Rate findings by impact on the business, not by technical severity alone. Agree owners and dates. Keep technical detail in an appendix so the audit committee can read the main report.
Frequently Asked Questions
Do we need a technical background to run this audit?
Not for the whole audit. You need enough to ask good questions and test evidence. For deep technical testing, such as penetration testing, bring in specialists and review their work.
Is NIST CSF mandatory?
We did not find that it is mandatory for Indian organisations, and we did not check sector rules. It is a voluntary framework used as a structure. Check your own regulator's requirements.
How often should we audit cybersecurity?
It depends on risk. Many teams cover high-risk areas every year and others on a cycle. Set the rhythm in the audit plan and review it after incidents.
What is the difference from an ISO 27001 audit?
ISO 27001 audits a management system against a standard that can lead to certification. A cybersecurity audit can follow any framework and need not lead to a certificate. See our ISO 27001 internal audit guide.
Can we rely on a vendor's SOC 2 report?
Partly. Read the scope, period, exceptions and the controls the report expects from you. It does not replace your own checks on how you use the service.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error