0%
0 of 83 answered
A — Managing Risk
A1 Governance
0/6
A2 Risk Mgmt
0/4
A3 Assets
0/3
A4 Supply Chain
0/4
B — Protecting
B1 Policies
0/4
B2 Identity & Access
0/8
B3 Data Security
0/10
B4 System Security
0/8
B5 Resilience
0/6
B6 Training
0/4
C — Detecting
C1 Monitoring
0/12
C2 Discovery
0/4
D — Minimising Impact
D1 Response
0/6
D2 Lessons Learned
0/4
A1
Governance
Board direction, roles & responsibilities, security decision-making
A1.a — Board Direction
Does the board receive and act on regular cyber security reports covering risk, controls, and incidents?
The board should receive timely information to understand the organisation's cyber security posture. Reports should cover current risk levels, control effectiveness, and significant incidents.
Is a named board-level individual accountable for cyber security?
Accountability at board level ensures cyber security receives appropriate attention and resources. This individual should understand the organisation's cyber risk landscape and be able to challenge technical advice.
A1.b — Roles & Responsibilities
Are cyber security roles and responsibilities clearly defined and communicated across the organisation?
All staff should understand their cyber security responsibilities. Key roles (CISO, security manager, incident responders) should be formally assigned, documented, and communicated.
Is there a documented responsibility assignment (RACI or equivalent) for cyber security functions?
A responsibility matrix ensures clarity over who is Responsible, Accountable, Consulted, and Informed for key security activities including incidents, risk decisions, and control ownership.
A1.c — Decision-making
Are cyber security considerations embedded into organisational decision-making and change management processes?
Major business decisions (new services, procurements, organisational changes) should include a security impact assessment. Security sign-off should be part of the change management process.
Are changes to essential functions assessed for security implications before implementation?
Change management processes should require security review to prevent new vulnerabilities being introduced or existing controls being bypassed. Evidence of security assessment should be part of the change record.
A2
Risk Management
Risk management process and understanding threat
A2.a — Risk Management Process
Is there a documented cyber risk management process that is reviewed and updated regularly?
The organisation should identify, assess, and manage cyber security risks using a repeatable, documented process aligned with business objectives. This should be reviewed at least annually or following significant changes.
Does the risk management process cover risks from third parties, new technologies, and changes to the operating environment?
Cloud services, IoT, AI, and other evolving technologies, as well as supply chain dependencies, should be assessed for cyber risk as part of the standard risk management process.
A2.b — Understanding Threat (v4.0)
Does the organisation maintain awareness of relevant threat actors and their tactics, techniques, and procedures (TTPs)?
Understanding who might target your organisation and how they operate helps prioritise defensive measures. This includes nation-state, criminal, hacktivist, and insider threats relevant to your sector and essential functions.
Is threat intelligence actively consumed from relevant sources and integrated into risk management decisions?
NCSC advisories, sector-specific feeds, and commercial threat intelligence should inform risk assessments and security investment priorities. Intelligence should be operationalised, not just collected.
A3
Asset Management
Hardware, software, and data asset inventory
A3.a — Asset Management
Is there a maintained, up-to-date inventory of all hardware assets supporting essential functions?
All servers, network devices, endpoints, OT/ICS equipment, and other hardware supporting essential functions should be inventoried with owner, location, criticality, and support lifecycle status.
Is there a maintained, up-to-date inventory of all software assets supporting essential functions?
All applications, operating systems, middleware, and firmware should be tracked including version, patch status, support lifecycle, and vendor. Unsupported software should be flagged for action.
Are data assets classified and mapped to understand information flows supporting essential functions?
The organisation should know what data it holds, its sensitivity classification, where it is stored and processed, how it flows between systems, and who has access to it.
A4
Supply Chain
Supplier assurance and secure software development
A4.a — Supply Chain
Are third-party suppliers assessed for cyber security risk before engagement and reviewed on an ongoing basis?
Due diligence should be conducted on all suppliers who access your systems, handle your data, or provide services supporting essential functions. This should include ongoing monitoring, not just initial onboarding.
Are cyber security requirements included in supplier contracts, including incident notification obligations?
Contracts should specify minimum security standards, audit rights, data handling requirements, breach notification timelines (typically 24-72 hours), and consequences for non-compliance.
A4.b — Secure Software Development (v4.0)
Are secure development practices (SSDLC) applied to in-house developed or commissioned software supporting essential functions?
Software should be developed following secure coding standards (e.g. OWASP), with security testing (SAST, DAST, penetration testing) integrated into the development lifecycle before production deployment.
Are third-party libraries, open source components, and software dependencies tracked, assessed for vulnerabilities, and kept updated?
Software supply chain risk is significant. All dependencies should be inventoried (e.g. via SBOM), monitored for known vulnerabilities (CVEs), and updated within defined risk-appropriate timeframes.
B1
Service Protection Policies & Processes
Policy development and implementation for essential functions
B1.a — Policy & Process Development
Are cyber security policies documented, reviewed at least annually, and aligned to the organisation's current risk profile?
Policies should cover key areas: access control, data protection, incident management, acceptable use, remote working, and patch management. They should be reviewed annually or following significant changes or incidents.
Do policies reference applicable legal obligations, sector regulations, and NCSC guidance?
Policies should align with legal requirements (NIS Regulations, GDPR, sector-specific regulations) and recognised good practice guidance from NCSC and standards such as ISO 27001 or NIST CSF.
B1.b — Policy & Process Implementation
Are cyber security policies actively enforced, with evidence of compliance monitoring?
Policies must be more than documents. There should be measurable evidence of compliance through audits, automated technical controls, and management reporting. Non-compliance should be tracked and resolved.
Are non-compliance issues identified, tracked to resolution, and escalated to management where appropriate?
When policy breaches occur, there should be a clear process for handling non-compliance including root cause analysis, remediation tracking, and escalation paths for serious or repeated violations.
B2
Identity & Access Control
Authentication, device management, privileged access, and IAM
B2.a — Identity Verification, Authentication & Authorisation
Is multi-factor authentication (MFA) enforced for all users accessing systems supporting essential functions, especially for remote and privileged access?
MFA significantly reduces credential-based attack risk. It should be mandatory for all remote access, privileged accounts, and access to systems supporting essential functions. Exceptions should be formally risk-accepted.
Are authentication mechanisms appropriate to the sensitivity of the systems accessed, and are authorisation decisions based on least privilege?
Stronger authentication (hardware tokens, certificate-based) should protect more sensitive systems. Authorisation should grant only the minimum access required for the user's role, with regular reviews to confirm ongoing appropriateness.
B2.b — Device Management
Are all devices accessing systems supporting essential functions corporately managed, enrolled in a device management solution, and configured to security policy?
Devices should be enrolled in MDM/UEM that enforces encryption, patch compliance, and security policies, and enables remote wipe. Non-compliant devices should be denied access via conditional access controls.
Are unmanaged, personal (BYOD), or guest devices restricted from accessing essential function networks and data?
If BYOD is permitted, appropriate controls (containerisation, conditional access) should limit risk to essential functions. Unmanaged devices should be blocked from direct network access or strictly limited via network segmentation.
B2.c — Privileged User Management
Are privileged accounts separate from standard user accounts and used only when performing administrative tasks?
Administrators should use standard accounts for day-to-day activities and elevated accounts only for administrative tasks. This limits the exposure of high-privilege credentials to malware and phishing attacks.
Are privileged access activities logged, monitored, and subject to regular review?
All use of privileged accounts should be recorded in tamper-resistant logs and reviewed regularly to detect unauthorised, anomalous, or excessive use of administrative privileges.
B2.d — Identity & Access Management
Is there a formal joiners/movers/leavers process ensuring timely access provisioning and revocation?
Access should be granted based on role requirements and revoked promptly when staff leave or change roles. Accounts should be disabled within 24 hours of departure. Regular access reviews should confirm ongoing appropriateness.
Is access to systems supporting essential functions granted on a least-privilege basis and reviewed regularly?
Users should have only the minimum access needed for their role. Access reviews (at least annually for standard users, quarterly for privileged users) should confirm permissions remain appropriate and remove unnecessary access.
B3
Data Security
Data classification, encryption in transit and at rest, mobile data, and sanitisation
B3.a — Understanding Data
Is sensitive data identified, classified, and mapped to understand where it is stored and how it flows?
Data supporting essential functions should be classified by sensitivity. The organisation should maintain data flow diagrams showing movement between systems, to third parties, and across boundaries.
Are data protection impact assessments (or equivalent) conducted for systems processing sensitive or personal data?
DPIAs or equivalent assessments should be completed before deploying systems handling personal or sensitive data, to identify and mitigate privacy and security risks before they are introduced.
B3.b — Data in Transit
Is data in transit encrypted using appropriate, up-to-date protocols (e.g. TLS 1.2 or later)?
Data traversing networks must be encrypted to prevent interception. Obsolete protocols (SSL, TLS 1.0/1.1) should be disabled. Certificate management processes should ensure timely renewal.
Are encrypted connections authenticated to prevent man-in-the-middle attacks?
Certificate validation should be enforced for all encrypted connections. Expired or self-signed certificates should be detected and remediated promptly. Strong certificate authorities and revocation checking should be used.
B3.c — Stored Data
Is sensitive data encrypted at rest using appropriate, current encryption standards?
Encryption at rest protects data from unauthorised access if storage media is lost, stolen, or decommissioned. Encryption keys should be managed separately from the encrypted data, with strong key management processes.
Are access controls to data stores reviewed regularly to ensure only authorised users and services have access?
Database and file share permissions should be reviewed periodically. Service accounts should have minimal permissions. Unused access should be revoked promptly. Privileged data access should be logged.
B3.d — Mobile Data
Are mobile devices carrying organisational data encrypted and protected by appropriate security controls?
All laptops, tablets, and phones that store or process organisational data should use full-disk or device encryption, with enforced PINs/passcodes, biometric authentication, and automatic screen lock.
Is remote wipe capability available and tested for mobile devices containing organisational data?
If a device is lost or stolen, the organisation should be able to remotely erase all organisational data. Remote wipe procedures should be documented, tested, and operable without physical access to the device.
B3.e — Media & Equipment Sanitisation
Is there a documented and followed process for securely disposing of or re-using media and equipment containing organisational data?
Hard drives, SSDs, USB media, and other storage must be securely wiped (to NCSC or NIST 800-88 standards) or physically destroyed before disposal or reassignment, to prevent data recovery.
Are sanitisation and disposal activities recorded with evidence of completion?
Certificates of destruction or sanitisation logs should be maintained for all disposed or reassigned equipment. These records support compliance with data protection regulations and provide an audit trail.
B4
System Security
Secure by design, configuration, management, and vulnerability management
B4.a — Secure by Design
Are security requirements defined at the design stage for new systems and services supporting essential functions?
Security should be a first-class requirement from design inception, not added retrospectively. Threat modelling should inform architectural decisions. Security requirements should be specified before build commences.
Are security architectures reviewed and validated by appropriately skilled personnel before systems enter production?
Designs for systems supporting essential functions should undergo security architecture review before deployment. This may include internal review, third-party assessment, or penetration testing prior to go-live.
B4.b — Secure Configuration
Are systems hardened according to documented security baselines (e.g. CIS Benchmarks, vendor hardening guides)?
Default configurations are rarely secure. All systems should be configured to a recognised hardening standard with unnecessary services, features, accounts, and protocols disabled or removed before deployment.
Is configuration management documented and auditable, with deviations from security baselines tracked and formally approved?
The organisation should be able to demonstrate that systems are configured as intended. Any deviations from baseline configurations should be risk-assessed, formally approved, documented, and reviewed periodically.
B4.c — Secure Management
Are administrative actions performed on segregated management interfaces or systems, separated from user traffic?
Management interfaces should be accessible only from dedicated management networks or jump servers, not directly from user networks or the internet. Out-of-band management should be used for critical infrastructure where possible.
Are management systems themselves secured, hardened, and subject to enhanced monitoring?
Jump servers, privileged access workstations (PAWs), and management networks should receive at least the same level of security hardening and monitoring as the systems they manage — ideally higher, given their elevated risk.
B4.d — Vulnerability Management
Is there a vulnerability scanning programme covering all systems and services supporting essential functions?
Regular authenticated vulnerability scanning should identify known weaknesses across internal systems, external-facing services, web applications, and cloud environments. Results should be tracked and trended over time.
Are vulnerabilities remediated within defined, risk-appropriate timeframes (e.g. critical within 14 days)?
The organisation should have defined SLAs for patching based on severity (critical within 14 days, high within 30 days per NCSC guidance). Remediation progress should be tracked, reported, and exceptions formally risk-accepted.
B5
Resilient Networks & Systems
Resilience preparation, design for resilience, and backups
B5.a — Resilience Preparation
Has the organisation identified and documented single points of failure for systems supporting essential functions?
Understanding where a single failure or cyber attack could disrupt an essential function allows proportionate resilience measures to be prioritised and implemented before an incident occurs.
Are recovery time objectives (RTO) and recovery point objectives (RPO) defined for essential functions and reflected in system design?
RTO and RPO targets should be agreed with business stakeholders and used to drive resilience architecture decisions, including redundancy levels, failover speed, and backup frequency.
B5.b — Design for Resilience
Are systems supporting essential functions designed to withstand common disruptions through redundancy, failover, and distribution?
Architectural resilience patterns (N+1 redundancy, active-active clustering, multi-zone deployment) should be used proportionate to the criticality and availability requirements of each essential function.
Are internet-facing services regularly reviewed and non-essential external connections disabled or restricted?
Minimising the external attack surface reduces exposure to exploitation. Only services that genuinely require internet exposure should be publicly accessible. Unused ports, protocols, and services should be blocked.
B5.c — Backups
Are backups taken regularly, stored offline or immutably, and tested for successful restoration?
Regular backups protect against ransomware, hardware failure, and human error. Backups must be stored where they cannot be modified by an attacker — offline, air-gapped, or using immutable cloud storage (WORM). Restoration must be regularly tested.
Are backup and recovery procedures documented and exercised at least annually?
Documented recovery procedures ensure restoration can proceed even if key personnel are unavailable. Annual restoration exercises validate that backups are valid, complete, and can be restored within RTO targets.
B6
Staff Awareness & Training
Security culture and role-appropriate training
B6.a — Cyber Security Culture
Does the organisation foster a security-aware culture with well-publicised channels for reporting suspected security incidents?
Staff should feel empowered and safe to report suspicious activity (phishing, anomalous behaviour, lost devices) without fear of blame. Reporting channels should be simple, well-known, and respond promptly to reports.
Is senior leadership visibly engaged in promoting cyber security awareness and setting the right cultural tone?
Leadership commitment is the single biggest driver of security culture. Leaders should visibly champion security, participate in training exercises, and be seen to take security decisions seriously.
B6.b — Cyber Security Training
Do all staff receive role-appropriate cyber security awareness training on joining and at regular intervals thereafter?
All staff need baseline awareness training covering phishing, password hygiene, acceptable use, and incident reporting. Technical staff need additional training on secure configuration, threat detection, and secure coding relevant to their role.
Is training effectiveness measured and content updated to reflect the current threat landscape?
Training effectiveness should be measured — not just completion rates. Simulated phishing click rates, knowledge assessments, and observed behaviour changes demonstrate whether training is achieving the desired effect.
C1
Security Monitoring
Log coverage, alert generation, incident identification, tools & skills, and threat intelligence
C1.a — Monitoring Coverage
Are logs collected from all systems supporting essential functions, including endpoints, network devices, authentication systems, and cloud services?
Comprehensive log collection is the foundation of security monitoring. Logs should cover authentication events, network connections, system changes, application activity, and privileged actions across all in-scope systems.
Is monitoring coverage reviewed regularly to ensure new systems and services are included and no coverage gaps exist?
As the estate evolves (new cloud services, systems, suppliers), monitoring coverage should be reassessed. Coverage gaps should be identified, risk-assessed, and remediated on a priority basis.
C1.b — Securing Logs
Are logs protected from tampering, stored in a secure central location, and retained for an appropriate period (typically 12+ months)?
Logs sent to a central, tamper-resistant SIEM or log management platform cannot be modified by an attacker who compromises a monitored system. Retention should support forensic investigation of incidents.
Are log sources authenticated and the integrity of log data verified?
Logs should come from authenticated sources. Integrity checking (hashing, write-once storage) ensures logs have not been modified post-collection. Log forwarding pipelines should be monitored for interruptions.
C1.c — Generating Alerts
Are meaningful security alerts generated from log data using defined correlation rules covering known attack patterns and policy violations?
Raw logs alone are insufficient. Alert rules should detect brute force, lateral movement, privilege escalation, data exfiltration indicators, policy violations, and known attack patterns relevant to the organisation.
Are alert thresholds regularly tuned to minimise false positives while maintaining detection capability?
Excessive false positives cause alert fatigue and lead to genuine incidents being missed. Alert rules should be regularly reviewed, tuned, and validated against current threat intelligence and organisational baselines.
C1.d — Identifying Security Incidents
Is there a defined process for triaging, prioritising, and escalating security alerts to identify genuine incidents?
Not every alert is an incident. A triage process should assess alert severity, eliminate false positives, and determine whether escalation to the incident response process is required, with defined timescales per severity level.
Are security incidents classified using a consistent severity framework, with appropriate response actions defined for each level?
A consistent severity classification (e.g. P1 Critical to P4 Low) ensures appropriate response resources are allocated. Playbooks or decision trees for common incident types improve triage speed and consistency.
C1.e — Monitoring Tools & Skills
Does the organisation have the tools and skilled analysts (in-house or via contracted MSSP/SOC) to perform effective security monitoring?
Effective monitoring requires both technology (SIEM, EDR, NDR) and skilled analysts who can interpret alerts in context. If in-house capability is limited, a managed security operations centre (SOC) arrangement may be appropriate.
Are monitoring tools and detection rules maintained, updated with current threat intelligence, and assessed for effectiveness?
Security tooling must be kept current. Detection rules should be updated as new threats emerge. Tool effectiveness should be validated through purple team exercises, detection testing, and regular platform health reviews.
C1.f — User Behaviour & Threat Intelligence (v4.0)
Is user and system behaviour baselined and monitored for anomalies that may indicate compromise or insider threat?
UEBA capabilities should establish baselines of normal activity and alert on deviations such as unusual login times, abnormal data access volumes, unexpected process execution, or lateral movement patterns.
Is structured threat intelligence actively consumed from relevant sources and operationalised into detection rules and hunting activities?
NCSC advisories, sector-specific ISACs, MITRE ATT&CK-based intelligence, and commercial feeds should be regularly reviewed and translated into concrete detection rules, indicator blocklists, and hunting hypotheses.
C2
Proactive Security Event Discovery
Detecting system abnormalities and threat hunting
C2.a — System Abnormalities for Attack Detection
Are system abnormalities (unexpected processes, unusual network connections, unauthorised file modifications) actively detected and investigated?
EDR and file integrity monitoring tools should detect unexpected system behaviour that may indicate compromise: unusual child processes, LOLBin execution, C2 beaconing, unauthorised registry changes, or scheduled task creation.
Are mechanisms in place to detect lateral movement and attacker persistence within the network?
Attackers who gain initial access typically move laterally. Internal network traffic analysis, honeypots, east-west monitoring, and detection of credential misuse or abnormal internal connections can reveal attackers traversing the environment.
C2.b — Threat Hunting (v4.0)
Does the organisation proactively hunt for threats within its environment, rather than relying solely on automated alerts?
Threat hunting involves hypothesis-driven, manual investigation to find threats that evade automated detection. This requires skilled analysts with access to rich telemetry and an understanding of current attacker TTPs.
Are threat hunting activities informed by current threat intelligence, MITRE ATT&CK techniques, and findings from previous incidents?
Hunting hypotheses should be targeted based on known adversary TTPs relevant to the sector and organisation, lessons from past incidents, and intelligence about active campaigns targeting similar organisations.
D1
Response & Recovery Planning
Incident response plan, capability, and testing
D1.a — Response Plan
Is there a documented incident response plan covering detection, triage, containment, eradication, recovery, and post-incident review?
The plan should define roles and responsibilities, communication channels, decision authorities, and specific playbooks for common incident types (ransomware, data breach, DDoS, insider threat, supply chain compromise).
Does the plan include communication procedures for internal stakeholders, regulators, sector bodies, and (where required) affected individuals?
The plan should define who needs to be notified, when (regulatory timelines), and how — including NIS Competent Authority notification, ICO reporting within 72 hours for personal data breaches, and customer communications.
D1.b — Response & Recovery Capability
Does the organisation have the capability (in-house or via retained incident response provider) to respond to and recover from significant cyber incidents?
Incident response requires specialist skills — digital forensics, malware analysis, crisis management, and recovery engineering. If not available in-house, retainer agreements with IR providers should be in place and regularly validated.
Are sufficient resources (people, technology, budget, and pre-agreed legal and communications support) available to support effective incident response?
Response capability must be proportionate to the organisation's risk profile. This includes trained staff available on call, IR tooling deployed and ready, pre-negotiated legal advice, and crisis communication support.
D1.c — Testing & Exercising
Is the incident response plan tested and exercised at least annually using tabletop, simulation, or live exercises?
Exercises test whether the plan works in practice, identify gaps, validate communication chains, and build responder muscle memory. Tabletop exercises test decision-making; live exercises test technical capability under realistic conditions.
Do exercises include scenarios relevant to current threats, and do they involve senior leadership and external stakeholders where appropriate?
Scenarios should reflect realistic threats: ransomware, supply chain compromise, insider threat, prolonged outage. Senior leadership participation tests escalation and decision authority. Lessons should be formally captured and acted upon.
D2
Lessons Learned
Root cause analysis and feeding improvements back into controls
D2.a — Incident Root Cause Analysis
Are root cause analyses conducted after significant incidents to understand systemic causes, not just proximate events?
Understanding why an incident occurred enables systemic improvements. RCA should distinguish proximate causes (e.g. unpatched system) from root causes (e.g. inadequate vulnerability management process) to drive lasting change.
Are post-incident findings documented and shared with relevant internal stakeholders and, where appropriate, sector peers and regulators?
Post-incident reports should be shared with management and affected teams. Where appropriate, findings should be shared with sector CERTs, regulatory bodies, and trusted peers to improve collective resilience.
D2.b — Using Lessons Learned
Are lessons learned from incidents and exercises systematically fed back into policies, training, security controls, and architectural improvements?
Incident findings should drive tangible, tracked improvements: updated procedures, enhanced detection rules, additional training, compensating controls, or architectural changes to prevent recurrence of the same or similar incidents.
Is there a formal process to track and verify that remediation actions from incidents and exercises are completed within agreed timescales?
Improvement actions should be formally tracked (in a risk register or action log) with owners, due dates, and sign-off on completion. Overdue actions should be escalated and re-risk-assessed if they cannot be delivered on time.