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.
Systems (infrastructure, operating systems, applications, identities, credentials and data) are continually and centrally identified and documented.
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.
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.
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.
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.
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.
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.
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.