Cyber Security Audit Checklist: How to Audit Your Organisation’s Defences

A cyber security audit systematically verifies whether an organization’s controls actually exist, function correctly, and are consistently applied, distinct from a risk assessment. This checklist organizes that verification against NIST CSF 2.0’s current six-function structure, with a genuine scoring method for each item.

If you’re overwhelmed by generic checklists that feel disconnected from any real framework, this grounds every item in something authoritative and current.

What Is a Cyber Security Audit, and Who Should Own It?

A cyber security audit systematically verifies whether an organization’s controls actually exist, function correctly, and get consistently applied, not just documented on paper. This differs from a risk assessment, which asks what could go wrong; an audit asks whether the controls meant to prevent that are genuinely in place and working.

Ownership matters directly here. A named individual, commonly a security or IT leader, should hold accountability for both commissioning the audit and driving remediation afterward. An audit with no clear owner tends to produce a report nobody feels genuinely responsible for acting on.

Internal, Compliance, or Technical Audit — Three Different Questions

Here’s a distinction worth stating precisely, since “audit” gets treated as one undifferentiated activity far too often.

An internal audit, conducted by your own team, checks routine adherence to internal policy, confirming staff actually follow the procedures your organization has already documented.

A compliance audit verifies conformance against a specific external standard, ISO 27001, Cyber Essentials, PCI DSS, answering whether you meet a defined, fixed benchmark set by someone outside your organization.

A technical audit examines actual system configuration and controls directly, firewall rules, patch levels, access permissions, answering whether the technical reality matches what policy and compliance documentation claim.

Internal vs Compliance vs Technical Audit

Audit Type	Conducted By	Answers
Internal	Your own team	Are we following our own policy?
Compliance	Auditor against external standard	Do we meet this specific benchmark?
Technical	Technical assessor	Does system configuration match what’s documented?

Each answers a genuinely different question, and confusing them means commissioning the wrong exercise for what you actually need to know.

The NIST CSF 2.0 Structure, Including the New Govern Function

NIST CSF 2.0, published February 26, 2024, organizes cybersecurity outcomes into six functions, spanning 22 categories and 106 subcategories total, expanded from the previous version’s five functions.

Govern is the newest, most significant addition, sitting centrally as the framework’s foundation. It covers organizational context, risk management strategy, cybersecurity roles, policy, oversight, and supply chain risk management, elevating cybersecurity from a purely technical IT concern to an explicit, board-level governance responsibility.

 Identify develops organizational understanding of assets and risk.

Protect covers safeguards limiting or containing an incident’s impact.

Detect covers timely discovery of cybersecurity events.

Respond covers action taken once an incident is detected.

Recover covers restoring capabilities and services after an incident.

NIST CSF 2.0’s Six Functions

Function	What It Covers
Govern	Risk strategy, policy, roles, oversight, supply chain risk
Identify	Asset and risk understanding
Protect	Safeguards limiting incident impact
Detect	Timely discovery of cybersecurity events
Respond	Action taken during an active incident
Recover	Restoring capabilities after an incident

A Practical Scoring Method: Not in Place, in Place, Tested, Monitored

Here’s a genuinely useful scoring methodology most checklist content skips, defaulting instead to a flat, uninformative yes-or-no list.

Score every checklist item on a four-level scale.

Not in place means the control genuinely doesn’t exist yet.

In place but unverified means the control exists on paper or in configuration but hasn’t been actively tested.

 In place and tested means someone has confirmed the control genuinely works as intended, at least once.

In place and continuously monitored means the control is actively, ongoingly verified, not just checked once and assumed to remain correct.

Here’s why this graduated scale matters practically. A flat yes/no checklist treats an MFA policy that exists only in a document, never actually enforced, identically to MFA that’s enforced, tested, and continuously monitored across every account. Those are wildly different real-world security states, and a binary checklist erases that difference entirely. The four-level scale forces an honest, specific answer for every single item, revealing genuine maturity rather than a comforting but misleading checkmark.

