Consumers of this file should refer to the Essentials OSCAL NS 1.0 page for information regarding the Essentials specific representation used in this OSCAL file.
The board of directors or executive committee is accountable for cyber security.
Formally define and establish executive and board-level accountabilities for cyber security, including setting, monitoring and adjusting organisational risk appetite, and review these accountabilities at a defined cadence.
No named executive or board member is accountable for cyber security.
Cyber security accountability exists only informally, or is assumed rather than documented.
No evidence of cyber security reporting to the executive board.
Organisational risk appetite is not set.
A named executive or board member is accountable for cyber security, but reporting obligations are not formally defined.
Board-level reporting on cyber security occurs but is ad hoc rather than on a defined schedule.
Accountability is documented but has not been reviewed within the organisationally defined cadence or following relevant organisational restructuring or leadership changes.
Organisational risk appetite is set but is not monitored or adjusted over time.
A named executive or board member has documented accountability for cyber security with defined reporting obligations.
Regular reporting to the board or executives occurs on a defined cadence with evidence of reporting artefacts.
Accountability arrangements are reviewed when organisational structures or leadership changes occur.
Organisational risk appetite is set and is monitored and adjusted over time as required.
The board of directors or executive committee is accountable for ensuring that artificial intelligence is secure, controllable, human-supervised and used in an ethical and accountable manner.
Establish and maintain executive accountability for the use, governance and risk management of artificial intelligence within the organisation.
No named executive is accountable for the use, governance or risk management of artificial intelligence.
Artificial intelligence is used within the organisation with no approval, risk assessment or oversight.
Artificial intelligence related risks are not reflected in the organisation’s risk register.
Artificial intelligence use and governance arrangements have not been reviewed within the schedule defined by the organisation.
A named executive is accountable for artificial intelligence but the governance process is informal or undocumented.
Approval and risk assessment occur for some artificial intelligence use cases but coverage is inconsistent across internally developed, third-party and embedded artificial intelligence.
Some artificial intelligence related risks are recorded but the organisation’s risk register does not capture all known artificial intelligence use cases.
Reviews occur within the schedule defined by the organisation, but do not consistently address changes in artificial intelligence capability, threat environment or organisational use.
A named executive has accountability for artificial intelligence, supported by an approved governance process that has evidence of being followed.
The governance process addresses approval, risk assessment and oversight for internally developed, third-party and embedded artificial intelligence use cases.
Artificial intelligence related risks are reflected in the organisation’s risk register and reported through standard governance channels.
Reviews of artificial intelligence use and governance arrangements are conducted on a schedule defined by the organisation and consistently address changes in artificial intelligence capability, threat environment or organisational use.
Suitable and sufficient personnel and resources are identified, acquired and maintained in support of cyber security activities.
Assign sufficient cyber security personnel and resources with the required skills to operate, monitor, maintain and manage the lifecycle of security controls and define cyber security responsibilities within role descriptions.
Cyber security functions are staffed on an ad hoc basis without reference to required skills or capacity.
Critical cyber security roles are unfilled with no approved recruitment plan.
No resourcing plan for cyber security personnel exists.
Some critical roles are filled but identified skills gaps have no plan for remediation.
While assigned personnel provide some capability, there are gaps in capacity, resources, or expertise that hinder the operation, monitoring, maintenance, and lifecycle management of controls.
A resourcing plan exists but does not cover all required cyber security functions.
Outstanding cyber security positions are being actively recruited, but capacity or skills gaps remain.
Sufficient cyber security personnel are assigned to operate, monitor, maintain and manage the lifecycle of controls across the organisation.
Skills gaps are identified and addressed through recruitment, training or contracted services.
A resourcing plan identifies all required cyber security personnel, roles, skills, resources and capacity.
Cyber security responsibilities are defined within applicable role descriptions.
Periodically review cyber security resourcing against cyber threat trends, cyber security incident outcomes and organisational changes.
No review of cyber security resourcing has been conducted.
Resourcing has not been reassessed following significant organisational or threat landscape changes.
A review has been conducted but did not reference current threat trends, cyber security incident outcomes, or organisational changes.
Review outcomes have identified required adjustments, but those adjustments have not been made.
A resourcing review has been completed within the review period defined by the organisation.
The review references current threat trends, cyber security incident outcomes and organisational changes.
Documented review outcomes include resourcing adjustments that are implemented within timeframes defined by the organisation, or formally risk accepted by an appropriate authority.
Security risk management activities for an organisation and their systems (infrastructure, operating systems, applications and data) are embedded into organisational risk management frameworks and subject to ongoing monitoring and assurance activities by the board of directors or executive committee.
Establish and maintain an approved risk management methodology and plan that is used to assess and treat cyber security risks.
No risk management methodology approved by the organisation is in place.
No current organisational risk register exists, or the register has not been reviewed within the cycle defined by the organisation.
Risk treatment decisions are not documented.
An approved risk management methodology exists but risk assessments have not been conducted within the defined cycle.
A risk register exists but treatment plans are incomplete or have not been actioned.
Risk assessments have been conducted but do not cover all in-scope assets.
An approved risk management methodology and plan are in place and used to assess and treat security risks.
A current risk register exists with documented and implemented treatment plans for all identified risks.
Risk assessments have been conducted or reviewed within the assessment cycle defined by the organisation.
Systems (infrastructure, operating systems, applications and data) are delivered and supported by trustworthy suppliers whose cyber security practices are regularly verified or otherwise risk-assessed.
Select and engage suppliers of software, hardware and services on the basis of a cyber supply chain risk assessment proportionate to the risk the supplier introduces, and retain appropriate assurance evidence to support the decision.
No documented or approved governance process exists for evaluating the cyber security trustworthiness of suppliers.
No cyber security evaluation is performed before suppliers are onboarded.
Evaluation outcomes are not documented.
Findings from supplier evaluation outcomes are not used to inform supplier approval, contractual requirements or risk treatment decisions where concerns are identified.
An evaluation process exists but is not consistently applied to all suppliers within scope.
Evaluation is performed for some suppliers, but criteria are not documented or are inconsistently applied.
Outcomes are documented but contractual arrangements do not reflect identified risks or required controls.
A documented and approved governance process is in place and consistently applied.
Cyber security trustworthiness evaluations are performed for all suppliers within scope prior to onboarding.
Evaluation criteria are documented, approved and proportionate to the criticality of what the supplier delivers.
Evaluation outcomes are documented, reflected in contractual arrangements and recorded in the organisation’s risk register where residual risk remains.
Maintain current assurance that suppliers continue to meet their cyber security commitments, and act when that assurance lapses or the supplier’s risk changes.
No process exists to obtain and risk-assess current supplier assurance evidence proportionate to supplier criticality and risk.
No documented and approved governance process exists for maintaining assurance that suppliers meet their cyber security commitments.
No actions are taken when supplier cyber security assurance lapses or supplier risk changes.
Supplier assurance evidence is obtained for some suppliers, but coverage is incomplete or the evidence is not reviewed and actioned.
Some findings are actioned but the response process is informal or inconsistent.
A process exists but acceptable forms and currency of assurance evidence are not defined or applied consistently.
Current assurance evidence is obtained from suppliers in proportion to their criticality and risk, and is reviewed for findings that affect the organisation.
Material concerns are addressed through contractual remediation, compensating controls or supplier substitution within defined timeframes.
A documented and approved governance process specifies the acceptable forms, scope and currency of supplier assurance evidence.
Systems (infrastructure, operating systems, applications and data) that are not capable of meeting cyber security requirements are managed using compensating security controls, along with enhanced monitoring and assurance activities, to maintain an acceptable level of residual risk until they can be decommissioned or replaced.
Establish and maintain a process for identifying, assessing and treating cyber security risks associated with legacy systems and unsupported technologies through compensating controls, enhanced monitoring and assurance until the systems can be removed or replaced.
No documented or approved governance process exists for identifying or managing legacy systems.
Legacy systems are not formally identified within the environment.
Cyber security risks associated with legacy systems are not assessed or are assessed informally.
There are no interim compensating controls to manage identified cyber security risks associated with legacy systems.
Legacy systems remain in operation indefinitely with no documented decommissioning, replacement or migration path.
A process exists but the criteria for classifying a system as legacy are not documented or are inconsistently applied.
Some legacy systems are identified but the inventory is incomplete or is not maintained.
Risk assessments are conducted for some legacy systems but treatment decisions are not documented or approved.
Some compensating controls are in place to address risks associated with legacy systems, but coverage is not complete.
A path exists for some legacy systems but is not tracked to completion.
A documented and approved governance process exists with clear criteria for classifying systems as legacy.
Legacy systems are formally identified, inventoried and reviewed on a cycle defined by the organisation.
Cyber security risks associated with legacy systems are assessed, treated and approved by an appropriate authority.
Compensating controls are applied to manage cyber security risks for legacy systems while decommissioning or migration efforts are in progress.
A documented decommissioning, replacement or migration path exists for retained legacy systems and is tracked to completion.
Systems (infrastructure, operating systems, applications, identities, credentials and data) are continually and centrally identified and documented.
Use an approved asset inventory mechanism that supports automated discovery to detect new and changed physical and non-physical assets.
No approved asset inventory mechanism is in place.
Asset inventory records are maintained manually with no automated discovery capability.
An approved asset inventory mechanism is deployed but does not cover all network segments or asset types.
Automated discovery scans to detect new and changed physical and non-physical assets occur on a schedule but reconciliation with the approved inventory is manual or inconsistent.
An approved asset inventory mechanism which supports automated discovery is deployed to cover all applicable assets and network segments.
Discovery runs on a regular schedule defined by the organisation and new or changed physical or non-physical assets that are detected are reconciled with the approved inventory.
Maintain current records of infrastructure, operating systems, applications, identities, credentials and data assets.
A maintained record of infrastructure, operating systems, applications, identities, credentials and data assets has not been established.
There is no defined process for identifying, recording, reviewing and updating asset records.
Asset records are maintained, but identified omissions, inaccuracies or newly discovered assets are not triaged and addressed within the timeframes or tolerances defined by the organisation.
A process to update the asset inventory runs on a schedule but the results are not reconciled or updated within a period defined by the organisation.
At each scheduled review or update, records of infrastructure, operating systems, applications, identities, credentials and data assets are complete and accurate within the tolerances defined by the organisation.
A defined process identifies changes and newly discovered assets between scheduled reviews, and ensures that records are reviewed, reconciled and updated within timeframes commensurate with the associated cyber security risk.
Security risks for an organisation and their systems (infrastructure, operating systems, applications and data) are identified, including by using current strategic and sector-specific cyber threat intelligence and threat modelling, and are documented along with any associated risk management decisions.
Identify relevant weaknesses, malicious actor techniques and cyber threat behaviours when undertaking risk assessments and review these inputs on a continuous basis.
Risk assessments do not reference relevant weaknesses, malicious actor techniques and cyber threat behaviours.
No process exists to incorporate threat information into risk assessment activities.
Current weaknesses, malicious actor techniques and cyber threat behaviours that are relevant to the organisation are not reviewed or updated.
Risk assessments reference threat intelligence but coverage is limited to well-known or generic threats.
Threat information is considered but not systematically mapped to organisational assets or detection gaps.
Current weaknesses, malicious actor techniques and cyber threat behaviours that are relevant to the organisation are reviewed or updated, but are not used to inform risk assessments or are reviewed only on an ad hoc basis.
Risk assessments incorporate and reference relevant weaknesses, malicious actor techniques relevant to the sector, and cyber threat behaviours.
Relevant weaknesses, malicious actor techniques and cyber threat behaviours are systematically related to applicable assets and used to inform risk treatment decisions.
Current weaknesses, malicious actor techniques and cyber threat behaviours relevant to the organisation are reviewed or updated on a continuous basis at a frequency that enables noted changes to inform risk assessments.
Systems (infrastructure, operating systems and applications) are planned, designed, developed, tested, deployed, maintained and decommissioned according to their business criticality ratings and security and resilience requirements using Secure by Design and Secure by Default principles and practices.
Design systems securely to provide visibility, enforce authorised access, protect data, minimise required and default privileges, limit exposed services and remove unnecessary functionality.
Systems are deployed with default configurations and no evidence of security design considerations.
Unnecessary services, protocols or functionality remain enabled with no documented rationale.
Security telemetry is not enabled or is not considered as part of system design.
Security is considered during system design but not consistently applied across all assets.
Some unnecessary services have been disabled but a systematic review has not been completed.
Security telemetry is partially enabled but gaps in coverage exist.
Systems are designed and deployed with exposed services limited, required and default permissions minimised, data protections in place, authorised access enforced, and only required functionality enabled.
Security telemetry is enabled by default.
Evidence exists that security design decisions are recorded and reviewed during system changes.
Secure build and deployment processes to enforce controls consistently across systems.
No controlled build or deployment process exists for applicable assets.
Changes to systems are applied ad hoc, without any version control, testing or approval.
A controlled deployment process exists but is not consistently followed for all changes.
Version control is in place but pre-deployment security verification is not performed.
A controlled build and deployment process is in place and consistently followed.
Configuration changes are subject to version control, testing and approval before deployment.
Security controls are confirmed to be implemented consistently across systems following deployment processes.
Cyber supply chains supporting systems (infrastructure, operating systems, applications and data) are secure, resilient and support effective and coordinated cyber security incident response.
Assess the integrity and authenticity of software, components and updates before use, and verify provenance where suitable supplier evidence is available.
No verification of software, component or update integrity or authenticity is performed before introduction into systems.
Verification outcomes are not recorded or available for review.
Where verification cannot be performed, no compensating control or remediation paths are documented.
Verification is performed for some categories of software but not consistently across operating systems, applications, firmware and dependencies.
Integrity or provenance checks are performed, but they do not provide sufficient assurance for all software, components or updates.
Verification outcomes are recorded for some software, components or updates prior to being introduced into systems, but not consistently.
Compensating controls exist for some unverifiable components but are not formally approved or time-bound.
Verification of integrity and provenance is performed for software, components and updates across all relevant categories, and provenance is verified where suitable supplier evidence is available.
Verification uses one or more mechanisms appropriate to the software, component, update and source to provide reliable assurance of integrity and provenance.
Verification outcomes are recorded and available for review.
Where verification cannot be performed, compensating controls are applied, exceptions are time-bound and remediation paths are documented.
Use vendor advisories and threat intelligence to maintain awareness of supplier, product and component exposure to compromise, and act within timeframes proportionate to the risk.
No monitoring is performed for indicators of supply chain compromise affecting software, components or services in use.
Vendor security notifications and threat advisories are not reviewed or actioned.
When supply chain compromise is identified, neither containment nor investigation is performed.
Supply chain compromise events are integrated into neither incident response nor risk management.
Monitoring occurs but does not draw on relevant threat intelligence sources or does not cover all in-scope systems.
Notifications and advisories are reviewed but exposure assessment and response are not conducted in a timely manner.
Containment occurs but investigation for evidence of exploitation is not consistently undertaken.
Some integration exists but findings are not reflected in the risk register or incident response procedures.
Monitoring covers software, components and services in use, drawing on relevant threat intelligence sources.
Vendor security notifications and threat advisories are reviewed, exposure is assessed and response actions are initiated within defined timeframes.
Identified supply chain compromises are responded to in timeframes defined by the organisation.
Supply chain compromise events are integrated with incident response and reflected in the risk register.
Robust and secure identity, credential and access management is used to establish, maintain and control access to systems (infrastructure, operating systems, applications and data) and to support effective detection of identity and credential misuse.
Identify and disable or remove default and unused accounts regularly, permitting exceptions only where the account is documented, justified, hardened and monitored.
No review of default or unused accounts has been conducted within the review period defined by the organisation.
Default vendor accounts remain enabled on production systems without appropriate documentation, justification, hardening and monitoring in place for their use.
No process exists to identify accounts that have not authenticated within a defined period.
A review has been conducted but does not cover all assets.
Default accounts have been identified but some remain enabled without documented justification.
Unused accounts are identified but remediation is incomplete or delayed beyond defined timeframes.
A review of accounts has been completed within the defined review period covering all assets.
Default accounts are disabled or have approved justification for remaining active, with appropriate monitoring and compensating controls for their use in place.
Accounts that show no evidence of use, other than approved emergency access accounts, are identified and either disabled or removed in accordance with defined timeframes.
Store authentication keys, secrets and tokens in approved secure repositories with access controls, including MFA.
Credentials are stored in plaintext, spreadsheets, shared drives or other unapproved locations as standard practice.
No approved secure repository is in use to store authentication keys, secrets and tokens.
Access to credential stores is neither controlled nor audited.
Access controls such as MFA are not enabled for authentication to secure repositories.
An approved secure repository is in use but does not cover all authentication keys, secrets and tokens within scope.
Access controls for secure repositories are in place but access logging is not enabled or not reviewed.
MFA is enforced for some, but not all, applicable users, repositories or authentication pathways, and the remaining exceptions are documented and subject to remediation.
Authentication keys, secrets and tokens within scope are stored in approved secure repositories, with any authorised exceptions documented, risk-assessed and managed in accordance with organisationally defined requirements.
Access to secure repositories is restricted using attribute or role-based access controls, MFA is enforced for all applicable authentication pathways, and access is logged and reviewed and investigated where necessary.
Identify and remediate unsecured keys, secrets and credentials by regularly scanning codebases, configuration files, file shares and user collaboration platforms.
No secret scanning capability is deployed.
No process exists to identify credentials exposed in codebases, configuration files, file shares or user collaboration platforms.
Unsecured keys, secrets and credentials found exposed in codebases, configuration files, scripts, file shares or user collaboration platforms are left in place with no action taken.
Secret scanning is deployed but does not cover all repositories, pipelines or user collaboration platforms.
Scanning runs but discovered credentials are not assessed in a timely manner.
Unsecured keys, secrets and credentials that are discovered are assessed, but are not rotated or revoked in a timely manner.
Secret scanning tooling is deployed across codebases, configuration files, file shares and user collaboration platforms.
Scans to identify unsecured keys, secrets and credentials run on a regular schedule defined by the organisation.
Unsecured keys, secrets and credentials that are discovered are assessed, then rotated and/or revoked within timeframes defined by the organisation.
Use phishing-resistant MFA for users authenticating to systems, including from untrusted, external or high-risk locations.
Phishing-resistant MFA is not enforced for interactive user authentication to systems.
MFA is deployed but uses non-phishing-resistant methods, such as SMS, voice, or push-only authentication instead of phishing-resistant MFA.
No access policies differentiate between trusted and untrusted, external or high-risk locations.
Access from untrusted, external or high-risk locations is permitted without MFA, or with non-phishing-resistant MFA.
Phishing-resistant MFA is deployed for some but not all systems within scope.
Access policies exist but do not cover all organisationally defined high-risk location categories.
Exceptions or alternative authentication pathways allow routine or recurring authentication without phishing-resistant MFA, or emergency access arrangements are not adequately restricted, monitored, tested or reviewed.
Phishing-resistant MFA is enforced for all routine interactive user authentication to systems within scope.
Phishing-resistant MFA is enforced for routine authentication attempts from untrusted, external or high-risk locations.
Customer-facing services provide a phishing-resistant MFA option for authentication.
Emergency access arrangements are periodically tested and reviewed to confirm that they remain operational, appropriately protected and limited to their intended purpose. Credentials or authentication factors used for emergency access are securely managed and are not used for routine administration.
Disable legacy authentication protocols or, where this is not feasible, restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan.
Legacy authentication protocols that cannot enforce modern authentication controls remain enabled and in active use without restriction.
No assessment has been conducted to identify which legacy authentication protocols are in use within the environment.
Authentication mechanisms transmitting credentials in cleartext or using weak cryptographic primitives remain enabled and no action has been taken to disable them.
Where legacy protocols are retained, no compensating controls, no monitoring and no decommissioning timelines are in place.
Legacy authentication protocols have been identified and are partially restricted but some remain enabled across systems within scope without justification.
An assessment has been conducted but does not cover all in-scope systems, or the inventory of legacy protocols in use is not maintained.
Some weak authentication mechanisms have been disabled but others remain enabled without documented justification or remediation plan.
Compensating controls exist for some retained legacy protocols but monitoring is inconsistent or decommissioning timelines are not defined.
Legacy authentication protocols that cannot enforce modern authentication controls have been identified and disabled across systems within scope, excluding documented and risk accepted exceptions.
An assessment of legacy authentication protocol use has been conducted across in-scope systems and the inventory is maintained.
Where retention is necessary, compensating controls are applied and decommissioning timelines are recorded and tracked.
Ongoing use of legacy authentication protocols is regularly risk reviewed, accepted and recorded in the organisation’s risk register.
Ensure that user, machine, system and service account credentials are unique per system or account, particularly in high-privilege contexts.
Local administrator credentials are shared across the device fleet, or service or privileged account credentials are routinely reused across systems.
Credential uniqueness is not enforced for applicable user, machine, system or service identities.
Credential uniqueness has not been addressed in high-privilege contexts, including domain administration, cloud administration or automation platforms.
Where credential uniqueness cannot be enforced, neither compensating controls nor remediation paths are in place.
Local administrator credential uniqueness has been implemented for some device populations but coverage is incomplete across the device fleet.
A technical mechanism is in place but applies to only a subset of credential types or systems within scope.
Credential uniqueness has been addressed in some high-privilege contexts but gaps remain in others.
Compensating controls exist for some shared credentials but monitoring is inconsistent or remediation plans do not exist.
Credentials for applicable local administrative accounts are unique to each system or account.
Credential uniqueness is consistently enforced for applicable user, machine, system and service identities.
Credential uniqueness is enforced consistently in high-privilege contexts, with managed identities or equivalent capabilities used in preference to shared static credentials wherever feasible.
Where uniqueness cannot be enforced, compensating controls are applied, the use of the shared credentials is monitored, and a remediation plan exists.
Users are granted the minimum access to systems (infrastructure, operating systems, applications and data) required to undertake their duties or functions.
Periodically review and update access privileges in alignment with current roles, duties and business requirements.
Access privileges are not reviewed against current roles, duties and business requirements.
Access reviews do not identify privileges that are no longer required.
Access privileges are not updated when personnel roles, duties or business requirements change.
Access privileges are not mapped to roles, duties and business requirements.
Access reviews are conducted for some accounts or systems, but coverage is incomplete.
Reviews identify excessive or obsolete privileges, but updates are incomplete or not completed within timeframes defined by the organisation.
A process to review access privileges exists but only occurs on an ad hoc basis.
Some access privileges are mapped to roles, duties and business requirements, but not all.
Access privileges for all applicable accounts and systems are reviewed within a cycle defined by the organisation and aligned with current roles, duties and business requirements.
Privileges identified as excessive or obsolete are removed or updated within timeframes defined by the organisation.
Review outcomes and resulting access changes are documented and available as evidence.
Access privileges are mapped to current roles, duties and business requirements.
Grant only authorised administrative roles permissions to create, modify or delete accounts and roles, and access privileged functions or applications.
Non-administrative users can create, modify or delete accounts or roles.
Delegated permissions are broad and have not been audited.
Permissions are restricted to administrative roles but some delegated permissions are broader than required.
Approval workflows exist for some high-impact changes but not all.
Only designated administrative roles can create, modify or delete accounts and roles.
Delegated permissions are audited and scoped to the minimum required.
Approval workflows are enforced for high-impact identity and access changes.
Provision user, administrative and non-person accounts with only the minimum access and privileges required to perform defined operational functions.
Accounts are provisioned with broad default permissions that exceed operational requirements.
Administrative and day-to-day user functions share the same account, with no separate privileged accounts.
Minimum privilege provisioning is defined but not consistently applied to all account types.
Administrative accounts are separated from user accounts but some exceptions exist without documented justification.
All accounts are provisioned with documented minimum permissions aligned to defined operational functions.
Separate accounts are allocated for privileged and day-to-day functions, and controls prevent privileged use from day-to-day context.
Non-person and service accounts are scoped to their specific integration requirements.
Systems (infrastructure, operating systems, applications and data) are administered in a secure, accountable and auditable manner.
Ensure administrative activities can only be performed from dedicated and hardened environments that are isolated from unprivileged user workloads.
Administrative access to systems is routinely performed from standard user devices without additional controls to protect the administrative session.
No dedicated or hardened administrative environment exists.
Exceptions to the use of dedicated administrative environments are neither identified nor assessed.
A dedicated administrative environment has been established, but administrative access is not consistently routed through it.
Administrative endpoints have been hardened, but unprivileged user workloads or unnecessary functions remain accessible.
Exceptions are documented, but their justification, risk acceptance, compensating controls or review arrangements are incomplete or inconsistently applied.
Administrative sessions originate from dedicated and hardened administrative environments that are isolated from unprivileged user workloads. Where this cannot be technically enforced, exceptions are documented, risk-assessed, formally accepted and protected by compensating controls.
Administrative environments are hardened and restricted to the functions required for authorised administration.
Exceptions are limited to systems or services that cannot support administration through a dedicated environment, are periodically reviewed and are removed when the technical limitation no longer applies.
Enforce explicit session establishment controls before privileged actions are permitted, including the use of time-bound privilege grants.
Privileged access is standing and does not require explicit activation or time-bound grants, excluding approved break-glass and emergency access accounts.
No re-authentication or step-up authentication is required before privileged sessions.
Time-bound access is implemented for some privileged roles but standing access remains for others.
Session duration limits exist but are not consistently enforced or are set excessively long.
Time-bound privilege grants are enforced for applicable privileged roles, with defined maximum session durations and approved emergency access arrangements.
Re-authentication or step-up authentication is required before privilege activation.
All privilege activations are logged with activating user, role and timeframes.
Record all administrative or management actions that modify systems, configurations or controls, including the details of the associated user, timestamp and target.
Administrative or management actions that modify systems, configurations or controls are not logged.
Logs do not capture sufficient detail to identify who made a change, when and to what target.
Logging is enabled and provides useful coverage, but does not cover all applicable administrative or management platforms.
Logs capture the administrator identity and action but lack detail on the target or change nature.
Comprehensive audit logging to capture all administrative or management actions is enabled on all platforms in scope.
Logs capture administrator identity, timestamp, target object and nature of change.
Systems (infrastructure, operating systems and applications) are securely configured to approved and maintained baselines, including by reducing attack surfaces and attack paths, with configurations continually monitored and consistently enforced.
Define approved configuration baselines, informed by vendor and industry hardening guidance, that disable or remove unnecessary services, insecure settings, and unsupported or weak communication protocols.
No documented configuration baseline exists for assets.
Systems are deployed with vendor defaults and no documented hardening has been applied.
A baseline exists but does not address all applicable asset types.
The baseline is documented but has not been reviewed or updated within the cycle defined by the organisation.
The baseline exists but rationale for configuration decisions is not documented.
A documented and approved baseline exists for all applicable asset types.
The baseline disables or removes unnecessary services, insecure settings, and unsupported or weak communication protocols.
Configuration decisions are documented with rationale to support drift assessment.
The baseline is reviewed and updated on a cycle defined by the organisation.
Deploy approved configuration baselines on systems, including infrastructure, operating systems and applications.
Approved baselines have not been applied to assets.
Baseline deployment has not been validated through technical assessment.
Approved baselines have been implemented where available, but some relevant asset types are not covered by an approved baseline.
Deployment has occurred but validation through technical assessment is incomplete or not current.
Approved baselines have been deployed, but coverage for all applicable assets is inconsistent.
Approved baselines have been applied to all applicable assets.
Deployment has been validated through technical assessment.
Coverage metrics are available demonstrating deployment completeness.
Detect and respond to configuration drift using scheduled technical assessments and, where supported, automated monitoring, based on system criticality and change rate.
No mechanism exists to detect configuration drift from approved baselines.
Assessments to detect configuration drift have not been conducted within the review period defined by the organisation.
Assessments do not systematically identify instances of configuration drift for assets.
Drift detection is in place but does not cover all applicable assets.
Drift is detected but the remediation process is informal or response timeframes are not defined.
Automated configuration monitoring or regular technical assessments detect drift across the applicable assets, occurring at a frequency based on system criticality and change rate.
A documented remediation process exists with defined response timeframes aligned to severity.
Drift events are tracked to closure with evidence of remediation.
Vulnerabilities in systems (infrastructure, operating systems, applications and data) are identified, documented, validated and prioritised for remediation or mitigation in a timely manner, with all remediation and mitigation actions verified for effectiveness.
Identify known software and configuration weaknesses of assets through continuous and repeatable assessment activities, including vulnerability scanning activities.
Vulnerability scanning activities are not undertaken.
No routine vulnerability assessment activity has been conducted within a period defined by the organisation.
Advisories for relevant software and configuration weaknesses for organisational assets are not reviewed and assessed for impact.
Vulnerability scanning is deployed but does not cover all applicable assets.
Vulnerability scans are conducted but results are not reviewed and prioritised within timeframes defined by the organisation.
Vulnerability scans are conducted but frequency is not regular enough to enable timely response.
Scanning covers software vulnerabilities but not configuration weaknesses.
Advisories for relevant software and configuration weaknesses for organisational assets are reviewed on an ad hoc basis, or only for some assets.
All applicable assets are included in routine vulnerability scanning, and scanning frequency enables timely response.
Scanning covers both software vulnerabilities and configuration weaknesses.
Results are reviewed and prioritised within timeframes defined by the organisation.
Advisories for relevant software and configuration weaknesses in all organisational assets are regularly reviewed and assessed for impact.
Apply security patches or updates within defined risk-based timeframes or automatically where operational impact is low.
No defined patching timeframes exist for applicable assets.
Patches are not applied or are applied on an ad hoc basis with no tracking.
Expected patching timeframes are defined by the organisation but are not consistently met.
Patches are applied but compensating controls are not documented where operational constraints prevent timely patching.
Patching coverage metrics exist but show significant gaps.
Risk-based patching timeframes defined by the organisation are in place and consistently met.
Patching is prioritised based on vulnerability severity, exposure and exploit availability.
Where operational constraints prevent timely patching, compensating controls are documented and approved.
Patching coverage metrics account for all applicable assets, with any exclusions identified and formally risk accepted.
Automatic patching of assets is applied where available and the organisation has determined operational impact is low.
Remediate or mitigate vulnerabilities exceeding defined risk thresholds within defined timeframes based on exploitation, exposure, criticality, impact and compensating controls, and verify treatment effectiveness.
No risk thresholds are defined for vulnerability remediation.
Vulnerabilities exceeding acceptable risk levels are not tracked or remediated.
Risk thresholds are defined but vulnerabilities exceeding them are not consistently remediated within defined timeframes.
Compensating controls are applied in some cases but are not formally documented or approved.
Risk thresholds defined by the organisation exist, and vulnerabilities exceeding them are remediated or have approved compensating controls within organisationally defined timeframes.
Remediation and mitigation actions are tracked to closure with verification that actions reduced the risk as intended.
The process is sustained, with historical data demonstrating consistent performance across organisationally defined reporting periods.
Systems (operating systems and applications) only permit the execution of software that is supported, verified and authorised.
Permit only supported, verified and organisation-authorised software to execute on systems, with exceptions minimised, formally risk accepted, time-bound, monitored and regularly reviewed.
Unsupported, unverified or unauthorised software can execute without restriction.
The list of approved software does not exist.
Execution restriction controls are deployed but do not cover all applicable assets.
The organisation maintains a list of approved software, but it has not been reviewed within timeframes defined by the organisation.
Execution restrictions are in place but integrity verification of approved software is not performed.
Exceptions to execution restrictions are granted without formal approval or time-bounding.
Controls restrict execution to supported, organisation-authorised and integrity-verified software on all applicable assets.
The organisation maintains a list of approved software and reviews it within the timeframes defined by the organisation.
Integrity of permitted software is verified using trusted mechanisms appropriate to the software and its source.
Exceptions are formally approved, documented, time-bound and reviewed on a regular cycle defined by the organisation.
Restrict administrative and management tooling to approved software sets and executed from only authorised, known locations.
No approved administrative toolset is defined.
No restrictions are placed on the location administrative tooling can be executed from.
No controls prevent unapproved administrative tools, including tools commonly used in post-compromise activity, from executing on managed assets.
An approved toolset is defined but not consistently enforced across all assets.
Administrative tooling is configured to execute from known locations, but privileged users can still run tooling from unapproved locations.
Some unapproved administrative tools are blocked but enforcement gaps exist.
A defined and enforced approved toolset exists for administrative and management activities, and execution is limited to authorised, known locations.
Administrative and management tooling outside the approved set is blocked from execution, including from unauthorised locations.
Systems (infrastructure, operating systems, applications and data) are regularly backed up in a secure and proven manner, including through the validation of restoration capabilities.
Back up important data, applications and settings on a defined schedule to secure, resilient storage protected by encryption and immutable, offline, logically isolated or equivalent controls.
No managed backup process exists for important data, applications and settings.
Backup storage is neither encrypted nor protected by immutable, offline, logically isolated or equivalent controls.
Important data, applications and settings are backed up, but backup schedules are not defined, do not cover all important assets, or are not consistently met.
Backups are encrypted but no immutable, offline, logically isolated or equivalent resilience controls are consistently applied.
Backups use immutable, offline, logically isolated or equivalent controls, but encryption is not consistently enforced.
All important data, applications and settings are backed up according to schedules defined by the organisation and aligned with their recovery requirements.
Backup schedules are monitored, and missed or unsuccessful backups are identified, investigated and remediated within timeframes defined by the organisation.
Backup storage is encrypted and protected by immutable, offline, logically isolated or equivalent controls.
Isolate backup repositories from general user environments and production workloads, ensuring they are separated from primary systems to prevent unauthorised access, modification or deletion.
Backup repositories are accessible from the production environment or by production administrators.
Compromise of a system would provide a direct path to access, modify or delete its own backups.
Backup repositories are logically separated but use credentials managed by the same identity platform as production.
Isolation is implemented but has not been tested or validated.
Backup repositories are isolated from production environments and general user access.
Access is controlled through credentials and administrative paths isolated from compromise of the primary identity environment.
Isolation has been validated to confirm that compromise of a system does not provide access to backups.
Conduct regular testing of backup and restoration procedures to ensure that backups are reliable and capable of meeting defined recovery time objectives and recovery point objectives.
No restoration test has been conducted within the test cycle defined by the organisation.
No backup or restoration procedures exist.
Restoration testing demonstrates that backups cannot be restored, or consistently fail to meet defined recovery time or recovery point objectives.
Restoration testing has been conducted but does not cover all important assets.
Backup procedures exist but have never been tested.
Testing has been conducted but coverage is incomplete or some tests did not meet the expected recovery time or recovery point objectives.
Restoration testing covering important assets is conducted within the test cycle defined by the organisation.
Testing validates that restoration meets the expected recovery time and recovery point objectives.
Test results are documented and gaps identified during testing are remediated.
Systems (infrastructure, operating systems and applications) are segmented into network zones based on business criticality and trust levels, with only authorised, controlled and monitored inbound and outbound communication paths between network zones permitted.
Isolate systems within network zones based on business criticality and trust level, and restrict and monitor inbound and outbound access to explicitly approved pathways and services.
Systems are deployed on shared or flat network segments with no segregation between functions or trust levels.
No access controls restrict network access from external or general user networks to in-scope systems.
Segmentation is documented or administratively defined but not enforced by technical controls.
Segmentation has not been validated through technical assessment.
Network segmentation has been implemented but does not cover all in-scope systems, or segments are defined inconsistently.
Access controls exist between segments, but deny-by-default is not enforced, or some pathways are permitted without documented approval.
Technical enforcement is in place for some segments but relies on a single mechanism that does not provide meaningful isolation.
Validation has been performed for some segments but not consistently across in-scope systems, or validation is out of date.
Pathways are reviewed, but findings are not actioned, or the review cycle is not defined by the organisation.
Systems within scope are deployed in network segments defined according to function, criticality and trust level, with segmentation applied consistently.
Deny-by-default access controls are enforced between segments, with access from external and general user networks limited to documented and approved pathways.
Segmentation is enforced through network-layer technical controls that provide meaningful isolation.
Segmentation has been validated through technical assessment with results documented and gaps remediated.
Approved pathways are reviewed on a regular cycle defined by the organisation, with unjustified pathways removed and changes reflected in the access control configuration.
Limit lateral movement between, and within, network segments to explicitly approved pathways and services, based on business requirements and trust levels.
No controls limit lateral movement between or within network segments.
Lateral movement is permitted by default across the environment, with restrictions applied only on an exception basis.
Approved pathways are not documented.
Lateral movement controls have not been validated through technical assessment.
Pathways and services are not reviewed after initial approval.
Controls limit lateral movement between segments but no controls operate within segments.
Restrictions are applied to some pathways, but the default position remains permissive in parts of the environment.
Approved pathways are documented but documentation is out of date or incomplete.
Validation has been performed but does not cover all in-scope segments, or is out of date.
Pathways are reviewed, but findings are not actioned, or the review cycle is not defined by the organisation.
Controls limit lateral movement both between and within segments, with deny-by-default applied at each boundary.
Pathways and services are explicitly approved based on documented business requirements and trust levels, with all other lateral movement denied.
Approved pathways are documented, reflect the current configuration and identify the business requirement and trust relationship justifying each.
Lateral movement controls have been validated through technical assessment with results documented and gaps remediated.
Pathways and services are reviewed on a regular cycle defined by the organisation, with unjustified pathways removed and the configuration updated to reflect approved changes.
Data communicated between different security domains for systems (infrastructure and applications) is controlled and subject to inspection and verification.
Inspect outbound content flows to detect unauthorised transfer of sensitive or high-value data.
No outbound content inspection is deployed.
Sensitive data can leave the organisation through any egress path without detection or control.
Outbound inspection is deployed but does not cover all applicable egress paths.
Rules are configured but do not cover all classified, regulated or high-value data types.
Alerts are generated but are not triaged or acted upon in a timely manner.
Outbound content inspection is deployed covering all applicable egress paths.
Rules are configured to detect unauthorised transfer of classified, regulated and high-value data.
Alerts are triaged and responded to within accepted risk timeframes defined by the organisation.
Block outbound network connections to known malicious or untrusted destinations.
No controls are deployed to prevent systems from establishing outbound connections to known malicious or untrusted destinations.
Blocking decisions are not informed by current threat intelligence.
Destination categorisation is not used.
Controls to prevent outbound connections being established are deployed but cover only a subset of in-scope systems or egress paths.
Threat intelligence is used to inform block decisions for outbound connections, but updates are infrequent, manual or limited to a single source.
Categorisation is in place, but the categories blocked do not reflect the organisation’s risk position.
Controls are deployed and applied across in-scope systems, egress paths, services, and network boundaries.
Blocking decisions draw on current threat intelligence, with destination lists updated on a cycle defined by the organisation.
Destination reputation, category and age are considered alongside threat intelligence, with category-based blocking aligned to the organisation’s risk position.
Inspect inbound content from external or untrusted sources to prevent delivery of malicious or unsafe content.
No inbound content inspection is deployed.
Inbound inspection is deployed but does not cover all applicable content channels.
Inspection is in place but detection signatures or rules are not maintained or updated.
Inbound content inspection covers all applicable content channels.
Detection signatures and rules are maintained and updated on a regular cycle defined by the organisation.
Blocked content is logged and available for review.
Current cyber threat intelligence is considered when implementing controls to prevent the delivery of malicious or unsafe content.
Personnel are provided with ongoing cyber security awareness training, including operational security considerations, tailored to their duties, access levels and current cyber threats.
Ensure all personnel receive cyber security awareness training, that is tailored to how they will interact with systems, applications and data in their assigned roles, before being granted access to organisational systems and data.
No requirement exists for personnel to complete cyber security awareness training before being granted access to critical, privileged or business systems.
No training completion records are maintained.
A training program exists but is not tailored to the specific risks of the systems in-scope.
A requirement to complete training before access is granted exists but is not consistently enforced.
Completion records are maintained but show significant gaps in coverage.
Role-tailored training programs address the specific risks, data handling obligations and incident reporting requirements relevant to in-scope systems.
All personnel complete role-tailored training before being granted access to organisational systems and data, with refresher training mandated within a cycle defined by the organisation.
Completion records are maintained and demonstrate full coverage.
Update and provide cyber security awareness training on a regular basis to reflect current threats and operational considerations.
No cyber security awareness training program exists.
Cyber security awareness training is not reviewed or updated after initial deployment.
Lessons learnt from cyber security incidents are not incorporated into training content.
The cadence of review is not defined.
Training is reviewed but updates do not reflect current threat intelligence, sector relevant adversary techniques or organisational changes.
Some lessons are incorporated but the process is informal, or coverage is limited to a small number of incidents.
Some changes are reflected, but training is not updated to address recently introduced systems or significant changes to working arrangements.
A review cadence exists, but is not consistently met, or is not proportionate to the rate of change.
Training content is reviewed and updated on a defined cycle, with updates reflecting current threat intelligence, adversary techniques relevant to the workforce and organisation’s operating context.
Lessons learnt from cyber security incidents within the organisation or its sector are systematically incorporated into training content.
Training reflects the systems, platforms and working arrangements that personnel currently interact with, including newly introduced platforms and changes to ways of working.
The cadence of review is defined, proportionate to the rate of change in the threat environment, and consistently met.
Security-relevant event logs and configuration changes for systems (infrastructure, operating systems, applications and data) are centrally collected, protected against unauthorised modification or deletion, and retained to support effective cyber security event detection and investigation.
Protect event logs from unauthorised access, modification or deletion, including by encrypting them during transit and at rest and securing the systems and accounts used to store, manage and analyse them.
Logs generated by applicable assets are not protected from modification or deletion.
Log access is not restricted to authorised roles with a business need.
Logs are neither encrypted during transit nor at rest.
Logs are forwarded but integrity protections are not in place at the source.
Log access is restricted but some roles retain the ability to modify or delete logs.
Logs are encrypted during transit but are not protected with encryption at rest (or vice versa).
Logs are protected against modification or deletion.
Logs are encrypted in transit and at rest.
Access to logs is restricted to authorised roles with a business need.
Forward high-value, security-relevant event logs and configuration changes from infrastructure, operating systems and applications to a central log storage capability.
Security-relevant logs from assets are not forwarded to a central logging capability.
High-value, security-relevant event logs or configuration changes from infrastructure, operating systems or applications are not forwarded.
High-value, security-relevant event logs are forwarded, but coverage gaps are identified or completeness has not been validated.
Configuration change logs are forwarded inconsistently.
The utility of security log sources is reviewed, but on an ad hoc basis rather than according to a defined schedule.
Log forwarding is in place but latency is excessive for effective detection.
High-value security-relevant event logs and configuration changes from all relevant infrastructure, operating systems and application sources are forwarded to the central logging capability.
Security log sources are reviewed at regular intervals to ensure their continued utility in detecting and responding to changing adversary techniques.
Log completeness has been validated against the expected log sources.
Logs are forwarded at a frequency that enables timely detection.
Establish a centralised event log storage capability that protects logs from unauthorised access or modification.
No centralised capability exists for storing event logs collected from systems across the environment.
Stored logs have no protection against modification or deletion by administrators of the systems generating them.
Access to the centralised capability is not restricted, or access is granted to roles without a documented need.
Log retention requirements are not defined.
A centralised capability exists but does not receive logs from in-scope systems, or coverage is inconsistent.
Stored logs are protected from modification, but the controls do not consistently prevent deletion, or controls are not applied to all log types.
Access is restricted to a defined set of roles but access is not logged or monitored.
A retention period is defined but is inconsistently applied, or some log types are retained for shorter periods than required.
A centralised event log storage capability is in place for logs collected from in-scope systems.
Stored logs are protected against unauthorised access, modification and deletion through technical controls including access restrictions, encryption at rest and integrity protection.
Access to the centralised capability is restricted to security operations personnel and other roles with a documented need, with access logged and monitored.
Log retention requirements are defined and aligned to investigative, regulatory and contractual obligations, with retention applied consistently across log types.
Baseline patterns of identity and credential access activities, privileged access activities, and remote access activities are established and maintained for systems (infrastructure, operating systems, applications and data) to enable the detection of anomalous or unexpected behaviour.
Continuously monitor and analyse software execution behaviour on systems to detect where legitimate tools and utilities are being used for malicious purposes.
No monitoring or equivalent analysis is used to identify anomalous or unexpected use of legitimate tools and utilities on applicable systems.
Existing controls do not provide a reasonable capability to detect security-relevant patterns of legitimate software being used for malicious purposes.
Monitoring or equivalent analysis covers some priority tools, execution behaviours or applicable systems, but risk-significant coverage gaps exist.
Security-relevant execution telemetry is collected, but detection rules, behavioural analytics or equivalent analysis are incomplete or not consistently operational.
Alerts relating to anomalous or unexpected software execution are generated, but they are not consistently triaged and investigated within organisationally defined timeframes.
The organisation identifies the legitimate tools, utilities and execution behaviours that present heightened risk of malicious use within applicable systems.
Security-relevant telemetry and contextual information are analysed using detection rules, behavioural analytics or equivalent methods to identify anomalous or unexpected use of priority tools and utilities.
Detection coverage is periodically reviewed and adjusted in response to changes in applicable systems, threat intelligence, observed activity and the organisation’s risk profile.
Alerts are prioritised, triaged and investigated within timeframes defined according to their assessed security risk.
Anomalous or unexpected events and behaviours for systems (infrastructure, operating systems, applications and data) are analysed in a timely manner to detect cyber security events.
Ensure event logs are normalised, time-synchronised and enriched to support correlation across systems and environments.
Logs are not time-synchronised to an authoritative source.
Logs are ingested in raw format and are neither normalised nor enriched.
Logs are time-synchronised but are not normalised to a common schema.
Some enrichment is applied but critical contextual data such as asset classification or account type is missing.
Logs are time-synchronised to the authoritative time source.
Logs are normalised into the common log schema and enriched with contextual metadata.
Enriched logs support correlation across relevant systems, environments and data sources in the central logging platform.
Ensure detection logic identifies unauthorised changes, anomalous authentication activity and suspicious software execution.
No detection logic is deployed to identify unauthorised changes, anomalous authentication activity or suspicious software execution events originating from assets.
Detection relies entirely on manual log review with no automated rules or alerting.
Detection logic exists but does not cover all three categories (unauthorised changes, anomalous authentication, suspicious execution).
Rules are deployed but are not tested or tuned on a regular cycle defined by the organisation.
Detection logic is deployed, and unauthorised configuration changes, anomalous authentication patterns and suspicious process execution events are captured and produce alerts.
Detection logic is tested and tuned on a regular cycle defined by the organisation to maintain effectiveness.
Detection coverage is reviewed following cyber security incidents or significant environmental changes.
Cyber security events are analysed in a timely manner to identify cyber security incidents.
Triage alerts and events in a timely manner to determine whether cyber security incident thresholds have been met.
No documented triage process exists.
Alerts are routinely ignored or left unreviewed.
No incident severity thresholds are defined.
A triage process exists but response times are not defined or consistently met.
Severity thresholds are defined but escalation procedures are informal.
A documented triage process with defined severity thresholds and response timeframes is in place.
Alerts are triaged within the timeframes defined by the organisation and escalated where cyber security incident thresholds are met.
Triage performance is tracked and reported.
Use indicators from across identities, applications, data and infrastructure activity rather than isolated signals when identifying cyber security incidents.
Investigation relies on single-source alerts with no cross-source correlation.
Correlation rules do not consider signals from multiple data sources.
Some correlation exists but is limited to specific data source pairs.
Cross-source investigation is performed manually but not supported by automated correlation.
Correlation rules and investigation procedures consider signals across identities, applications, data and infrastructure.
Automated correlation supports detection of multi-stage adversary activity.
Cyber security event detection capabilities are regularly evaluated for effectiveness and continuously refined, including by using current strategic and sector-specific cyber threat intelligence, to improve the detection of cyber security events.
Review detection coverage periodically to identify gaps arising from new assets, services or architectural changes.
No review of detection coverage has been conducted within the period defined by the organisation.
No process exists to assess new assets and services for log coverage or detection applicability.
A review of detection coverage has been conducted but does not cover all recently deployed assets or services.
Detection gaps have been identified and remediation is planned, but remediation has not been executed within timeframes defined by the organisation.
A detection coverage review has been completed within the cycle defined by the organisation.
New assets and services are assessed for log coverage and detection rule applicability.
Identified detection gaps are remediated within risk-based timeframes defined by the organisation.
Cyber security incident roles and responsibilities are defined, documented and exercised to support the internal and external coordination and management of cyber security incidents, including responsibilities for declaring cyber security incidents and undertaking pre-approved response and recovery activities.
Integrate external coordination obligations into cyber security incident response activities where required.
External coordination requirements for Cyber security incident response activities are neither identified nor documented.
No defined triggers, contacts or timeframes exist for external reporting.
External coordination requirements are documented but are not integrated into operational response procedures.
Contacts and triggers are defined for some but not all required external parties.
Cyber security incident response procedures include documented external coordination requirements with defined triggers, contacts and timeframes.
Requirements cover all relevant external parties identified by applicable legal, regulatory, contractual and organisational obligations.
Coordination procedures have been exercised or invoked and lessons learnt have been incorporated.
Cyber security incidents are contained, eradicated and recovered from in a timely manner.
Use documented, tested and approved cyber security incident response procedures when responding to cyber security incidents.
No documented cyber security incident response plan or procedures exist.
Incident response activities are conducted on an ad hoc basis without any defined roles, escalation paths, procedures or response objectives.
Available incident records demonstrate systemic failures to contain, eradicate or recover from cyber security incidents within organisationally defined timeframes, and the causes of these failures are not addressed.
A cyber security incident response plan exists but has not been exercised or invoked within the organisationally defined test cycle.
The cyber security incident response plan defines roles, escalation paths, and response procedures, but target timeframes or intended response outcomes are not clearly defined.
Incident records or exercise results demonstrate that response activities do not consistently meet organisationally defined timeframes or intended outcomes, but identified deficiencies are documented and subject to improvement actions.
An approved cyber security incident response plan is in place and defines roles, escalation paths, response procedures, target timeframes and intended containment, eradication and recovery outcomes.
The incident response plan and associated procedures have been exercised or invoked within the organisationally defined test cycle.
Incident records demonstrate that cyber security incidents are contained, eradicated and recovered from within organisationally defined target timeframes and achieve the intended response outcomes, taking into account incident severity, complexity and business impact.
Where target timeframes or intended outcomes are not achieved, the causes are analysed, improvement actions are assigned and tracked, and relevant plans, procedures and controls are updated.
Where no relevant cyber security incident has occurred during the assessment period, appropriately scoped exercises demonstrate the organisation’s capability to achieve its target timeframes and intended response outcomes.
Lessons learnt from cyber security incidents are captured, and areas for improvement are identified, prioritised and actioned in a timely manner.
Perform post-cyber security incident reviews to identify the security gaps that enabled each stage of the cyber security incident.
Post-incident reviews are not conducted.
Post-incident reviews are conducted for some incidents but not all that meet the severity threshold defined by the organisation.
Reviews are conducted but findings are not documented or actioned.
Post-incident reviews are conducted for all incidents meeting the severity threshold defined by the organisation.
Findings identify the specific gaps that enabled each stage of the incident.
Remediation actions arising from findings are implemented and tracked to closure.
Evaluate the monitoring coverage and cyber security incident response procedures following cyber security incidents.
Detection rules, monitoring coverage and response procedures are not reviewed following incidents.
Reviews are conducted but do not result in documented changes to detection or response capabilities.
Some improvements are made but not systematically tracked or validated.
Detection rules, monitoring coverage and cyber security incident response procedures are reviewed following incidents, with identified lessons incorporated into updates.
Changes are documented, tested and validated for effectiveness.