The Full Checklist, Domain by Domain

Score each item below using the four-level method: not in place, in place but unverified, in place and tested, or in place and monitored.

Govern

• ☐ Named individual accountable for cybersecurity risk
• ☐ Documented, board-reviewed risk management strategy
• ☐ Defined cybersecurity roles and responsibilities across the organization
• ☐ Supply chain and third-party risk management process

Identify

• ☐ Current, accurate asset inventory
• ☐ Documented data classification scheme
• ☐ Regular vulnerability assessment cadence established

Protect

• ☐ Multi-factor authentication enforced across all accounts
• ☐ Least-privilege access control applied consistently
• ☐ Encryption in transit and at rest for sensitive data
• ☐ Patch management process with defined timelines

Detect

• ☐ Centralized log collection and monitoring
• ☐ Defined anomaly and intrusion detection capability
• ☐ Regular review cadence for monitoring alerts

Respond

• ☐ Documented, tested incident response plan
• ☐ Named incident response roles and decision rights
• ☐ Defined communication and notification procedures

Recover

• ☐ Regularly tested backup and restoration process
• ☐ Documented disaster recovery and business continuity plan
• ☐ Post-incident review process feeding back into future planning

Why Continuous Auditing Is Replacing the Once-a-Year Exercise

Here’s a genuine shift worth understanding directly. Modern audit expectations increasingly require evidence that a control operated consistently throughout an entire review period, not merely that it existed on the specific day an auditor happened to check.

An annual snapshot audit only proves compliance at one exact moment in time. A control that was correctly configured on audit day but quietly drifted out of compliance three months later would still pass that annual audit’s own historical record, even though the actual protection had genuinely lapsed. Continuous auditing addresses this directly, capturing ongoing evidence automatically rather than relying on a single point-in-time check, meaning drift gets caught close to when it happens rather than discovered, potentially embarrassingly, at next year’s scheduled review.

How Does This Map onto Cyber Essentials and NCSC’s CAF?

Cyber Essentials verifies five foundational technical controls, firewalls, secure configuration, access control, malware protection, and patch management, offering a practical, accessible starting checklist particularly suited to smaller UK organizations without the resources for a full CSF 2.0 implementation.

NCSC’s Cyber Assessment Framework evaluates broader security outcomes, particularly relevant for critical national infrastructure and organizations subject to NIS Regulations, assessing whether specific security objectives are genuinely being achieved rather than prescribing exact technical implementations.

Both frameworks map cleanly onto specific NIST CSF 2.0 functions, primarily Protect and Identify, meaning work completed toward either UK-specific framework directly contributes toward broader CSF 2.0 alignment rather than existing as separate, disconnected effort. Cyber Security Solutions Ltd frequently helps organizations build their first audit checklist directly against CSF 2.0’s own structure, then map existing Cyber Essentials or CAF work onto it, rather than starting from an ungrounded, generic template disconnected from any authoritative framework.

A Realistic Approach for Your Very First Formal Audit

Start with the Govern and Identify functions specifically, establishing genuine ownership and accurate asset visibility before attempting to score any technical control. Without knowing who’s accountable and what you actually have, scoring Protect or Detect items produces unreliable, ungrounded results.

Score every item honestly using the four-level method, resisting the temptation to mark something “in place” simply because a policy document mentions it. Document every identified gap clearly enough to act on later, not just enough to note it existed.

Treat this first audit as an honest baseline to improve against over time, not a pass-fail exercise you either succeed or fail at. A first audit scoring mostly “in place but unverified” isn’t a failure; it’s an accurate, genuinely useful starting point revealing exactly where testing and monitoring effort should go next.

Conclusion

An audit checklist only earns its value when it’s grounded in a real framework and scored honestly enough to reveal genuine gaps, not just comforting checkmarks. Start with Govern and Identify, score every item on the four-level scale, and treat the result as a baseline worth improving, not a test to pass. If you want help running your first CSF 2.0-aligned audit properly, Cyber Security Solutions Ltd can walk through it with you.