NIST SP 800-53 Rev 5

Requires an access control policy and supporting procedures to be written, approved, issued to the personnel who must apply them, owned by a named official, and reviewed and reissued on a defined frequency and after defined trigger events, with the scope, owner, audience and review cadence all set by the organization.

• Approved access control policy showing issue date, approver and stated scope
• Distribution or acknowledgement record proving the policy reached the defined audience
• Written designation of the official accountable for the policy and its procedures
• Access control procedure documents that operationalise each policy statement
• Review log showing the last review against the defined frequency and any event-driven review

• Policy exists but the review frequency and triggering events were never defined, so no review is ever due
• Procedures describe an older toolset and no longer match how access is actually granted
• No named official owns the policy, so updates stall between security and IT operations

Concurrent Session Control. Limit the number of concurrent sessions for each [organization-defined] to [organization-defined]

• Defined limit on concurrent sessions per account type, and the account types it applies to
• System configuration setting that enforces the session count limit, exported from the identity or application platform
• Log or screenshot of an attempted session beyond the limit being refused or the oldest session terminated
• Record of who approved the limit and on what basis, such as licence model or account sensitivity

• Limit written into the security plan but never configured in the platform that issues sessions
• Enforcement applied to interactive logon only while API tokens and service sessions are uncounted
• Privileged accounts left unlimited on the argument that administrators need flexibility

Requires a session to be locked after an organization-defined period of inactivity or on user command, hiding what was on screen, and to stay locked until the same user re-authenticates through the normal identification and authentication path.

• Endpoint policy object or MDM profile showing the configured inactivity lock timeout
• Screenshot or configuration export showing the pattern hiding the previous display
• Sample of workstation configuration compliance results across the estate
• Exception register for devices where the lock is relaxed, with approval and compensating measures

• Lock timeout enforced on corporate laptops but not on shared operational consoles or kiosks
• Screen lock configured as a user preference that a user can disable
• Re-entry allowed with a local unlock that bypasses central authentication

Requires user sessions to be terminated automatically when organization-defined conditions or trigger events occur, such as elapsed session time or period of inactivity, rather than left open until the user chooses to close them.

• Documented list of the conditions and trigger events that force session termination
• Application or platform configuration showing session timeout values in force
• Session logs demonstrating automatic termination events actually firing
• Design note covering how long-running or batch sessions are treated

• Termination conditions never defined, so the control has no measurable target
• Web tier enforces a timeout while the underlying API tokens remain valid for far longer
• Termination logs out the interface but leaves the server-side session or token alive

Requires the organization to identify and formally document the specific user actions that may be performed on the system without identifying or authenticating the user, and to record in the system security plan the business rationale for each one.

• Documented list of actions permitted without identification or authentication
• Security plan section carrying the rationale for each permitted action
• Configuration evidence showing no action beyond that list is reachable unauthenticated
• Review record confirming the list is revisited when functionality changes

• Public pages and unauthenticated APIs grew over time and were never added to the list
• Rationale recorded as convenience rather than a mission or business need
• List documented once at authorization and never reconciled with the deployed system

Security and Privacy Attributes. Provide the means to associate [organization-defined] with [organization-defined] for information in storage, in process, and/or in transmission; Ensure that the attribute associations are made and retained with the information; Establish

• Defined set of security and privacy attributes and the permitted values for each
• Design documentation showing where attributes bind to information at rest, in process and in transit
• Evidence that attribute associations persist through transformation, export and transfer, not just at creation
• Record of the authorised personnel or processes permitted to change an attribute value
• Audit records of attribute changes showing who altered a value and when

• Attributes applied at ingest and silently stripped when data is copied to a reporting store or extract
• Permitted value set undefined, so free text labels accumulate and no rule can act on them
• No audit of attribute change, so a downgrade from restricted to public leaves no trace

Requires each type of remote access to the system to be governed by documented usage restrictions, connection and configuration requirements and implementation guidance, and to be explicitly authorized before any remote connection is permitted.

• Remote access standard listing each permitted access type and its restrictions
• Authorization records approving each remote access method before use
• VPN or remote gateway configuration showing the required settings in force
• Inventory of remote access paths including vendor and administrative routes

• Vendor support tools provide a remote path that was never authorized as a remote access type
• Restrictions written for the VPN only, while remote desktop and cloud consoles go untreated
• No record of authorization, only the technical fact that the method works

Requires configuration and connection requirements plus implementation guidance to be established for every type of wireless access, and each wireless access type to be authorized before any wireless connection to the system is allowed.

• Wireless standard covering authentication, encryption and connection requirements per access type
• Authorization record for each wireless network or access type in use
• Wireless controller configuration export and site survey or rogue access point scan results
• Register of guest and operational technology wireless segments and their approvals

• Guest wireless deployed by facilities without a security authorization
• Legacy encryption left enabled on an older service set for compatibility
• Rogue and unmanaged access points never scanned for, so unauthorized wireless is invisible

Requires documented configuration settings, connection rules and implementation guidance for mobile devices the organization controls, including their use away from controlled areas, and explicit authorization before any such device connects to an organizational system.

• Mobile device standard covering encryption, lock, patching and off-site use
• Mobile device management enrolment report reconciled to the device inventory
• Authorization records for mobile device connection to each in scope system
• Evidence of enforcement action on non-compliant or unenrolled devices

• Personally owned devices reach corporate mail with no enrolment or authorization
• Requirements stop at the device and ignore removable storage attached to it
• Inventory drifts, so devices that left the organization still hold valid connection profiles

Requires accounts to be managed across their full life cycle: permitted and prohibited account types defined, account managers assigned, membership prerequisites and approvals required, accounts created, modified, disabled and removed under documented criteria, usage monitored, and access reauthorized on a defined frequency.

• Account type register showing which account types are permitted and which are prohibited
• Provisioning and deprovisioning tickets carrying documented approval by the responsible party
• Leaver reconciliation between the human resources record and account disablement dates
• Periodic account recertification results with evidence that revocations were executed
• Monitoring output for atypical account usage and for dormant accounts

• Shared and service accounts sit outside the joiner mover leaver process entirely
• Recertification is signed off in bulk without any account actually being removed
• Contractor and third party accounts outlive the engagement because no end date is held

Requires terms to be established, or existing external system relationships identified, before authorized individuals may reach the system from external systems or handle organizational information on them, or alternatively requires organization-defined types of external system to be prohibited outright.

• Documented terms and conditions or agreements covering permitted external system use
• Register of external systems recognised as trusted and the basis for that trust
• Policy statement naming external system types that are prohibited
• Technical enforcement evidence such as blocked personal cloud storage or unmanaged device denial

• Terms exist on paper while unmanaged home devices connect freely in practice
• Prohibited categories never enumerated, so nothing can be enforced or tested
• Trust relationships assumed from a commercial contract that never mentions security requirements

Information Sharing. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information's access and use restrictions for [organization-defined] ; and Employ [organization-defined] to assist users in making information

• Defined list of information sharing circumstances where user discretion is required
• Names or roles of the users authorised to make a sharing decision
• The automated mechanism or aid presented to the user at the point of sharing, with a screenshot of what it shows
• Sample sharing decisions showing the partner's access authorisations were compared against the information's use restrictions
• Access and use restrictions recorded against the shared information itself

• Sharing left to individual judgement with no aid, so the user cannot see the partner's authorisations
• Restrictions attached to the information at classification but not carried into the sharing interface
• Decision recorded nowhere, so a disputed disclosure cannot be reconstructed

Requires named individuals to be authorized and trained to publish information publicly, content to be reviewed for nonpublic information before it is posted, and published content to be re-reviewed on a defined frequency with anything nonpublic removed on discovery.

• List of individuals authorized to publish, with evidence of the training they received
• Pre-publication review records showing sign-off before posting
• Periodic sweep results of live public content against the defined review frequency
• Removal or takedown records for nonpublic information found on public surfaces

• Marketing and product teams publish directly with no review step
• Review covers the website but not public code repositories, file shares or open storage buckets
• Periodic re-review never scheduled, so old pages retain information that later became sensitive

Data Mining Protection. Employ [organization-defined] for [organization-defined] to detect and protect against unauthorized data mining

• Identification of the data storage objects holding information at risk of mining, such as warehouses or aggregated stores
• Documented data mining prevention and detection techniques in use, including query rate and volume thresholds
• Configuration of the mechanism enforcing those thresholds against the storage objects named
• Detection records showing anomalous extraction patterns raised for review
• Definition of which mining techniques are authorised, so the detection distinguishes analysts from adversaries

• Protection applied to the production database while the analytics replica holding the same data is uncontrolled
• No threshold defined, so bulk extraction looks identical to normal query load
• Authorised analytics never baselined, producing enough noise that detections are routinely dismissed

Access Control Decisions. [organization-defined] to ensure [organization-defined] are applied to each access request prior to access enforcement

• Documented access control decision procedure showing the decision is reached before enforcement, not after
• Design documentation identifying the policy decision point and the policy enforcement points it serves
• The attributes and policies the decision uses, and where they are sourced at decision time
• Audit records of access decisions showing the decision outcome and the inputs that produced it
• Evidence that enforcement points cannot grant access without a decision, including on failure of the decision service

• Enforcement points cache a prior decision and keep serving access after the underlying authorisation is revoked
• Decision service failure treated as allow, so an outage becomes an authorisation bypass
• Decision inputs not logged, so an assessor cannot tell which policy produced a given grant

Reference Monitor. Implement a reference monitor for [organization-defined] that is tamperproof, always invoked, and small enough to be subject to analysis and testing, the completeness of which can be assured

• Identification of the access control policies the reference monitor mediates
• Design documentation demonstrating the monitor is always invoked, with no bypass path around it
• Tamper protection evidence for the monitor itself, such as memory protection or signed and immutable deployment
• Analysis or test results showing the monitor is small enough for its completeness to be assured
• Verification that the monitor cannot be disabled or reconfigured by the subjects it mediates

• A bypass path exists for maintenance or break glass access that the always invoked claim does not cover
• Tamperproof asserted from platform hardening with no evidence specific to the monitor
• Size and complexity never analysed, so completeness of mediation is claimed rather than assured

Requires the system to technically enforce the access authorizations that policy has approved, so that logical access to information and system resources is permitted only where an approved authorization exists.

• Access control configuration export showing permissions as enforced by the system
• Mapping from approved authorization records to the entitlements actually held
• Test results demonstrating denial of access outside an approved authorization
• Evidence of enforcement at each layer including database, storage and administrative interfaces

• Enforcement present in the application but absent at the database or storage layer beneath it
• Entitlements accumulate through role changes so effective access exceeds what was approved
• Emergency or break glass paths bypass enforcement without compensating logging

Requires information flows within the system and between connected systems to be controlled against approved authorizations, using flow control policies the organization defines, so that data cannot move between domains or destinations that were never approved.

• Documented information flow control policy and approved flow matrix
• Firewall, proxy or data loss prevention rule sets that implement the approved flows
• Network diagram showing enforcement points between security domains
• Rule review records confirming permissive or stale flows were removed

• Flow matrix exists on paper while the rule base carries broad any to any allowances
• Egress flows unmanaged even where ingress is tightly controlled
• Cloud to cloud and service to service traffic is outside the flow model entirely

Requires the organization to identify and document the individual duties that must be kept apart to limit malevolent activity without collusion, and to define system access authorizations so that those duties cannot be exercised by one person.

• Documented conflicting duty pairs for the mission and system in question
• Role definitions and entitlement mapping showing conflicting duties are not held together
• Toxic combination report from the identity system or a manual conflict analysis
• Approved exceptions with the compensating detective controls applied

• Conflicting duties named for finance processes only and never for system administration
• Small teams create unavoidable conflicts that are tolerated rather than documented and compensated
• Separation enforced at role definition but broken by direct entitlement grants

Requires access for users and for processes acting for them to be limited to what their assigned tasks actually need, so that no account, role or process holds privileges beyond the minimum required to do its job.

• Role to entitlement mapping showing privileges justified against job function
• Privileged account inventory with business justification for each
• Review evidence where excess privilege was identified and removed
• Configuration showing service and application accounts run without administrative rights

• Administrator rights granted as a default to speed up troubleshooting and never revoked
• Service accounts run with far more privilege than the application needs
• Least privilege applied to people while automation and pipeline identities are unrestricted

Requires a limit on consecutive failed logon attempts within a defined time period, and an automatic response when the limit is passed, such as locking the account or node for a defined period, holding it until an administrator releases it, delaying the next prompt, or notifying an administrator.

• Authentication policy configuration showing threshold, counting window and lockout response
• Sample account lockout events from authentication logs
• Documented values chosen for attempt count, time period and lockout duration
• Coverage evidence across all authentication surfaces including remote and application logins

• Threshold enforced on the directory but not on the internet facing application login
• Lockout response set to notify only, so brute force attempts continue unimpeded
• Values never formally defined, leaving defaults that nobody has reviewed

System Use Notification. Display [organization-defined] to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:

• The approved system use notification text, with documented approval by the organisation
• Screenshot of the banner as displayed before access is granted, on each access path including remote and mobile
• Evidence the banner remains on screen until the user takes explicit action to acknowledge it
• For publicly accessible systems, the system use information displayed and the description of authorised uses
• Legal or privacy review record confirming the wording matches applicable laws, directives and policies

• Banner present on desktop logon but absent from VPN, SSH and API access paths
• Banner auto dismisses on a timer, so no explicit acknowledgement is captured
• References to monitoring and recording omitted on public facing systems where the wording differs by design

Previous Logon Notification. Notify the user, upon successful logon to the system, of the date and time of the last logon

• Configuration enabling display of last logon date and time on successful logon
• Screenshot of the notification a user actually sees at logon
• Evidence the notification is presented on each access path where the control is claimed
• Procedure telling users what to do when the previous logon shown is not theirs, and where that report goes

• Data is captured in logs but never surfaced to the user, which is the point of the control
• Notification shown at console logon only while federated and single sign on paths show nothing
• No reporting route defined, so a user who spots an unfamiliar logon has nowhere to raise it

Requires an awareness and training policy plus supporting procedures to be written, approved, distributed to defined personnel, assigned to a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved awareness and training policy with scope, approver and date
• Evidence the policy reached the defined recipients
• Designation of the official accountable for the training programme
• Procedures describing how training is assigned, delivered and tracked
• Review record against the defined frequency and any triggering event

• Training policy inherited from a corporate handbook and never tailored to this system
• No defined review cadence, so content ages past its relevance
• Policy silent on contractors and third party personnel who use the system

Requires security and privacy literacy training for all system users including managers, executives and contractors, given at induction and repeated on a defined frequency and after defined system changes or events, with awareness techniques employed, content refreshed, and incident lessons folded back into it.

• Training completion report covering all user categories including executives and contractors
• Course content showing the security and privacy topics delivered
• Record of awareness techniques used such as simulated phishing or targeted campaigns
• Change log showing content updated after incidents or system changes

• Completion tracked for employees while contractors and vendors are omitted
• Content unchanged year to year, so it does not reflect the threats actually seen
• Incidents produce a post mortem but never reach the awareness material

Requires role-based security and privacy training for personnel holding organization-defined roles, delivered before access or duties begin and repeated on a defined frequency and on system change, with content refreshed and incident lessons incorporated.

• Defined list of roles requiring role-based training and the syllabus for each
• Completion records showing training preceded the grant of access or duties
• Refresher completion evidence against the defined frequency
• Content revision history reflecting system changes and incident lessons

• Privileged administrators receive only the general awareness course
• Training delivered after access was already granted rather than before
• Developer and incident responder roles identified but no distinct syllabus exists for them

Requires training activity to be documented and monitored across both general awareness and role-based training, and requires individual training records to be kept for an organization-defined retention period.

• Training register listing individuals, courses completed and dates
• Defined retention period for training records and evidence it is applied
• Monitoring report showing outstanding or overdue training being chased
• Retained records for leavers covering the required period

• Records live inside a learning platform whose retention is shorter than the defined period
• Role-based training tracked informally by managers and never consolidated
• No monitoring of non-completion, so overdue training is invisible

Requires the results of organizational training to be fed back to organization-defined personnel on a defined frequency, so that those accountable for the programme can see participation and outcomes and act on them.

• Training results report issued to the defined recipients
• Defined recipient list and reporting frequency
• Distribution evidence such as meeting minutes recording receipt
• Evidence of action taken in response to reported results

• Reports produced but sent to no defined audience
• Feedback limited to completion percentages with no view of effectiveness
• Reporting frequency never set, so it happens only when someone asks

Requires an audit and accountability policy and supporting procedures to be developed, approved, issued to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved audit and accountability policy with scope, approver and date
• Evidence of dissemination to the defined personnel or roles
• Designation of the official responsible for the policy and procedures
• Logging procedures covering what is logged, where it goes and who reviews it
• Review record for the audit and accountability policy and procedures against the defined frequency and triggering events

• Policy describes on-premises logging only while workloads have moved to cloud services
• Procedures do not say who reviews logs or how often
• Review cadence and triggering events left undefined

Non-repudiation. Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed [organization-defined]

• Definition of the actions requiring irrefutable attribution, such as approvals, releases or transmissions
• The binding mechanism used, for example digital signature over the action and its content
• Key management evidence showing the signing key is bound to one individual and not shared
• Sample signed records with successful verification output
• Evidence that the signature covers the action content, so the record cannot be altered after signing

• Shared or role based signing credentials, which defeats attribution to an individual
• Signature covers a hash captured at submission but not the content finally stored
• No retained means to verify old signatures once the certificate expires or is rotated

Requires audit records to be kept for an organization-defined retention period that is long enough to support after the fact investigation of incidents and to satisfy applicable regulatory and internal retention obligations.

• Documented audit record retention period and the obligations that justify it
• Log platform retention configuration and archive tier settings
• Evidence a record from the oldest retained period can still be produced and read
• Reconciliation showing every in scope log source inherits the retention setting

• Retention period set by storage cost rather than by investigative and regulatory need
• Hot search retention meets policy while archived records are unreadable or unrestorable
• Some log sources default to a short retention and were never brought into the policy

Requires the system to be able to generate audit records for the auditable event types on organization-defined components, to let defined personnel choose which events specific components log, and to produce records carrying the required record content.

• List of system components in scope for audit record generation
• Configuration showing logging enabled on each in scope component
• Sample generated audit records demonstrating the required content fields
• Documentation of which roles may change the event selection and how that is controlled

• Logging enabled on servers but absent on network devices, containers or cloud control planes
• Ability to change event selection is unrestricted, so logging can be silently reduced
• Records generated but stripped of fields needed to attribute the event

Monitoring for Information Disclosure. Monitor [organization-defined] [organization-defined] for evidence of unauthorized disclosure of organizational information; and If an information disclosure is discovered: Notify [organization-defined] ; and Take the following additional actions: [organization-defined]

• The defined open source information sites, forums and paste sites monitored, and the monitoring frequency
• Search terms or organisational identifiers monitored for, such as domains, code signatures or document markings
• Monitoring output records covering the review period, including nil findings
• Notification records showing the defined personnel were alerted when a disclosure was found
• The additional response actions defined and evidence they were executed on a real finding

• Monitoring covers brand mentions but not the credential dumps and code repositories where disclosure actually surfaces
• Findings routed to marketing or legal without ever reaching incident response
• Frequency undefined, so monitoring happens when someone remembers

Session Audit. Provide and implement the capability for [organization-defined] to [organization-defined] the content of a user session under [organization-defined] ; and Develop, integrate, and use session auditing activities in consultation with legal counsel and

• The defined circumstances under which session capture or record and view is invoked
• The users or roles able to invoke session audit, and the approval required
• Configuration of the session capture capability and a sample captured session
• Legal counsel consultation record, plus the civil liberties or privacy officials engaged
• Retention, access and handling rules for captured session content, given that it may hold personal data

• Capability deployed broadly and always on, exceeding the defined circumstances
• Legal and privacy consultation absent, which the control requires explicitly and an assessor checks for
• Captured sessions retained indefinitely with the same access as ordinary logs

Cross-organizational Audit Logging. Employ [organization-defined] for coordinating [organization-defined] among external organizations when audit information is transmitted across organizational boundaries

• Agreements with each external organisation covering audit information exchanged across the boundary
• The defined methods for coordinating audit information, such as agreed formats, identifiers and time base
• Evidence that audit information transmitted externally preserves the identity of the originating subject
• Records of audit information actually exchanged during the period
• Points of contact on both sides for audit coordination and dispute

• Logs shared with a provider under contract while no method exists to correlate their records with yours
• Timestamps in different zones or unsynchronised clocks, so cross boundary sequences cannot be reconstructed
• Subject identity anonymised in transit for privacy reasons with no agreed way to re-attribute during an investigation

Requires identification of the events the system can log, coordination with the parties who need audit information, selection of the specific event types to be logged with the frequency or situation for each, a documented rationale for that selection, and review of the selection on a defined frequency.

• Catalogue of loggable event types for the system
• Approved list of selected event types with logging frequency or trigger
• Written rationale linking the selection to investigation and monitoring needs
• Minutes or correspondence evidencing coordination with incident response and other consumers
• Review record showing the selection was revisited on the defined frequency

• Event selection copied from a vendor default with no rationale recorded
• Selection never reviewed after new components or new threats appeared
• Consumers of the logs were never consulted, so the events captured do not support their work

Requires each audit record to carry enough detail to establish what type of event occurred, when and where it occurred, its source, its outcome, and the identity of the individuals, subjects or objects associated with it.

• Sample audit records from each major log source showing all required elements present
• Field mapping documenting where each required element is carried
• Normalisation or parser configuration in the log platform
• Gap analysis of sources that cannot supply a required element and the compensating approach

• Records show an action but not the actor, so accountability cannot be established
• Source address lost behind a proxy or load balancer and never preserved
• Outcome not recorded, so a failed and a successful attempt look the same

Requires audit log storage to be sized and allocated against the retention requirements the organization has set, so that logging capacity does not run out and records are not lost before their retention period ends.

• Capacity calculation linking log volume and retention period to allocated storage
• Storage utilisation trend for the logging platform
• Alert configuration for approaching capacity limits
• Evidence of headroom or expansion action taken when growth increased

• Capacity sized at deployment and never revisited as log volume grew
• Overflow silently overwrites the oldest records rather than raising an alert
• Local device buffers overwrite within hours and forwarding failures go unnoticed

Requires defined personnel to be alerted within a defined time period when the audit logging process fails, and requires the organization to take the additional response actions it has defined for that failure.

• Alert configuration for logging process failure with the defined notification window
• Defined recipient list and the additional actions to be taken on failure
• Sample alert and the ticket showing response within the required time
• Test evidence proving a simulated logging failure raises the alert

• Failures of the log forwarder itself are unmonitored, so silence looks like health
• Alerts route to a mailbox nobody owns
• Additional actions never defined, so the response is improvised each time

Requires audit records to be reviewed and analysed on a defined frequency for indications of organization-defined inappropriate or unusual activity and its likely impact, findings to be reported to defined personnel, and the depth of review to be increased when credible information changes the risk.

• Defined review frequency and the activity indicators being looked for
• Completed review records with reviewer, date and findings
• Reports issued to the defined recipients and evidence of follow-up
• Record of a review level adjustment made in response to changed risk

• Review is automated alerting only, with no periodic analytical review for slow patterns
• Findings recorded but never reported to anyone able to act
• No mechanism to raise review intensity when threat information changes

Requires a capability that reduces audit records and generates reports, able to serve review, analysis and reporting on demand and to support later investigation of incidents, while leaving the original records unchanged in both content and time order.

• Log platform capability documentation covering search, filtering and reporting
• Sample generated report produced on demand for an investigation
• Evidence that original records are preserved unmodified alongside processed views
• Integrity or immutability configuration for the raw record store

• Only aggregated dashboards exist and the underlying records cannot be retrieved
• Normalisation rewrites timestamps into local time and loses the original ordering
• Reduction pipeline drops fields permanently rather than filtering a preserved copy

Requires audit record time stamps to be produced from internal system clocks at an organization-defined granularity, and expressed in Coordinated Universal Time or with a fixed or recorded local offset so records from different systems can be correlated.

• Time synchronisation configuration and authoritative time source for in scope systems
• Defined time granularity requirement and evidence it is met
• Sample records from several systems showing consistent time reference
• Monitoring or drift report for clock synchronisation failures

• Some systems log in local time with no offset, breaking cross system correlation
• Time source unauthenticated or set per device, so drift goes undetected
• Granularity too coarse to order events that occur within the same second

Requires audit information and the audit logging tools themselves to be protected from unauthorized access, modification and deletion, and requires defined personnel to be alerted when such access, modification or deletion is detected.

• Access control configuration for the log store and logging tools
• Evidence of write once, immutable or off system storage of audit records
• Alerting configuration for unauthorized access to or modification of audit data
• Review showing administrators cannot delete records covering their own activity

• System administrators can clear the logs on the systems they administer
• Logs held only on the originating host, so compromise destroys the evidence
• No alert on log deletion or on the logging service being stopped

Requires an assessment, authorization and monitoring policy with supporting procedures to be developed, approved, disseminated to defined personnel, assigned to a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved assessment, authorization and monitoring policy with scope and approver
• Dissemination evidence to the defined personnel or roles
• Written designation of the official accountable for the assessment, authorization and monitoring policy and procedures
• Procedures covering assessment planning, authorization and ongoing monitoring
• Review record for the assessment, authorization and monitoring policy and procedures against the defined frequency and triggering events

• Policy covers initial authorization but is silent on ongoing monitoring
• Procedures never updated after the authorization process itself changed
• No named owner, so the policy drifts from actual practice

Requires selection of a suitably independent assessor, a documented assessment plan covering scope, procedures and environment, approval of that plan by the authorizing official before assessment begins, assessment of controls on a defined frequency, and production of an assessment report for defined recipients.

• Approved control assessment plan showing scope, procedures, environment and team
• Evidence of assessor selection and the basis for the required independence
• Signed approval of the plan by the authorizing official before fieldwork
• Assessment report with results per control and its distribution record

• Assessment performed by the team that operates the controls, with no independence
• Plan approved after testing had already started, or not at all
• Report produced but findings never routed into remediation tracking

Requires exchanges of information between this system and other systems to be approved and managed through a documented agreement, each agreement to record interface characteristics, security and privacy requirements, responsibilities and the impact level of the information exchanged, and agreements to be reviewed on a defined frequency.

• Register of information exchanges and the agreement type covering each
• Signed agreements recording interface characteristics and security responsibilities
• Impact level determination for the information passing over each exchange
• Review evidence against the defined frequency, including retired connections

• Interconnections created by projects and never registered or papered
• Agreements exist but do not state the impact level or the security responsibilities of each party
• No review cycle, so agreements outlive the connections they describe

Requires a plan of action and milestones to record planned remediation for weaknesses found in control assessments and for known vulnerabilities, and requires that plan to be updated on a defined frequency using findings from assessments, audits and continuous monitoring.

• Current plan of action and milestones with owners, dates and resource estimates
• Traceability from assessment and audit findings into plan entries
• Update history evidencing the defined update frequency
• Closure evidence for completed items and re-test results

• Plan holds only assessment findings while vulnerability scan results are tracked elsewhere
• Milestone dates slip repeatedly with no re-approval or risk acceptance
• Items closed on assertion without evidence that the weakness was actually fixed

Requires a senior official to be assigned as authorizing official for the system and for common controls, requires that official to accept inherited common controls and authorize operation before the system runs, and requires authorizations to be updated on a defined frequency.

• Written appointment of the authorizing official for the system and for common controls
• Signed authorization decision document with its effective and expiry dates
• Record of acceptance of inherited common controls
• Evidence of authorization update against the defined frequency or on significant change

• System operating past the expiry of its authorization with no renewal
• Common control inheritance assumed without the authorizing official ever accepting it
• Authorization signed by a delegate without documented authority to do so

Requires a system-level continuous monitoring strategy aligned to the organizational one, defining the metrics monitored, the frequencies for monitoring and for assessing control effectiveness, ongoing control assessment, correlation and analysis of the results, response actions, and reporting of security and privacy posture to defined personnel.

• Documented continuous monitoring strategy with metrics and frequencies
• Evidence of ongoing control assessments performed at the stated cadence
• Correlation and analysis output showing findings drawn from monitoring data
• Posture reports issued to the defined personnel and the actions they triggered

• Monitoring reduced to vulnerability scanning, with most controls never reassessed
• Metrics defined but never collected or reported
• Findings analysed in isolation rather than correlated across sources

Requires penetration testing to be conducted on organization-defined systems or components at an organization-defined frequency, so that control effectiveness is tested by simulated adversary activity rather than by inspection alone.

• Defined testing frequency and the systems or components in scope
• Rules of engagement and scope agreement for each test
• Penetration test report with findings, severity and evidence
• Remediation and re-test records for findings raised

• Scope narrowed to the external perimeter so internal paths are never tested
• Testing performed once at go live and not repeated at the defined frequency
• Findings reported but not tracked to closure or re-tested

Requires internal connections of organization-defined components to be authorized, each documented with its interface details, the security and privacy needs it carries and what information passes over it, terminated when defined conditions occur, and reviewed for continued need at a defined frequency.

• Register of authorized internal connections with documented characteristics
• Authorization records for each connection class or component type
• Termination conditions and evidence connections were closed when met
• Periodic review confirming each connection is still needed

• Internal connections treated as out of scope because they do not cross the boundary
• Register never updated as components were added, replaced or retired
• No defined termination conditions, so temporary connections become permanent

Requires a configuration management policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved configuration management policy with scope, approver and date
• Dissemination evidence to the defined recipients
• Designation of the official accountable for the policy
• Procedures covering baselines, change control and configuration monitoring
• Review record for the configuration management policy and procedures against the defined frequency and triggering events

• Policy predates the move to infrastructure as code and describes manual builds
• Change control procedure exists but no baseline procedure sits beside it
• Review cadence undefined, so the policy silently ages

Requires software and its documentation to be used within contract and copyright terms, use of quantity licensed software to be tracked so copying and distribution stay controlled, and peer to peer file sharing to be controlled and documented so it cannot be used to distribute copyrighted work.

• Software licence register reconciled to deployed installations
• Evidence of tracking for quantity licensed products
• Policy and technical control record covering peer to peer file sharing
• Attestation or audit result showing use within contract terms

• Licence counts tracked in finance records that never reconcile to actual installations
• Open source obligations ignored because only paid licences are tracked
• Peer to peer controls absent on developer workstations and build servers

Requires policies governing user installation of software to be established, enforced through organization-defined methods, and monitored for compliance on an organization-defined frequency.

• User software installation policy stating what users may and may not install
• Technical enforcement configuration such as application allow listing or removal of local administrator rights
• Compliance monitoring output at the defined frequency
• Exception records for users permitted to install, with justification

• Policy written but users retain local administrator rights, so nothing enforces it
• Enforcement applied to workstations while servers and cloud instances are unmanaged
• No monitoring, so unauthorized software is only found during incidents

Information Location. Identify and document the location of [organization-defined] and the specific system components on which the information is processed and stored; Identify and document the users who have access to the system and

• Documented location of the defined information, naming the specific system components that process and store it
• List of users with access to each component holding that information
• Data mapping or inventory documentation, including personally identifiable information where held
• Change records showing the location documentation was updated when components changed
• Evidence the documented location was verified against the live estate rather than asserted

• Primary store documented while backups, caches, log stores and analytics copies are not
• Inventory built once at accreditation and never reconciled after migration or scaling
• User access list maintained per application rather than per component, so component level access is unknown

Data Action Mapping. Develop and document a map of system data actions

• A documented map of system data actions covering collection, use, retention, disclosure and disposal
• Identification of which data actions involve personally identifiable information
• Evidence the map traces data actions across components and to external recipients, not only within one application
• Review and update record showing the map was refreshed when a data action changed
• Link from the map to the privacy risk assessment that consumed it

• Map describes application logic but omits the disclosure to third parties, which is the action of greatest privacy consequence
• Drawn once for a privacy impact assessment and never maintained as the system changes
• Data actions listed without the personally identifiable information elements involved, so the map cannot support privacy analysis

Signed Components. Prevent the installation of [organization-defined] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization

• Definition of the software and firmware components required to be signed
• List of certificates recognised and approved by the organisation for verifying signatures
• Configuration enforcing signature verification at install time, with the failure behaviour on an unsigned component
• Installation or change records showing verification occurred, and evidence of a rejected unsigned component
• Process for approving a new signing certificate and revoking one no longer trusted

• Verification enforced on the operating system while application packages, drivers and container images install unverified
• Trust store accumulates certificates with no approval or revocation process behind it
• Enforcement set to warn rather than block, so an unsigned component still installs

Requires a current baseline configuration of the system to be developed, documented and held under configuration control, and reviewed and updated on a defined frequency, when defined circumstances require it, and whenever components are installed or upgraded.

• Documented baseline configuration for each component type in the system
• Version control or configuration management repository showing baseline change history
• Review records at the defined frequency and after component installation or upgrade
• Comparison of a deployed instance against its baseline

• Baseline exists for servers but not for network devices, containers or cloud services
• Baseline document frozen at deployment while live systems drifted
• Baselines updated informally without passing through configuration control

Requires the types of change that fall under configuration control to be defined, proposed changes to be reviewed and approved or rejected with explicit consideration of security and privacy impact, decisions and implemented changes to be documented, change records to be retained for a defined period, and change activity to be monitored and reviewed by the responsible body.

• Documented definition of which change types are configuration controlled
• Change records showing security and privacy impact considered before approval
• Change advisory board or approver minutes recording decisions
• Retention evidence for change records against the defined period
• Post-implementation review or monitoring output for change activity

• Emergency changes bypass approval and are never retrospectively documented
• Impact analysis recorded as a tick box with no security reasoning behind it
• Infrastructure as code changes merge without passing through the same change control

Requires changes to the system to be analysed for their potential security and privacy impact before they are implemented, so that the consequences of a change are understood while it can still be stopped or modified.

• Impact analysis records attached to change requests before implementation
• Method or checklist used to assess security and privacy impact
• Examples of changes rejected or modified because of the analysis
• Evidence that the analysis considers privacy as well as security effects

• Analysis performed after deployment as part of a review rather than beforehand
• Privacy impact never considered, only availability and security
• Standard or pre-approved changes exempted without an initial impact assessment of the category

Requires physical and logical access restrictions on who may make changes to the system to be defined, documented, approved and actually enforced, so that only authorized personnel can alter the system.

• Documented and approved restrictions on who may change what
• Access control configuration for production change paths and deployment pipelines
• Records showing enforcement, for example rejected unauthorized deployments
• Review of privileged change access against the approved list

• Developers hold standing write access to production alongside the pipeline
• Restrictions documented but not enforced, so the pipeline can be bypassed manually
• Physical access to equipment rooms not treated as a change path

Requires configuration settings for system components to be established and documented at the most restrictive mode consistent with operations using defined secure configuration baselines, implemented in practice, with any deviation identified, documented and approved on defined operational grounds, and changes to settings monitored and controlled.

• Documented configuration settings or hardening standard per component type, citing the source benchmark
• Configuration compliance scan results against those settings
• Approved deviation register with the operational justification for each
• Monitoring evidence showing setting changes are detected and reviewed

• Benchmark adopted but never tailored, so most settings are silently exempted in practice
• Deviations applied locally by engineers with no approval record
• Compliance measured once at build with no drift detection afterwards

Requires the system to be configured to provide only the capabilities essential to its mission, and requires organization-defined functions, ports, protocols, software and services to be prohibited or restricted so that unnecessary attack surface is removed.

• Documented list of mission essential capabilities for the system
• Defined list of prohibited or restricted functions, ports, protocols, software and services
• Port and service scan results reconciled to the approved list
• Evidence of removal or disabling of unnecessary components

• Default services left running because nothing verified whether they were needed
• Prohibited list defined for workstations only and not for servers or appliances
• Scan results show unapproved listening services that nobody reconciles

Requires an accurate inventory of system components that covers every component, avoids duplicate or cross system accounting, is held at the granularity needed for tracking and reporting, carries the information the organization has defined for accountability, and is reviewed and updated on a defined frequency.

• Component inventory with the defined accountability fields populated
• Reconciliation of the inventory against a discovery scan or cloud asset listing
• Defined review frequency and evidence of review at that cadence
• Rules preventing duplicate accounting across system boundaries

• Cloud and container assets absent because inventory is built from a fixed asset register
• Ownership field blank, so no one is accountable for individual components
• Inventory reviewed annually while the estate changes weekly

Requires a configuration management plan for the system that sets out roles, responsibilities and processes, establishes how configuration items are identified and managed across the development life cycle, names the configuration items placed under management, is reviewed and approved by defined personnel, and is itself protected from unauthorized disclosure and modification.

• Approved configuration management plan with roles, processes and approval signatures
• Configuration item register showing what is under configuration management
• Evidence of the identification process applied across the development life cycle
• Storage and permission settings that keep the configuration management plan from unauthorized change

• Plan describes a process that the delivery teams do not follow
• Configuration items never formally identified, so the plan has no subject
• Plan stored on an open share where anyone can modify it

Requires a contingency planning policy and supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved contingency planning policy with scope, approver and date
• Evidence the contingency planning policy reached the personnel or roles it defines
• Written designation of the official accountable for the contingency planning policy and procedures
• Procedures supporting plan development, testing and activation
• Review record for the contingency planning policy and procedures against the defined frequency and triggering events

• Policy covers disaster recovery of infrastructure but not business function continuity
• Review only after an incident rather than at a defined cadence
• Policy silent on services delivered by third parties

Requires the system to be recoverable and reconstitutable to a known state within an organization-defined period consistent with its recovery time and recovery point objectives after disruption, compromise or failure.

• Documented recovery time and recovery point objectives for the system
• Recovery procedures describing return to a known and secure state
• Recovery test results showing objectives met within the defined period
• Validation that controls are restored, not only functionality

• Objectives stated by the business but never tested against actual recovery times
• Recovery restores service while security controls remain disabled from the recovery process
• Reconstitution after compromise not covered, only recovery after outage

Alternate Communications Protocols. Provide the capability to employ [organization-defined] in support of maintaining continuity of operations

• The defined alternative communications protocols identified for continuity use
• Design or configuration evidence showing the alternative protocol is available and reachable when the primary fails
• Test records demonstrating the alternative protocol carried real traffic during a contingency exercise
• Continuity plan section naming who switches to the alternative and on what trigger

• Alternative protocol depends on the same physical path or provider as the primary, so both fail together
• Listed in the plan but never exercised, so failure to switch is discovered during a real event
• No defined trigger, leaving the switch to an individual judgement call under pressure

Safe Mode. When [organization-defined] are detected, enter a safe mode of operation with [organization-defined]

• The defined conditions that trigger entry into safe mode
• The defined restrictions that apply while in safe mode, and what functions remain available
• Design and configuration evidence showing safe mode entry is automatic on the defined conditions
• Test record of safe mode entry and of the return to normal operation
• Operator procedure covering who authorises exit from safe mode and what must be verified first

• Safe mode restrictions undefined, so the mode is a label rather than a constrained state
• Entry conditions cover hardware failure but not the compromise conditions the control is aimed at
• No tested exit path, so recovery from safe mode is improvised

Alternative Security Mechanisms. Employ [organization-defined] for satisfying [organization-defined] when the primary means of implementing the security function is unavailable or compromised

• Identification of the primary security functions in scope and the alternative mechanism defined for each
• Evidence the alternative mechanism satisfies the same security requirement, not merely a related one
• Deployment or standby evidence showing the alternative is available before it is needed
• Test record of operating under the alternative mechanism
• Trigger and authority for switching when the primary is unavailable or compromised

• Alternative shares a dependency with the primary, such as the same directory or key infrastructure
• Alternative provides weaker assurance than the primary with no risk acceptance recorded
• Never exercised, so its capacity and performance under real load are unknown

Requires a contingency plan that identifies essential mission and business functions and their contingency requirements, sets recovery objectives, priorities and metrics, assigns roles and contacts, addresses operating through disruption and full restoration without weakening controls, is approved by defined personnel, distributed to defined recipients, coordinated with related plans, reviewed on a defined frequency and updated after change or testing.

• Approved contingency plan with recovery objectives, priorities and metrics
• Business impact analysis identifying essential functions and dependencies
• Distribution list and evidence the plan reached the defined recipients
• Review and update history including changes after tests or incidents
• Evidence of coordination with incident response and related organizational plans

• Plan lists systems but never identifies the business functions they support
• Contact details stale, naming people who left the organization
• Plan updated after tests but the revised version never redistributed

Requires contingency training for system users appropriate to their assigned roles, delivered within a defined period of taking on a contingency role, repeated when system changes require it and at a defined frequency, with training content reviewed and updated on a defined frequency and after defined events.

• Contingency training syllabus mapped to contingency roles
• Completion records showing training within the defined period of role assignment
• Refresher training evidence at the defined frequency
• Content revision history following exercises, incidents or system changes

• Only the recovery team trained while business function owners are not
• New role holders wait for the annual session rather than being trained on assignment
• Training content unchanged after an exercise exposed procedural failures

Requires the contingency plan to be tested at a defined frequency using defined test types to establish that the plan works and that people are ready to execute it, the test results to be reviewed, and corrective action to be initiated where the test shows it is needed.

• Test plan and scenario documentation for each exercise
• Test report with results, observations and participants
• Defined test types and frequency, and evidence they were met
• Corrective actions raised, tracked and closed following the test

• Tabletop exercise substituted for the technical failover test the plan requires
• Results recorded but corrective actions never tracked to closure
• Test scope avoids the components most likely to fail

Requires an alternate storage site to be established with the agreements needed to store and retrieve backup information, and requires that site to provide controls equivalent to those protecting the primary site.

• Agreement or contract covering the alternate storage site and retrieval rights
• Assessment showing site controls are equivalent to the primary site
• Evidence of separation from the primary site against the identified threats
• Retrieval test record proving backup information can be recovered from the site

• Alternate storage shares the same power, network or hazard zone as the primary site
• Equivalence assumed from a provider claim with no assessment
• Retrieval never tested, so the time to recover from that site is unknown

Requires an alternate processing site with the agreements needed to transfer and resume defined system operations for essential functions within a defined period when the primary site is unavailable, with equipment and supplies available or contracted for delivery in that period, and with controls at the alternate site equivalent to the primary.

• Agreement for the alternate processing site with the transfer and resumption terms
• Documented list of operations to be resumed and the required time period
• Evidence equipment and supplies are in place or contracted for timely delivery
• Assessment of control equivalence at the alternate site
• Failover test record demonstrating resumption within the defined period

• Contracted capacity is best effort and not guaranteed when a regional event hits every customer at once
• Alternate site inherits the same single points of failure as the primary
• Resumption time never measured against the requirement

Requires alternate telecommunications services, with the necessary agreements, to allow defined system operations for essential functions to resume within a defined period when primary telecommunications are unavailable at either the primary or the alternate site.

• Contracts for alternate telecommunications services with priority and restoration terms
• Documentation of the operations they must support and within what period
• Evidence of path and carrier diversity from the primary service
• Test or activation record demonstrating the alternate service works

• Second circuit purchased from a different reseller that uses the same physical path
• Alternate service covers the primary site only and not the alternate processing site
• Capacity of the alternate service insufficient to carry essential functions

Requires backups of user-level information, system-level information and system documentation including security and privacy documentation, each at an organization-defined frequency, and requires the confidentiality, integrity and availability of the backup information itself to be protected.

• Backup schedule and success reports covering user-level, system-level and documentation backups
• Encryption and access control configuration protecting backup data
• Restore test records proving backups are usable
• Defined backup frequencies and evidence they are met

• Documentation and configuration backed up nowhere, only application data
• Backups unencrypted or reachable with the same credentials as production, so ransomware takes both
• Backup success monitored while restore capability is never tested

Requires an identification and authentication policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved identification and authentication policy with scope, approver and date
• Evidence the identification and authentication policy reached the personnel or roles it defines
• Written designation of the official accountable for the identification and authentication policy and procedures
• Procedures covering identity proofing, authenticator issue and revocation
• Review record for the identification and authentication policy and procedures against the defined frequency and triggering events

• Policy predates multi-factor rollout and still describes password only authentication
• Non-organizational and machine identities not addressed by the policy
• No review cadence defined for the identification and authentication policy, so it silently ages

Adaptive Authentication. Require individuals accessing the system to employ [organization-defined] under specific [organization-defined]

• The defined circumstances or situations that trigger supplemental authentication
• The supplemental authentication techniques or mechanisms required in each circumstance
• Configuration of the risk engine or policy that evaluates the circumstance at authentication time
• Authentication logs showing supplemental authentication was demanded when a trigger condition was present
• Evidence of the fallback when the supplemental mechanism is unavailable

• Triggers defined in policy while the platform applies a vendor default risk policy that does not match them
• Fallback silently downgrades to single factor when the supplemental method fails
• No logging of the triggering condition, so the decision cannot be shown to have been risk based

Requires users to re-authenticate when organization-defined circumstances or situations occur, such as a change of role or privilege, use of a more sensitive function, or expiry of an authenticated session.

• Documented list of circumstances that require re-authentication
• Configuration evidence showing re-authentication enforced at those points
• Sample logs showing re-authentication events occurring
• Design note covering re-authentication for privileged and sensitive operations

• Circumstances never defined, so re-authentication happens only at session expiry
• Privilege elevation performed without re-proving identity
• Long lived tokens keep sessions alive past any re-authentication point

Requires users who need accounts for logical access to be identity proofed to the assurance level applicable under the relevant standards, requires identities to be resolved to a unique individual, and requires identity evidence to be collected, validated and verified.

• Documented identity proofing procedure and the assurance level applied
• Records of identity evidence collected, validated and verified per user population
• Evidence that each identity resolves to a unique individual with no shared records
• Distinct proofing treatment for remote onboarding and for contractors

• Contractors and third party staff onboarded on a manager assertion with no evidence check
• Assurance level never determined, so proofing rigour is arbitrary
• Duplicate identity records for the same person across systems

Identity Providers and Authorization Servers. Employ identity providers and authorization servers to manage user, device, and non-person entity (NPE) identities, attributes, and access rights supporting authentication and authorization decisions in accordance with [organization-defined] using

• Inventory of identity providers and authorisation servers in use, and the systems each serves
• The defined policy for managing user, device and non-person entity identities, attributes and access rights
• Trust configuration between relying parties and each provider, including permitted issuers and audiences
• Evidence that attributes and access rights asserted by the provider are the ones enforced at the relying party
• Records of provider and authorisation server configuration change and review

• Non-person entity identities such as workloads and service accounts managed outside the provider entirely
• Relying parties accepting tokens from any issuer in the trust store rather than a named provider
• Attribute release configured once and never reconciled with the access rights actually enforced

Requires organizational users to be uniquely identified and authenticated, and requires that unique identity to be carried through to the processes that act on their behalf, so that system activity is attributable to a specific person.

• Directory or identity store showing unique accounts per organizational user
• Authentication configuration including multi-factor where required
• Evidence that process and session activity carries the initiating user identity
• Register of any shared accounts with justification and compensating attribution

• Shared administrative accounts destroy attribution at exactly the highest privilege
• Automation runs under a generic identity that hides who initiated the action
• Legacy applications authenticate locally and outside the central identity store

Requires organization-defined devices or device types to be uniquely identified and authenticated before a local, remote or network connection is established, so that connectivity is granted to known devices rather than to anything that reaches the network.

• Defined list of devices or device types requiring authentication and the connection types covered
• Network access control or certificate based authentication configuration
• Certificate or credential issuance and revocation records for devices
• Logs showing unknown devices denied connection

• Device authentication applied to laptops while printers, cameras and operational technology connect freely
• Shared pre-shared key used across all devices, giving no unique identity
• Wired ports left open without any device authentication

Requires identifiers for individuals, groups, roles, services and devices to be assigned only on authorization from defined personnel, chosen to identify the right subject, assigned to that subject, and prevented from being reused for an organization-defined period.

• Authorization records preceding identifier assignment
• Naming standard covering individual, group, role, service and device identifiers
• Configuration or procedure preventing identifier reuse for the defined period
• Sample checks confirming no identifier was reissued inside that period

• Reuse period never defined, so a leaver username is reissued to a new starter
• Service and device identifiers assigned by engineers without any authorization step
• Naming conventions inconsistent across systems so the same person appears as several subjects

Requires authenticators to be managed end to end: identity verified before issue, initial content set, strength appropriate to use, administrative procedures for distribution, loss, compromise and revocation, default authenticators changed, minimum and maximum lifetimes with reuse conditions enforced, authenticators changed on a defined frequency by type, content protected, and protection requirements implemented by users and devices.

• Authenticator standard covering strength, lifetime and reuse conditions per authenticator type
• Procedures for issue, replacement of lost or compromised authenticators and revocation
• Evidence default credentials are changed before a component enters service
• Configuration enforcing the defined lifetimes and reuse restrictions
• Evidence of protected storage such as hashing, vaulting or hardware tokens

• Default credentials remain on appliances, embedded devices and management interfaces
• Service account secrets never rotated because nothing tracks where they are used
• Authenticators emailed or shared in chat during issue and reset

Requires feedback shown during authentication to be obscured so that an observer or an attacker cannot harvest authentication information from what the system displays or returns.

• Screenshots or configuration showing masked credential entry
• Error message specification showing failures do not reveal which factor was wrong
• Test evidence that responses do not disclose whether an account exists
• Coverage across web, mobile, console and recovery flows

• Error messages distinguish unknown user from wrong password and enable enumeration
• Credentials echoed in console or terminal sessions during administration
• Recovery and password reset flows leak whether an address is registered

Requires authentication to a cryptographic module to be implemented by mechanisms that satisfy the laws, directives, policies, regulations, standards and guidelines that apply to authentication for such modules.

• Inventory of cryptographic modules in use and their validation status
• Documented authentication requirements applicable to those modules
• Configuration showing role based authentication to the module is enforced
• Vendor certification or validation certificate references

• Cryptographic module operating in a non-validated mode
• Administrative access to key management platforms without the required authentication strength
• Applicable requirements never identified, so compliance cannot be demonstrated

Requires non-organizational users, and processes acting on their behalf, to be uniquely identified and authenticated so that external party activity on the system is attributable in the same way as internal activity.

• Identity register covering external users such as customers, partners and vendors
• Federation or external identity provider configuration and trust agreements
• Evidence of unique accounts rather than shared partner logins
• Access review evidence for external identities

• One shared login issued per partner organization, so individual actions cannot be attributed
• External accounts persist after the commercial relationship ends
• Federated trust accepted without agreeing the assurance level behind it

Service Identification and Authentication. Uniquely identify and authenticate [organization-defined] before establishing communications with devices, users, or other services or applications

• Definition of the system services and applications required to be identified and authenticated
• The mechanism binding an identity to each service, such as certificates, signed tokens or mutual TLS
• Configuration showing authentication occurs before communications are established, not after
• Inventory of service credentials with owner, issuance and rotation dates
• Logs of service to service authentication including failures

• Network location used as the identity, so anything on the segment is trusted implicitly
• Service credentials embedded in code or images with no rotation and no owner
• Authentication one way only, so the client verifies the server while the server accepts any caller

Requires an incident response policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved incident response policy with scope, approver and date
• Evidence the incident response policy reached the personnel or roles it defines
• Written designation of the official accountable for the incident response policy and procedures
• Procedures for detection, triage, containment, eradication, recovery and reporting
• Review record for the incident response policy and procedures against the defined frequency and triggering events

• Policy silent on privacy incidents and personal data breach obligations
• Procedures assume an on-premises estate and omit cloud and provider incidents
• Review only occurs after a major incident

Requires incident response training matched to assigned roles, delivered within a defined period of taking on an incident response role or gaining system access, repeated when system changes require it and at a defined frequency, with content reviewed and updated on a defined frequency and after defined events.

• Role based incident response training syllabus
• Completion records showing incident response training preceded or met the defined window after role assignment
• Refresher records at the defined frequency
• Content update history following exercises, incidents or system change

• Responders trained while system administrators who detect first are not
• Training delivered once at hire with no refresher cycle
• Content never updated after incidents exposed procedural gaps

Requires the incident response capability serving the system to be tested for effectiveness at an organization-defined frequency using the test types the organization has defined, so readiness is demonstrated rather than assumed.

• Defined test types and frequency for incident response testing
• Exercise scenario documents and participant lists
• Test reports with observations and identified weaknesses
• Corrective actions tracked to closure after each test

• Only tabletop exercises run, so technical containment steps are never proven
• Test scope excludes third party providers who hold part of the response
• Findings from exercises are not fed back into plans or training

Requires an incident handling capability covering preparation, detection and analysis, containment, eradication and recovery, consistent with the incident response plan, coordinated with contingency planning, improved by lessons learned that are fed back into procedures, training and testing, and applied with comparable rigour across the organization.

• Documented handling procedures covering each stage of the lifecycle
• Incident records showing the stages applied in practice
• Lessons learned reviews and evidence of resulting changes to procedures or training
• Evidence of coordination with contingency and recovery activities

• Containment and recovery handled ad hoc by whoever is available
• Lessons learned captured in a document that changes nothing downstream
• Handling rigour varies widely between teams and business units

Requires incidents to be tracked and documented from detection through resolution, so that a durable record exists of what happened, what was done and how it ended.

• Incident register or ticketing system holding all incidents
• Sample incident records showing timeline, actions taken and resolution
• Evidence of tracking through to closure with root cause where determined
• Retention arrangements for incident documentation

• Minor incidents resolved in chat and never recorded
• Records lack timelines, so response times cannot be measured
• Incidents closed without a root cause or resolution note

Requires personnel to report suspected incidents to the incident response capability within an organization-defined period, and requires incident information to be reported to the authorities the organization has identified.

• Defined internal reporting timeframe and the channels available to staff
• Evidence staff know how and when to report, such as awareness material
• List of authorities to be notified and the applicable timeframes
• Records of actual notifications made and their timing

• Reporting timeframe undefined, so escalation depends on individual judgement
• Regulatory notification obligations never mapped, so deadlines are discovered during an incident
• Reporting path exists but staff use informal channels that bypass it

Requires an incident response support resource that forms part of the incident response capability and gives system users advice and assistance on handling and reporting incidents.

• Documented support resource such as a help desk function or named responders
• Contact routes published to system users
• Records of assistance provided to users during incidents
• Integration evidence showing the support resource feeds the incident process

• Support resource exists but users do not know how to reach it
• Help desk takes reports without any handoff into incident response
• No coverage outside business hours

Requires an incident response plan that sets the roadmap and structure for the capability, fits it to the organization, defines reportable incidents and success metrics, defines the resources and management support needed, is approved by defined personnel, distributed to defined recipients, reviewed on a defined frequency, updated for change and lessons learned, and protected from unauthorized disclosure and modification.

• Approved incident response plan with roles, structure and reportable incident definitions
• Distribution record to the defined recipients
• Review and update history including changes after incidents or exercises
• Access controls protecting the plan from unauthorized disclosure or change
• Defined metrics for measuring incident response capability

• Plan defines severity levels but never defines what counts as a reportable incident
• Plan stored only on the system it is meant to help recover
• Updates made without redistribution, so responders hold an outdated copy

Information Spillage Response. Respond to information spills by: Assigning [organization-defined] with responsibility for responding to information spills; Identifying the specific information involved in the system contamination; Alerting [organization-defined] of the information spill using a

• Named personnel or roles assigned responsibility for responding to information spills
• Procedure for identifying the specific information involved and the components contaminated
• Alerting records showing the defined personnel were notified by a method not itself using the contaminated system
• Isolation, eradication and decontamination records for a real or exercised spill
• Post spill actions including access removal for personnel exposed and the additional defined actions

• Alert sent using the contaminated system or mailbox, spreading the spill further
• Contaminated system cleaned while backups, mail copies and export files keep the spilled information
• Personnel exposed to the information are never tracked, so exposure cannot be bounded afterwards

Requires a maintenance policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved maintenance policy with scope, approver and date
• Evidence the maintenance policy reached the personnel or roles it defines
• Written designation of the official accountable for the maintenance policy and procedures
• Procedures covering scheduled maintenance, tools, remote maintenance and personnel
• Review record for the maintenance policy and procedures against the defined frequency and triggering events

• Policy addresses hardware maintenance only and ignores remote vendor support sessions
• Cloud and managed service maintenance treated as out of scope with no substitute controls
• No review cadence defined for the maintenance policy, so it silently ages

Requires maintenance, repair and replacement to be scheduled, documented and reviewed against vendor and organizational requirements, all maintenance approved and monitored whether local or remote, removal of components off site explicitly approved by defined personnel, equipment sanitised of information before it leaves, components checked before return to service, and defined maintenance information recorded.

• Maintenance schedule and completed maintenance records per component
• Approval records for off site removal of systems or components
• Sanitisation records for equipment removed for maintenance or repair
• Verification records confirming controls were checked before return to service
• Defined maintenance record fields and evidence they are captured

• Failed drives returned to the vendor under warranty without sanitisation or destruction
• Vendor performed maintenance not recorded because it was arranged directly by operations
• No verification that security controls still function after maintenance

Requires the maintenance tools used on the system to be approved, controlled and monitored in use, and requires previously approved tools to be reviewed at an organization-defined frequency so the approved set stays current.

• Register of approved maintenance tools including diagnostic and remote support software
• Control evidence such as restricted issue, checkout records or managed installation
• Monitoring records of tool use during maintenance activity
• Review record for previously approved tools at the defined frequency

• Engineers bring personal utilities and portable media that were never approved
• Approved list created once and never reviewed as tooling changed
• Tool use unmonitored, so a maintenance tool becomes an unlogged administrative channel

Requires nonlocal maintenance and diagnostic activity to be approved and monitored, permitted only where consistent with policy and documented in the security plan, established with strong authentication, recorded, and with sessions and network connections terminated when the maintenance is finished.

• Approval records for each nonlocal maintenance arrangement
• Security plan section documenting permitted nonlocal maintenance tools and paths
• Authentication configuration for remote maintenance sessions
• Session records including start, end and connection termination evidence

• Vendor remote support tunnel left permanently open between engagements
• Sessions authenticated with a shared vendor credential
• No monitoring or recording of what the remote engineer actually did

Requires a process for authorizing maintenance personnel with a maintained list of authorized maintenance organizations and individuals, verification that unescorted maintainers hold the required access authorizations, and designation of competent authorized personnel to supervise maintenance by anyone who does not.

• Authorized maintenance personnel and organization list, kept current
• Verification records of access authorizations for unescorted maintainers
• Designation of supervising personnel and evidence of supervision during visits
• Escort logs for maintenance visits by unauthorized personnel

• Vendor engineers admitted on the strength of a company name rather than an individual authorization
• Escort assigned but lacking the technical competence to supervise the work
• Authorized list never pruned as vendor staff change

Timely Maintenance. Obtain maintenance support and/or spare parts for [organization-defined] within [organization-defined] of failure

• Defined list of system components requiring timely maintenance support or spare parts, with the time period for each
• Service provider contracts or service level agreements evidencing the committed response time
• Spare parts inventory and availability records for the components named
• Records of actual maintenance response times measured against the defined period
• Evidence the defined period was derived from availability requirements rather than from what the vendor offered

• Contract response time is for acknowledgement rather than restoration, so the committed period is not what the control needs
• Spares held for common components while the single sourced long lead item has none
• Components reaching end of support with no replacement plan, leaving the period unachievable

Field Maintenance. Restrict or prohibit field maintenance on [organization-defined] to [organization-defined]

• Definition of the systems and components on which field maintenance is restricted or prohibited
• The approved alternative, such as return to a depot or trusted facility, and the authority for any exception
• Maintenance records showing where maintenance was actually performed for the components in scope
• Approval records for any field maintenance permitted by exception, including the compensating measures applied
• Evidence maintenance personnel and their equipment were controlled at the field location

• Restriction stated in policy while operational pressure produces routine unapproved field repair
• Exceptions granted verbally with no record and no compensating measures
• Maintenance records do not record location, so compliance with the restriction cannot be tested

Requires a media protection policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved media protection policy with scope, approver and date
• Evidence the media protection policy reached the personnel or roles it defines
• Written designation of the official accountable for the media protection policy and procedures
• Procedures covering media access, marking, storage, transport and sanitisation
• Review record for the media protection policy and procedures against the defined frequency and triggering events

• Policy covers paper records but not removable digital media, or the reverse
• Sanitisation and disposal handled by facilities under no policy at all
• No review cadence defined for the media protection policy, so it silently ages

Requires access to organization-defined types of digital and non-digital media to be restricted to organization-defined personnel or roles, so that only those with a need can reach the media holding the information.

• Defined media types in scope and the personnel or roles permitted access
• Physical access controls on media stores such as locked cabinets or rooms
• Access records or issue logs for controlled media
• Review evidence that the permitted list is current

• Backup tapes and drives stored in areas open to all staff and cleaners
• Restrictions defined for digital media while paper records are unmanaged
• Access list never reviewed after team changes

Requires system media to be marked with the distribution limitations, handling caveats and any applicable security markings for the information it holds, with organization-defined media types exempt from marking only while they remain inside defined controlled areas.

• Marking standard mapping information classification to media markings
• Sample marked media covering each classification in use
• Documented exemptions and the controlled areas in which they apply
• Spot check results confirming marking practice in the field

• Exemption applied to media that regularly leaves the controlled area
• Markings applied at creation but lost when media is copied or reused
• Classification scheme exists but staff cannot tell which marking to apply

Requires organization-defined media types to be physically controlled and securely stored within organization-defined controlled areas, and requires that protection to continue until the media is destroyed or sanitised using approved equipment, techniques and procedures.

• Defined controlled areas and the media types stored in each
• Physical security evidence for the storage locations
• Inventory or custody records for stored media
• Destruction and sanitisation records using approved methods

• Media awaiting destruction accumulates in unsecured areas for months
• Custody records absent, so loss would not be detected
• Sanitisation performed with a quick format rather than an approved technique

Requires organization-defined media types to be protected and controlled by defined controls while in transit outside controlled areas, accountability for the media to be maintained throughout, transport activity to be documented, and transport to be carried out only by authorized personnel.

• Defined media types in scope for transport and the controls applied, such as encryption or tamper evident containers
• Chain of custody records for each transport movement
• List of personnel authorized to transport media
• Transport logs reconciled against dispatch and receipt confirmations

• Backup media couriered with a signature on collection but no custody record in between
• Encryption relied on for digital media while paper records travel unprotected
• Transport performed by whoever is going that way rather than by authorized personnel

Requires organization-defined media to be sanitised before disposal, before it leaves organizational control and before reuse, using defined techniques, with the mechanism chosen to match the sensitivity of the information the media held in strength and integrity.

• Sanitisation procedure specifying technique per media type and classification
• Certificates of destruction or sanitisation logs with serial numbers
• Verification records confirming sanitisation was effective
• Evidence covering media returned to lessors, vendors or cloud providers

• Technique chosen by convenience rather than matched to the information classification
• No verification step, so a failed wipe is indistinguishable from a successful one
• Solid state media treated with methods designed for magnetic disks

Requires the use of organization-defined media types on defined systems or components to be restricted or prohibited using defined controls, and specifically requires portable storage devices with no identifiable owner to be prohibited from use in organizational systems.

• Policy stating which media types are restricted or prohibited and on which systems
• Technical enforcement configuration such as port control or device allow listing
• Evidence that unowned portable storage is blocked
• Exception records with justification and compensating controls

• Policy prohibits removable media while no technical control prevents it
• Enforcement on laptops but not on servers, build machines or operational technology
• Ownership of approved devices never recorded, so the unowned device rule cannot be applied

Media Downgrading. Establish [organization-defined] that includes employing downgrading mechanisms with strength and integrity commensurate with the security category or classification of the information; Verify that the system media downgrading process is commensurate with the

• The defined media downgrading process, including the mechanisms used and their assessed strength
• Categorisation documentation establishing the security category or classification the downgrade must be commensurate with
• List of media requiring downgrading and the disposition of each
• Verification records showing the downgrading process was tested and the information is not recoverable
• Records of each downgrade performed, including operator, method and date

• Downgrading method chosen for convenience without assessing its strength against the classification
• Process verified once at introduction and never re-verified as media technology changes
• Downgraded media released with no record, so the chain of custody breaks at the point of greatest risk

The organization plans and conducts control assessments, system authorizations, ongoing monitoring, and connection authorization for system interconnections.

• Security assessment plans
• Security assessment reports
• System authorization decisions
• Interconnection security agreements
• Continuous monitoring metrics

• Assessments only at authorization, not ongoing
• Interconnections undocumented
• Monitoring outputs not actioned
• POA&M not updated from assessment findings

Security and privacy plans are developed and maintained, including rules of behavior, baseline tailoring, and central management of common controls.

• System security plan per system
• Privacy plan per system
• Rules of behavior with user acknowledgements
• Central management policy
• Architecture descriptions

• Plans static and not updated
• Rules of behavior not acknowledged
• Architecture descriptions vague
• Privacy plan absent

The organization maintains a program management function for security and privacy, including strategic plans, risk management strategy, workforce, and senior leadership engagement.

• Information security program plan
• Privacy program plan
• Risk management strategy
• Workforce skill assessments
• Senior leadership reporting cadence records

• Program plans not refreshed
• Workforce gaps unaddressed
• Privacy program understaffed
• Senior leadership briefings ad hoc

The organization conducts risk assessments, threat awareness activities, privacy risk assessments, vulnerability monitoring, and criticality analyses for systems.

• Risk assessment reports per system
• Vulnerability scan results
• Threat intelligence integration evidence
• Privacy risk assessments
• Criticality analyses

• Risk assessments stale
• Scans not authenticated where required
• Threat intelligence not actioned
• Criticality analyses absent

Security and privacy requirements are addressed in acquisition processes, including supplier evaluation, system development life cycle, and external system services.

• Acquisition policies with security clauses
• SDLC integration documentation
• Supplier risk assessments
• Development security testing results
• External service agreements with security terms

• Security requirements omitted from contracts
• SDLC security gates absent
• Supplier risk assessed only at onboarding
• External services without continuous oversight

The organization implements supply chain risk management including policy, plans, supplier reviews, provenance, tampering protections, and component authenticity.

• Supply chain risk management plans
• Supplier inventory and risk tiers
• Provenance and SBOM records
• Tamper-evident packaging procedures
• Counterfeit detection processes

• SBOM coverage limited
• Component authenticity not verified
• Suppliers not tiered by risk
• Disposal of components leaks data

The organization provides security and privacy literacy training, role-based training, and training feedback aligned with responsibilities and emerging threats.

• Annual literacy training records
• Role-based training curricula
• Phishing simulation results
• Training effectiveness metrics
• Records of training updates after incidents

• Training generic across roles
• Privileged user training absent
• Phishing results not feeding into training
• Effectiveness not measured

Configuration baselines are established, changes controlled, security impact analyses performed, and configurations monitored for unauthorized change.

• Approved baseline configurations per platform
• Change advisory board records
• Security impact analyses on changes
• Configuration monitoring tool outputs
• Software inventory with authorized versions

• Baselines not maintained for cloud
• Emergency changes bypass review
• Unauthorized software unaddressed
• Drift detection absent

The organization develops contingency plans, trains personnel, tests plans, provides alternate storage and processing sites, and ensures information system backup and recovery.

• Information system contingency plans
• Test reports per system
• Alternate site agreements
• Backup logs and restore test records
• Training completion logs

• Plans untested at functional level
• Backups not tested for restore
• Alternate sites not geographically diverse
• Cloud contingency reliance without verification

The organization establishes an incident response capability including planning, training, testing, handling, monitoring, reporting, and incident response assistance.

• Incident response plan and playbooks
• Tabletop and functional exercise records
• Incident reporting metrics
• SOC operating procedures
• Post-incident reports with corrective actions

• Playbooks generic and not scenario specific
• Reporting timelines not met
• Lessons learned not implemented
• Third-party incident coordination weak

Controlled maintenance is performed on systems, including timely maintenance, maintenance tools, nonlocal maintenance, and maintenance personnel.

• Maintenance schedule and logs
• Approval records for nonlocal maintenance
• Tool inventory with vetting records
• Escort procedures for maintenance personnel
• Sanitization records for media used in maintenance

• Nonlocal maintenance unmonitored
• Tools brought in without inspection
• Personnel not properly vetted
• Records incomplete

Media containing system information is protected through access controls, marking, storage, transport, sanitization, and use restrictions.

• Media handling policy
• Media inventory and tracking logs
• Sanitization records per NIST SP 800-88
• Transport records with chain of custody
• Restricted use logs (USB, removable media)

• Sanitization not verified
• Removable media uncontrolled
• Marking inconsistent
• Transport without encryption

Physical access to systems and facilities is controlled, environmental hazards mitigated, and visitors managed, with monitoring and emergency support.

• Access lists for facilities
• Badge and lock management records
• Environmental controls (HVAC, fire suppression) maintenance records
• Visitor logs
• Surveillance and monitoring records

• Access lists not reviewed
• Fire suppression not tested
• Visitor logs incomplete
• Co-location and cloud provider physical controls unverified

Personnel are screened, terminated and transferred under controlled procedures, with access agreements and sanctions for noncompliance.

• Position risk designations
• Background investigation records
• Access agreements with signatures
• Termination and transfer access removal logs
• Sanctions process documentation

• Position risk not designated
• Termination access removal slow
• Transfers retain old access
• Sanctions not consistently applied

Requires a physical and environmental protection policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved physical and environmental protection policy with scope, approver and date
• Evidence the physical and environmental protection policy reached the personnel or roles it defines
• Written designation of the official accountable for the physical and environmental protection policy and procedures
• Procedures covering access authorization, monitoring, visitors and environmental controls
• Review record for the physical and environmental protection policy and procedures against the defined frequency and triggering events

• Policy written for an owned data centre and never adapted to colocation or cloud hosting
• Facilities team operates the controls but was never given the policy
• No review cadence defined for the physical and environmental protection policy, so it silently ages

Requires the ability to cut power to the system or defined components in an emergency, with shutoff devices placed in defined locations so authorized personnel can reach them, and with the shutoff capability protected against unauthorized activation.

• Location documentation or floor plan showing emergency power shutoff devices
• Evidence of protective measures such as covers, keyed switches or restricted access
• Testing or inspection records for the shutoff capability
• Procedure identifying who is authorized to operate it and in what circumstances

• Shutoff exists but is unlabelled or blocked by stored equipment
• No protection against accidental or malicious activation
• Authorized personnel never briefed on when and how to use it

Requires an uninterruptible power supply able to support either an orderly system shutdown or a transition to longer term alternate power when the primary power source is lost.

• Uninterruptible power supply specification and the runtime it provides
• Documented choice between orderly shutdown and transition to alternate power
• Maintenance, battery replacement and load test records
• Evidence of automated orderly shutdown configuration where that option is used

• Battery runtime no longer matches the load after equipment was added
• Units never load tested, so actual runtime is unknown
• Supply protects servers while network and cooling equipment is unprotected

Requires automatic emergency lighting to be installed and maintained so that it switches on during a power outage or disruption, covering exits and the routes people use to evacuate the building.

• Emergency lighting coverage plan for exits and evacuation routes
• Test and inspection records at the required interval
• Maintenance records including battery and lamp replacement
• Evidence of automatic activation during a test or actual outage

• Lighting installed but never tested, so batteries have failed
• Coverage stops at corridors and omits equipment rooms occupied by staff
• Maintenance handled by a landlord with no evidence provided to the organization

Requires fire detection and suppression systems to be installed and maintained for the facility, supported by an energy source independent of the facility supply so they remain functional during a power failure.

• Fire detection and suppression system documentation and coverage plan
• Inspection, testing and maintenance certificates
• Evidence of the independent energy source supporting the systems
• Records of alarm testing and fire authority notification arrangements

• Suppression covers the main hall but not adjacent equipment or storage rooms
• Certificates lapsed and no maintenance contract is current
• Independent energy source assumed but never verified

Requires environmental levels such as temperature, humidity, pressure, radiation or other organization-defined parameters to be held within defined acceptable ranges in the facility housing the system, and monitored at an organization-defined frequency.

• Documented acceptable ranges for each environmental parameter in scope
• Environmental monitoring readings or system output at the defined frequency
• Alerting configuration for out of range conditions and the response taken
• Maintenance records for cooling and humidity control equipment

• Acceptable ranges never documented, so readings cannot be judged
• Monitoring exists but out of range alerts route nowhere
• Only temperature monitored while humidity and other parameters are ignored

Requires protection against water leakage damage through master shutoff or isolation valves that can be reached, are proven to work, and whose location is known to the personnel who would have to operate them.

• Documentation of shutoff or isolation valve locations serving the facility
• Inspection or test records confirming valves operate
• Evidence key personnel are identified and know the valve locations
• Water detection sensor placement and alerting configuration where used

• Valve locations known only to a building contractor who is not on call
• Valves seized through lack of exercise and never inspected
• No water detection under raised floors or near cooling equipment

Delivery and Removal. Authorize and control [organization-defined] entering and exiting the facility; and Maintain records of the system components

• Definition of the system components subject to delivery and removal authorisation
• Authorisation records for components entering and exiting the facility, showing who approved each movement
• Register of items entering and exiting, reconcilable against the component inventory
• Evidence of the control point where the authorisation is checked, such as a loading dock procedure
• Reconciliation between removal records and asset disposal or transfer records

• Deliveries controlled while removals are not, which is the direction that matters for data loss
• Register kept by facilities and never reconciled with the asset inventory, so discrepancies are invisible
• Staff carrying equipment out through main entrances entirely outside the dock procedure

Requires the alternate work sites permitted for employees to be identified and documented, organization-defined controls to be applied at those sites, the effectiveness of those controls to be assessed, and a means to be provided for employees there to contact information security and privacy personnel about incidents.

• Documented list of permitted alternate work site types and the controls required at each
• Assessment records evaluating control effectiveness at alternate sites
• Published contact route for security and privacy incidents from remote locations
• Employee acknowledgement of alternate work site requirements

• Home working permitted in practice with no documented control expectations
• Controls specified but effectiveness never assessed in any form
• Incident contact routes assume the corporate network is reachable

Location of System Components. Position system components within the facility to minimize potential damage from [organization-defined] and to minimize the opportunity for unauthorized access

• The defined physical and environmental hazards that positioning is intended to mitigate
• Floor plans or location documentation showing where system components sit relative to those hazards
• Rationale linking each placement decision to the hazard it mitigates and to unauthorised access opportunity
• Records of placement review when the facility or the hazard assessment changed
• Evidence that access opportunity was considered, such as distance from public areas and sightlines to screens

• Placement driven by available space and cabling, with the hazard rationale written afterwards
• Water and mechanical plant hazards overlooked because the assessment concentrated on intrusion
• Layout documentation not updated after equipment moves, so the assessed position is not the actual one

Information Leakage. Protect the system from information leakage due to electromagnetic signals emanations

• Identification of the systems and areas requiring protection from electromagnetic signal emanations
• The protective measures applied, such as shielding, filtering, zoning or separation distances
• Emanation test records for the protected systems or facility
• Confirmation that the protection level matches the classification of the information processed
• Maintenance evidence that shielding integrity is preserved after cabling and layout changes

• Shielding installed at build and then breached by later cable penetrations with no reseal
• No test records, so protection is asserted from design intent rather than measurement
• Protection scoped to the processing equipment while peripherals and cabling carrying the same signal are excluded

Requires a list of individuals authorized to enter the facility housing the system to be developed, approved and maintained, access credentials to be issued, the list to be reviewed at a defined frequency, and individuals to be removed from it once access is no longer required.

• Approved facility access list with approval evidence
• Credential issue records tied to individuals on that list
• Review records at the defined frequency with removals actioned
• Reconciliation between the access list and the leaver process

• Leavers keep working badges because access removal is not part of offboarding
• List reviewed but exceptions never removed from the badge system
• Contractor and vendor access granted outside the approved list

Asset Monitoring and Tracking. Employ [organization-defined] to track and monitor the location and movement of [organization-defined] within [organization-defined]

• The defined assets requiring location tracking and the defined areas within which they are tracked
• The asset location technology employed and its coverage across those areas
• Tracking and monitoring records showing asset location and movement over the period
• Alerting evidence when an asset left a defined area or stopped reporting
• Handling rules for the location data itself where it can reveal individual movement

• Tracking technology deployed with no alert on absence, so a missing asset is discovered at the next stocktake
• Defined areas never specified, leaving no boundary that movement can be assessed against
• Location data retained and accessed with no privacy consideration despite tracking staff by proxy

Electromagnetic Pulse Protection. Employ [organization-defined] against electromagnetic pulse damage for [organization-defined]

• Definition of the systems or components requiring electromagnetic pulse protection
• The protective measures employed, such as surge arrest, shielded enclosures or filtered power and signal entry
• List of locations where the protective measures are implemented
• Design or test documentation supporting the adequacy of the measures for the assessed threat
• Inspection records confirming bonding, grounding and enclosure integrity are maintained

• Power entry protected while signal and network penetrations are unprotected
• Measures installed with no inspection cycle, so degraded bonding goes unnoticed
• Protection scoped to the primary site with the failover site unprotected against the same event

Component Marking. Mark [organization-defined] indicating the impact level or classification level of the information permitted to be processed, stored, or transmitted by the hardware component

• The defined hardware components required to carry a marking, and the marking scheme used
• Information types held and the impact or classification level assigned to each
• Component inventory cross referenced to the marking actually applied to each item
• Physical inspection record or photographs showing markings in place and legible
• Procedure for re-marking when a component's permitted processing level changes

• Marking applied at issue and never updated when a component is repurposed to a higher or lower level
• Removable media and peripherals marked while the hosts they attach to are not
• Marking scheme uses internal codes that a handler cannot interpret without a lookup they do not have

Facility Location. Plan the location or site of the facility where the system resides considering physical and environmental hazards; and For existing facilities, consider the physical and environmental hazards in the organizational risk management

• Site planning documentation showing physical and environmental hazards considered in the location decision
• The hazard assessment for the chosen site, covering flood, seismic, fire, civil disturbance and adjacent land use
• For existing facilities, the entry in the organisational risk management programme recording the site hazards
• Mitigation measures adopted where the site hazard could not be avoided
• Review record showing site hazards were reconsidered when the hazard profile changed

• Site selected on cost and connectivity with the hazard assessment produced after the lease was signed
• Existing facilities never assessed at all because the control is read as applying only to new build
• Primary and alternate sites share a hazard zone, such as the same flood plain or substation

Requires physical access authorizations to be enforced at defined entry and exit points by verifying authorization before entry and controlling ingress and egress with defined mechanisms or guards, physical access audit logs to be kept, publicly accessible areas to be controlled, visitors to be escorted and their activity controlled in defined circumstances, keys and combinations to be secured with inventories and changes made on defined events and frequencies.

• Entry and exit point register showing the enforcement mechanism at each
• Physical access audit logs from badge or guard systems
• Visitor escort procedure and completed visitor logs
• Key and combination inventory with reissue records after defined events
• Controls applied to publicly accessible areas within the facility

• Tailgating unaddressed, so an authorization check happens for only the first person through
• Combinations unchanged after staff with knowledge of them departed
• Access logs collected by a landlord and never obtained or reviewed by the organization

Requires physical access to organization-defined system distribution and transmission lines inside organizational facilities to be controlled using defined security controls, so cabling cannot be tapped, cut or interfered with.

• Documentation of in scope distribution and transmission lines and their routes
• Evidence of protective measures such as locked risers, conduit or sealed trays
• Access records for communications rooms and cable pathways
• Inspection records for cabling infrastructure

• Communications risers shared with the building and accessible to other tenants
• Patch panels in open office areas with no physical protection
• Cabling protected in the data hall while inter-building runs are unprotected

Requires physical access to output from organization-defined output devices to be controlled so that unauthorized individuals cannot obtain printed, displayed or otherwise emitted information.

• Register of output devices in scope and the controls applied to each
• Configuration evidence such as secure print release requiring the user at the device
• Placement records or screen privacy measures for displays in shared areas
• Clear desk and output collection checks

• Printers in shared corridors output sensitive documents that sit uncollected
• Screens visible from public areas or through windows
• Secure print available but not enforced as the default

Requires physical access to the facility to be monitored so that physical security incidents are detected and responded to, physical access logs to be reviewed at a defined frequency and on defined events, and review and investigation results to be coordinated with the incident response capability.

• Monitoring arrangements such as alarms, surveillance or guard patrols
• Physical access log review records at the defined frequency
• Records of event driven reviews following an incident or alarm
• Evidence of handover of physical findings into the incident response process

• Surveillance recorded but never reviewed unless something is already known to be wrong
• Physical incidents handled by facilities and never reach the security incident process
• Review frequency undefined, so reviews happen only on request

Requires visitor access records for the facility to be kept for an organization-defined retention period, reviewed at a defined frequency, and any anomalies in those records reported to organization-defined personnel.

• Visitor records covering identity, host, purpose, and entry and exit times
• Defined retention period and evidence records are kept for it
• Review records at the defined frequency
• Reports of anomalies raised to the defined personnel and their resolution

• Visitor book records arrival but never departure, so presence cannot be established
• Records kept but never reviewed, so repeated unexplained visits go unnoticed
• Retention shorter than the period needed to support an investigation

Requires power equipment and power cabling serving the system to be protected against damage and destruction, whether accidental, environmental or deliberate.

• Documentation of power equipment and cabling supporting the system
• Evidence of physical protection such as restricted plant rooms and protected cable routes
• Inspection and maintenance records for power infrastructure
• Assessment of single points of failure in the power path

• Distribution boards in areas accessible to all staff and contractors
• Power cabling shares an unprotected route with a high traffic corridor
• Protection considered for the data hall while upstream supply equipment is ignored

Requires a planning policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved planning policy with scope, approver and date
• Evidence the planning policy reached the personnel or roles it defines
• Written designation of the official accountable for the planning policy and procedures
• Procedures covering security plan development, review and maintenance
• Review record for the planning policy and procedures against the defined frequency and triggering events

• Policy exists but no procedure describes how security plans are maintained between authorizations
• Planning treated as a one off project activity rather than an ongoing obligation
• No review cadence defined for the planning policy, so it silently ages

Requires a control baseline to be selected for the system, so that the starting set of controls is chosen deliberately against the system's categorization rather than assembled ad hoc.

• Documented baseline selection decision and the categorization it follows from
• Security plan section recording the selected baseline
• Approval evidence for the selection
• Traceability from the baseline to the controls implemented

• Baseline never formally selected, so control scope is inferred after the fact
• Selection inconsistent with the recorded security categorization
• Selection made once and not revisited when the categorization changed

Requires the selected control baseline to be tailored by applying documented tailoring actions such as scoping, compensating control selection and parameter assignment, so the baseline reflects the actual system and risk.

• Documented tailoring actions with the rationale for each
• Record of organization-defined parameter values assigned during tailoring
• Approval of the tailored baseline by the responsible authority
• Traceability from tailoring decisions into the security plan

• Controls removed during tailoring with no documented rationale or approval
• Parameter values left unset, so several controls have no measurable target
• Tailoring performed once and never reconciled with later system changes

Requires system security and privacy plans that align to the enterprise architecture, define the system components and operational context, name role holders, identify information types and the security categorization with rationale, state threats, requirements and the controls selected including tailoring, and requires those plans to be approved, distributed, reviewed on a defined frequency, updated for change and findings, and protected from unauthorized disclosure and modification.

• Approved system security and privacy plan covering each required element
• Approval signature by the authorizing official or delegate
• Record showing the security and privacy plan was issued to its defined recipients
• Review and update history following change, assessment or monitoring findings
• Access controls preventing unauthorized disclosure or modification of the system security and privacy plan

• Plan describes the system as designed rather than as it now runs
• Control implementation statements copied between systems without tailoring
• Plan updated at reauthorization only, so it is stale for most of its life

Requires rules of behaviour describing user responsibilities and expected conduct for system, security and privacy matters to be established and given to individuals needing access, documented acknowledgement to be obtained before access is authorized, the rules to be reviewed and updated at a defined frequency, and prior acknowledgers to re-acknowledge updated rules.

• Current rules of behaviour document with version and approval date
• Signed or recorded acknowledgements dated before access was granted
• Review and update history at the defined frequency
• Re-acknowledgement records following an update

• Access granted first and acknowledgement chased afterwards
• Rules updated without any re-acknowledgement, so users agreed to a superseded version
• Contractors and privileged third parties never receive the rules

Concept of Operations. Develop a Concept of Operations (CONOPS) for the system describing how the organization intends to operate the system from the perspective of information security and privacy; and Review and update the

• The Concept of Operations document describing how the system is intended to be operated from a security and privacy perspective
• Evidence the CONOPS covers operating modes, operator roles and the security assumptions behind them
• Review and update records against the defined frequency
• Traceability from the CONOPS to the system security plan and privacy plan, showing they agree
• Approval of the CONOPS by the accountable system owner

• CONOPS written as a functional description with security and privacy operation absent, which is the specific angle the control requires
• Never updated after major change, so it describes a system that no longer exists
• Contradicts the system security plan on operating assumptions, and neither document is reconciled

Requires security and privacy architectures that set out how confidentiality, integrity and availability will be protected, how personal information processing will be handled to reduce privacy risk to individuals, how the architectures fit the wider enterprise architecture, and what is assumed about or depended on from external systems and services, reviewed and updated at a defined frequency and reflected in acquisition and planning.

• Security and privacy architecture documents covering each required element
• Documented assumptions about and dependencies on external systems and services
• Review and update records at the defined frequency
• Evidence the architecture informs acquisition decisions and the security plan

• Architecture describes security but treats privacy as an afterthought
• External dependencies undocumented, so inherited risk is invisible
• Architecture diverges from what was built and is never reconciled

Central Management. Centrally manage [organization-defined]

• The defined list of controls and control enhancements designated for central management
• For each, identification of the organisational entity that manages it centrally and the mechanism used
• Evidence that the centrally managed implementation actually applies to the systems claiming inheritance
• Records showing system owners were informed of what they inherit and what remains their responsibility
• Change and review records for the centrally managed implementations

• Systems claim inheritance of a central control that does not in fact cover their platform or region
• Central management asserted with no named owner, so no one maintains the implementation
• Boundary between central and system responsibility undocumented, leaving parts of the control unimplemented by both

Information Security Program Plan. Develop and disseminate an organization-wide information security program plan that: Provides an overview of the requirements for the security program and a description of the security program management controls and

• The organisation-wide information security program plan, showing the programme overview and the requirements it covers
• The section describing the program management controls and common controls in place or planned
• Identification of the roles, responsibilities, management commitment and compliance approach in the plan
• Approval by a senior official with the authority and resources named
• Dissemination evidence and the review and update records against the defined frequency and after significant change

• Plan covers system level controls while the program management and common controls it exists to document are thin
• Common controls listed without naming what inherits them, so inheritance cannot be verified
• Approved once at accreditation and not refreshed after reorganisation changed the roles it names

Authorization Process. Manage the security and privacy state of organizational systems and the environments in which those systems operate through authorization processes; Designate individuals to fulfill specific roles and responsibilities within the organizational risk

• The documented authorisation process covering how the security and privacy state of systems is managed
• Designations of individuals to the specific risk management roles, such as authorising official and system owner
• Current authorisation decisions for organisational systems, with dates and conditions
• Evidence that authorisations are tracked and reported, including those expired or operating under conditions
• Integration of the authorisation process with the continuous monitoring output that should inform it

• Authorisations issued and then never revisited, so the recorded state predates significant change
• Role designations vacant or held by someone who has left, leaving decisions unmade
• Authorisation decided from a point in time assessment with continuous monitoring findings never fed back into it

Mission and Business Process Definition. Define organizational mission and business processes with consideration for information security and privacy and the resulting risk to organizational operations, organizational assets, individuals, other organizations, and the Nation; and

• Documented mission and business processes, with the security and privacy considerations recorded for each
• The protection needs determined for each process, traceable to a risk assessment
• Evidence of the information protection and personally identifiable information processing needs feeding system requirements
• Revision records showing processes were revised when protection needs could not be met
• Sign off by the mission or business process owner rather than by security alone

• Protection needs derived from system architecture rather than from the business process the system serves
• Process never revised when the needs proved unachievable, so the gap is carried as permanent risk
• Personally identifiable information processing needs omitted, leaving privacy requirements unstated

Insider Threat Program. Implement an insider threat program that includes a cross-discipline insider threat incident handling team

• The insider threat programme charter, its scope and its authority
• Membership of the cross discipline incident handling team, showing security, legal, human resources and management representation
• Procedures for referral, triage and handling of a potential insider concern
• Records of cases handled, with the disciplines actually engaged in each
• Evidence of the legal and privacy safeguards governing what the programme may collect and access

• Team exists on paper as a security function only, with no human resources or legal participation
• No referral route from managers and colleagues, so the programme sees only what monitoring tools surface
• Data collection safeguards undefined, exposing the programme itself as a privacy risk

Security and Privacy Workforce. Establish a security and privacy workforce development and improvement program

• The security and privacy workforce development and improvement programme documentation
• Definition of security and privacy roles and the competencies required for each
• Assessment of current workforce competence against those role requirements, showing the gap
• Development activity records such as training, certification and rotation tied to named roles
• Measures of programme effect, such as gap closure or role fill rates, reviewed over time

• Programme equated with annual awareness training, which addresses all staff rather than the security and privacy workforce
• Role competencies never defined, so no gap can be measured and no development is targeted
• Privacy workforce omitted entirely while security roles are well covered

Testing, Training, and Monitoring. Implement a process for ensuring that organizational plans for conducting security and privacy testing, training, and monitoring activities associated with organizational systems: Are developed and maintained; and Continue to be

• Organisational plans for security and privacy testing, training and monitoring activities
• The process ensuring those plans are developed, maintained and executed as written
• Evidence the plans continue to be executed, such as completion records against the planned schedule
• Review record confirming the plans remain consistent with the organisational risk management strategy and priorities
• Records of adjustment where risk priorities changed and the plans were revised to match

• Plans developed and then executed only in part, with no tracking that would surface the shortfall
• Testing, training and monitoring planned in separate silos with no consistency check across them
• Plans never re-tested against the risk management strategy, so activity continues on stale priorities

Security and Privacy Groups and Associations. Establish and institutionalize contact with selected groups and associations within the security and privacy communities: To facilitate ongoing security and privacy education and training for organizational personnel; To

• The selected security and privacy groups and associations, and the rationale for selecting them
• Records of contact or membership, such as membership confirmations and meeting attendance
• Evidence the contact produced ongoing education for personnel, for example briefings circulated internally
• Evidence of currency maintained on recommended practices, techniques and technologies through those contacts
• Records of security and privacy information shared with the groups where appropriate

• Membership held by one individual with nothing flowing back to the wider organisation
• Contacts named in the plan with no evidence of any interaction during the period
• Information sharing one way only, receiving without any review of what may be shared out

Threat Awareness Program. Implement a threat awareness program that includes a cross-organization information-sharing capability for threat intelligence

• The threat awareness programme documentation, including its scope and intended audience
• The cross organisation information sharing capability used for threat intelligence, and the partners it connects
• Records of threat intelligence received and disseminated during the period
• Evidence threat intelligence changed something, such as a control adjustment or a hunt initiated
• Handling rules governing the sensitivity and permitted onward sharing of received intelligence

• Feeds subscribed to and ingested with no analysis, so intelligence never reaches a decision
• Sharing capability receives only, contributing nothing back to the community the control envisages
• Traffic light or equivalent handling markings ignored, risking the sharing relationship

Protecting Controlled Unclassified Information on External Systems. Establish policy and procedures to ensure that requirements for the protection of controlled unclassified information that is processed, stored or transmitted on external systems, are implemented in

• Policy and procedures for protecting controlled unclassified information processed, stored or transmitted on external systems
• Identification of the external systems that handle controlled unclassified information
• Agreements or contract clauses imposing the protection requirements on those external systems
• Evidence the requirements are implemented, such as assessment results or attestations from the external party
• Review and update records for the policy and procedures against the defined frequency

• Requirements imposed on prime contractors with nothing flowing down to subcontractors handling the same information
• External systems inventory incomplete, missing collaboration and file transfer services adopted by teams
• Attestation accepted at onboarding with no ongoing verification that protection continues

Privacy Program Plan. Develop and disseminate an organization-wide privacy program plan that provides an overview of the agency's privacy program, and: Includes a description of the structure of the privacy program and the resources

• The organisation-wide privacy program plan, with the programme structure and the resources dedicated to it
• The strategic goals and objectives of the privacy programme and how they will be met
• Identification of the privacy controls in place or planned, and the roles and responsibilities behind them
• Approval by a senior official with authority and resources, and evidence of dissemination
• Review and update records against the defined frequency and following privacy incidents or legal change

• Plan lists privacy obligations without naming the resources committed, which is the specific content the control requires
• Privacy folded into the security program plan rather than maintained as its own plan
• Not updated after a change in privacy law that altered the obligations it describes

Privacy Program Leadership Role. Appoint a senior agency official for privacy with the authority, mission, accountability, and resources to coordinate, develop, and implement, applicable privacy requirements and manage privacy risks through the organization-wide privacy

• Appointment record for the senior agency official for privacy, and their position description
• Documentation of the authority, mission, accountability and resources assigned to the role
• Evidence the official coordinates and implements privacy requirements, such as signed privacy impact assessments and notices
• Reporting line showing the official's access to senior leadership
• Records of privacy risk decisions made or escalated by the official

• Role assigned as an additional duty with no resources, so authority exists on paper only
• Official appointed but not involved in the privacy impact assessments and notices the role should own
• No reporting line to leadership, so privacy risk stops below the decision makers

Information Security Program Leadership Role. Appoint a senior agency information security officer with the mission and resources to coordinate, develop, implement, and maintain an organization-wide information security program

• Appointment record for the senior agency information security officer, naming the individual and the date
• Documentation of the mission and resources assigned to the role, including staffing and budget
• Position description or charter setting out the authority to coordinate, develop, implement and maintain the organisation-wide information security programme
• Evidence the officer exercises the role, such as approval of the information security program plan and of risk decisions
• Reporting line showing the officer's access to the head of the organisation

• Role held as a secondary duty by an information technology manager, so it lacks the independence and authority the control assumes
• Appointed with a title but no resources, leaving the programme unimplementable
• Officer not involved in the security programme artefacts they are accountable for, so accountability exists only on the organisation chart

Dissemination of Privacy Program Information. Maintain a central resource webpage on the organization's principal public website that serves as a central source of information about the organization's privacy program and that: Ensures that the

• The central privacy resource webpage on the organisation's principal public website, with its URL
• Evidence the page carries the required privacy programme information, including policies, reports and notices
• Confirmation the public can access the material without registration or barriers
• Review record showing the page content is current and links resolve
• Assignment of responsibility for maintaining the page

• Page exists but links to superseded documents, so the public sees a stale privacy position
• Privacy information scattered across several pages with no central resource, which is what the control asks for
• No owner assigned, so the page ages between audits

Accounting of Disclosures. Develop and maintain an accurate accounting of disclosures of personally identifiable information, including: Date, nature, and purpose of each disclosure; and Name and address, or other contact information of the individual

• The accounting of disclosures record showing date, nature and purpose of each disclosure
• Name and address or other contact information of the person or organisation the information went to
• Evidence the accounting is retained for the required period
• The process by which disclosures are captured into the accounting at the time they occur
• Evidence the accounting can be produced to an individual on request

• Only formal written disclosures captured while routine system to system transfers are not
• Accounting reconstructed from logs at request time rather than maintained, so it is incomplete
• Purpose recorded as a generic category, which does not meet the nature and purpose requirement

Personally Identifiable Information Quality Management. Develop and document organization-wide policies and procedures for: Reviewing for the accuracy, relevance, timeliness, and completeness of personally identifiable information across the information life cycle; Correcting or deleting inaccurate

• Organisation-wide policies and procedures for reviewing personally identifiable information for accuracy, relevance, timeliness and completeness
• Procedures for correcting or deleting inaccurate or outdated personally identifiable information
• Records of quality reviews performed across the information life cycle
• Sample notices of correction or deletion issued to recipients who received the flawed information
• Monitoring records showing quality management practices are themselves reviewed

• Correction applied in the master record while downstream copies and prior recipients keep the inaccurate version
• Quality checked at collection only, not across the life cycle as the control requires
• No disseminated correction notice, so third parties continue acting on wrong information

Data Governance Body. Establish a Data Governance Body consisting of [organization-defined] with [organization-defined]

• The document establishing the Data Governance Body and its charter of operations
• Membership showing the defined roles are filled, with their authority
• Minutes and decision records from body meetings during the period
• Records of requests to review data and the outcomes decided
• The policies, procedures and standards the body issued or approved

• Body chartered but not convened, so no decisions exist to evidence it
• Membership lacks the legal and privacy roles required to decide the questions put to it
• Decisions taken with no record, leaving governance unauditable

Data Integrity Board. Establish a Data Integrity Board to: Review proposals to conduct or participate in a matching program; and Conduct an annual review of all matching programs in which the agency has participated

• Document establishing the Data Integrity Board, its charter and its membership
• Records of the Board's review of proposals to conduct or participate in a matching program
• The annual review of all matching programs the organisation participated in, with its findings
• Computer matching agreements and notices considered by the Board
• Evidence of Board decisions where a proposal was rejected or conditioned

• Board reviews new proposals but skips the annual review of existing matching programs
• Matching activity conducted under an agreement that was never brought to the Board
• Board membership drawn only from the programme proposing the match, removing independence

Minimization of Personally Identifiable Information Used in Testing, Training, and Research. Develop, document, and implement policies and procedures that address the use of personally identifiable information for internal testing, training, and research; Limit or

• Policies and procedures addressing use of personally identifiable information for internal testing, training and research
• Evidence of the limitation or minimisation applied, such as synthetic data, subsetting or de-identification
• Authorisation records where real personally identifiable information was used, with the justification
• Records showing test, training and research data is removed or destroyed when no longer needed
• Privacy risk assessment covering the testing, training and research use

• Production data copied into lower environments as the default with minimisation applied only on request
• De-identification applied to obvious identifiers while the combination of remaining fields still identifies people
• Test data sets never destroyed, so copies persist long after the project ended

Complaint Management. Implement a process for receiving and responding to complaints, concerns, or questions from individuals about the organizational security and privacy practices that includes: Mechanisms that are easy to use and readily accessible

• The documented complaint management process for security and privacy complaints, concerns and questions
• The intake mechanisms offered and evidence they are easy to use and readily accessible
• Tracking records showing each complaint logged, acknowledged and responded to within the defined time periods
• The complaint response records themselves, showing what was decided and communicated
• Review records showing complaints are analysed for systemic issues

• Intake exists only as a general contact form, so complaints are not identified as such and are never tracked
• Response time periods undefined, so nothing is late and nothing is escalated
• Complaints closed individually with no trend analysis, so a repeated root cause is never addressed

Privacy Reporting. Develop [organization-defined] and disseminate to: [organization-defined] to demonstrate accountability with statutory, regulatory, and policy privacy mandates; and [organization-defined] and other personnel with responsibility for monitoring privacy program compliance; and Review and update

• The defined privacy reports and their content
• Distribution records showing the reports reached the defined oversight bodies and the personnel monitoring privacy compliance
• The reports themselves for the period under assessment
• Review and update records for the reports against the defined frequency
• Evidence the reports address the statutory, regulatory and policy privacy mandates they are meant to demonstrate accountability against

• Reports produced for external oversight while internal personnel responsible for monitoring compliance receive nothing
• Content unchanged year on year, so the report no longer reflects current mandates
• Dissemination undocumented, leaving no evidence the accountability loop closed

Risk Framing. Identify and document: Assumptions affecting risk assessments, risk responses, and risk monitoring; Constraints affecting risk assessments, risk responses, and risk monitoring; Priorities and trade-offs considered by the organization for managing risk; and

• Documented assumptions affecting risk assessments, responses and monitoring
• Documented constraints affecting risk assessments, responses and monitoring
• The organisational priorities and trade-offs recorded for managing risk
• Evidence the risk framing was distributed to those who conduct assessments and make risk decisions
• Review and update records for the risk framing against the defined frequency

• Assumptions held informally by the risk team and never written down, so assessments are inconsistent between assessors
• Trade-offs unstated, leaving risk acceptance decisions without a reference point
• Framing produced once and never revisited after the threat or business environment shifted

Risk Management Program Leadership Roles. Appoint a Senior Accountable Official for Risk Management to align organizational information security and privacy management processes with strategic, operational, and budgetary planning processes; and Establish a Risk Executive

• Appointment documentation for the Senior Accountable Official for Risk Management, including roles and responsibilities
• Evidence the official aligns security and privacy management with strategic, operational and budgetary planning
• The Risk Executive function establishment document, its membership and its terms of reference
• Records of Risk Executive deliberations and the risk decisions taken
• Evidence the Risk Executive view informed system level authorisation decisions

• Official appointed with no involvement in budget planning, which is the alignment the control names
• Risk Executive constituted but never convened, so organisation-wide risk perspective is absent
• Decisions taken at system level with no reference to the Risk Executive position

Information Security and Privacy Resources. Include the resources needed to implement the information security and privacy programs in capital planning and investment requests and document all exceptions to this requirement; Prepare documentation required for

• Capital planning and investment requests showing security and privacy resources included
• Documented exceptions where resources were not included, with the approval for each exception
• The programming and budgeting documentation prepared for the security and privacy programmes
• Evidence of a discrete line item for information security and privacy in programming and budgeting documentation
• Records showing the resources requested were tracked through to allocation

• Security funded within project budgets with no discrete line item, so it cannot be tracked or defended
• Exceptions taken without documentation, which the control requires explicitly
• Requests submitted and reduced in allocation with no record of the resulting unfunded risk

Supply Chain Risk Management Strategy. Develop an organization-wide strategy for managing supply chain risks associated with the development, acquisition, maintenance, and disposal of systems, system components, and system services; Implement the supply chain risk

• The organisation-wide supply chain risk management strategy covering development, acquisition, maintenance and disposal
• Evidence of implementation across the organisation, not only within one programme
• Review and update records for the strategy against the defined frequency and on significant supply chain change
• Linkage from the strategy to the supply chain controls applied in acquisitions
• Identification of the roles accountable for supply chain risk under the strategy

• Strategy covers acquisition while maintenance and disposal, where components leave organisational control, are unaddressed
• Written centrally and never implemented in the procurement process that actually selects suppliers
• No review trigger tied to supply chain events, so a major supplier compromise does not prompt reassessment

Continuous Monitoring Strategy. Develop an organization-wide continuous monitoring strategy and implement continuous monitoring programs that include: Establishing the following organization-wide metrics to be monitored: [organization-defined]; Establishing [organization-defined] and [organization-defined] for control effectiveness; Ongoing monitoring

• The organisation-wide continuous monitoring strategy document
• The defined organisation-wide metrics to be monitored, and the defined monitoring and assessment frequencies
• Ongoing monitoring and assessment output, showing the metrics were actually produced at the stated frequency
• Evidence of correlation and analysis of the monitoring data, and the response actions taken
• Reporting of the security and privacy status to the defined personnel

• Metrics defined but not collected, so the strategy describes monitoring that does not happen
• Data collected without correlation or analysis, producing dashboards nobody acts on
• Frequencies chosen for tool convenience rather than derived from risk, so volatile controls are checked rarely

Purposing. Analyze [organization-defined] supporting mission essential services or functions to ensure that the information resources are being used consistent with their intended purpose

• List of mission essential services and functions, and the information resources supporting each
• The documented analysis of whether those resources are used consistently with their intended purpose
• Definition of the intended purpose against which each resource was analysed
• Findings where resource use had drifted from intended purpose, and the action taken
• Review record showing the analysis is repeated at the defined frequency

• Intended purpose never documented at commissioning, so drift cannot be detected
• Analysis performed on production systems while shared platforms serving many purposes are excluded
• Findings recorded with no action, so repurposed resources continue outside their authorisation

Plan of Action and Milestones Process. Implement a process to ensure that plans of action and milestones for the information security, privacy, and supply chain risk management programs and associated organizational systems: Are developed

• The process document for developing and maintaining plans of action and milestones across security, privacy and supply chain risk management
• Current plans of action and milestones with the remedial actions, resources, milestones and completion dates
• Evidence the plans are reported in accordance with the organisational reporting requirements
• Review records checking the plans for consistency with the organisational risk management strategy and priorities
• Evidence of a central view across all systems rather than plans held only by system owners

• Milestone dates extended repeatedly with no re-approval, so the plan never technically slips
• Plans maintained per system with no organisation-wide view, so common root causes are invisible
• Supply chain risk items excluded from the process despite being in scope of the control

System Inventory. Develop and update [organization-defined] an inventory of organizational systems

• The inventory of organisational systems, with the attributes recorded for each
• Evidence the inventory is updated at the defined frequency
• The process and sources used to build and reconcile the inventory
• Reconciliation records showing the inventory was compared against an independent source such as network discovery or the finance asset register
• Ownership assignment for each system in the inventory

• Inventory maintained manually and reconciled against nothing, so unregistered systems stay invisible
• Cloud subscriptions and vendor hosted services excluded because the inventory was built around owned hardware
• Systems recorded with no owner, so nothing downstream in the programme can be assigned

Measures of Performance. Develop, monitor, and report on the results of information security and privacy measures of performance

• The defined information security and privacy measures of performance and what each is intended to show
• Collected measurement data for the reporting period, with its source
• Reports of the measurement results and the audience they were issued to
• Evidence the measures are monitored over time rather than produced once, showing trend
• Records where a measure prompted a change to the programme

• Measures count activity such as tickets closed rather than performance of the security and privacy programme
• Data collected but never reported, so the measurement loop does not close
• Privacy measures absent while security measures are well developed

Enterprise Architecture. Develop and maintain an enterprise architecture with consideration for information security, privacy, and the resulting risk to organizational operations and assets, individuals, other organizations, and the Nation

• Enterprise architecture documentation showing information security and privacy considerations embedded in it
• Risk assessment results for the enterprise architecture itself
• Evidence architecture decisions record the resulting risk to operations, assets and individuals
• Maintenance records showing the architecture is updated as the estate changes
• Evidence system level designs are checked against the enterprise architecture

• Security architecture maintained as a separate document that the enterprise architecture does not reference
• Architecture describes the target state with no view of the current estate, so risk cannot be assessed against reality
• Privacy considerations absent, leaving data flows and processing purposes outside the architecture

Critical Infrastructure Plan. Address information security and privacy issues in the development, documentation, and updating of a critical infrastructure and key resources protection plan

• The critical infrastructure and key resources protection plan
• The sections addressing information security and privacy issues within that plan
• Identification of the organisation's critical infrastructure and key resources that the plan covers
• Update records showing the plan is maintained as the infrastructure or the threat changes
• Evidence of coordination with the sector or national bodies the plan sits under

• Plan addresses physical protection of infrastructure while information security and privacy issues are omitted
• Critical infrastructure identified once with no reassessment as dependencies shifted to third parties
• Plan held by facilities or operations with security and privacy functions never consulted

Risk Management Strategy. Develops a comprehensive strategy to manage: Security risk to organizational operations and assets, individuals, other organizations, and the Nation associated with the operation and use of organizational systems; and Privacy risk

• The comprehensive risk management strategy covering both security risk and privacy risk
• The stated risk tolerance and the acceptable risk assessment methodologies, response strategies and monitoring processes
• Evidence of implementation consistently across the organisation, not only in one programme
• Review and update records against the defined frequency
• Evidence the strategy informs actual risk decisions, such as risk acceptances referencing the stated tolerance

• Risk tolerance stated qualitatively in terms nobody can apply to a specific decision
• Privacy risk folded into security risk, losing the distinct harms to individuals the control separates
• Strategy exists centrally while business units run their own methodologies, defeating consistency

Requires a personnel security policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved personnel security policy with scope, approver and date
• Evidence the personnel security policy reached the personnel or roles it defines
• Written designation of the official accountable for the personnel security policy and procedures
• Procedures covering screening, transfer, termination and sanctions
• Review record for the personnel security policy and procedures against the defined frequency and triggering events

• Policy owned by human resources with no security involvement in its content
• External providers and contractors outside the policy scope
• No review cadence defined for the personnel security policy, so it silently ages

Requires a risk designation to be assigned to every organizational position, screening criteria to be established for the individuals who fill them, and those designations to be reviewed and updated at an organization-defined frequency.

• Register of positions with assigned risk designations
• Documented screening criteria mapped to each designation level
• Review records at the defined frequency with changes applied
• Evidence designations are applied when positions are created or changed

• Designations assigned to permanent staff roles only, omitting contractor positions
• Screening criteria identical regardless of designation, making the designation meaningless
• Designations never revisited as roles gained privileged access

Requires individuals to be screened before access to the system is authorized, and to be rescreened where organization-defined conditions require it and at the frequency defined for those conditions.

• Screening records showing completion before access authorization
• Documented rescreening conditions and their frequencies
• Rescreening completion records for the populations covered
• Evidence of the treatment applied where screening cannot be completed

• Access granted on the start date while screening is still in progress
• Rescreening conditions never defined, so screening happens once in a career
• Contractors screened by their employer with no evidence provided to the organization

Requires that on termination of employment system access is disabled within an organization-defined period, authenticators and credentials are revoked, exit interviews cover defined security topics, organizational property is retrieved, and the organization retains access to the information and systems the individual controlled.

• Termination checklist covering access disablement, credential revocation, property return and handover
• Access disablement timestamps measured against the defined period
• Exit interview records covering the defined security topics
• Evidence organizational information held by the leaver remains accessible

• Access disabled for core systems while cloud services and remote tools are missed
• Defined disablement period exceeded for involuntary departures where speed matters most
• Data held in personal drives or mailboxes lost when the account is deleted

Requires that when individuals are reassigned or transferred internally their existing logical and physical access is reviewed and confirmed as still needed, defined transfer actions are initiated within a defined period, authorizations are modified to match the new role, and defined personnel are notified within a defined period.

• Transfer process documentation with the defined actions and timeframes
• Records of access reviews performed at transfer
• Evidence of access modification or removal following the review
• Notification records to the defined personnel within the required period

• Access accumulates across roles because transfer only ever adds entitlements
• Transfer treated as a human resources event that never reaches system owners
• Notification timeframes undefined, so changes lag the transfer by months

Requires access agreements for organizational systems to be developed and documented, reviewed and updated at a defined frequency, signed by individuals before access is granted, and re-signed when the agreements are updated or at a defined frequency.

• Current access agreement templates such as non-disclosure and acceptable use agreements
• Signed agreements dated before access was granted
• Version history of the access agreements showing review at the defined frequency
• Re-signature records following updates or at the defined interval

• Agreements signed at hire and never refreshed as the agreements changed
• Privileged users sign the same agreement as general users with no added obligations
• Third party personnel covered by a corporate contract but never signing individually

Requires personnel security requirements including roles and responsibilities to be established for external providers, providers to be required to comply with them, the requirements to be documented, providers to notify defined personnel within a defined period when their personnel with credentials, badges or privileges transfer or leave, and provider compliance to be monitored.

• Documented personnel security requirements for external providers
• Contract clauses binding providers to those requirements and to the notification timeframe
• Notification records received from providers about transfers and terminations
• Monitoring evidence such as provider attestations or audit results

• No obligation on providers to notify departures, so provider staff keep working credentials
• Requirements documented but compliance never monitored
• Badges and privileges tracked per provider organization rather than per individual

Requires a formal sanctions process for individuals who fail to comply with information security and privacy policies and procedures, and requires defined personnel to be notified within a defined period when the sanctions process is initiated, identifying the individual and the reason.

• Documented sanctions process agreed with human resources and legal
• Evidence the process is communicated to staff, for example in the rules of behaviour
• Notification records to the defined personnel within the defined period
• Records of sanctions applied, held with appropriate confidentiality

• Sanctions exist in a human resources handbook that never references security policy breaches
• No notification path, so security is unaware when a policy breach is being handled
• Process defined but never applied, including after repeat violations

Requires security and privacy roles and responsibilities to be written into organizational position descriptions, so that expectations are part of the role rather than an add on.

• Sample position descriptions showing security and privacy responsibilities
• Evidence of coverage across privileged and security relevant roles
• Change records showing descriptions updated when responsibilities changed
• Alignment between position descriptions and role based training requirements

• Security responsibilities named only in dedicated security roles
• Descriptions updated for new hires while incumbents keep older versions
• Privacy responsibilities omitted entirely

Policy and Procedures. Develop, document, and disseminate to [organization-defined]: [organization-defined] personally identifiable information processing and transparency policy that: Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and Is consistent

• The personally identifiable information processing and transparency policy, covering purpose, scope, roles, responsibilities and management commitment
• Evidence the policy addresses coordination among organisational entities and compliance
• Procedures implementing the policy and its associated controls
• Dissemination evidence to the defined personnel or roles
• Designation of the official to manage the policy and procedures, and review records against the defined frequency and triggering events

• Privacy obligations covered inside the security policy, with no distinct processing and transparency policy
• Coordination among entities unaddressed, so legal, marketing and product each interpret processing rules differently
• Review triggers not defined, so a change in privacy law does not prompt a policy update

Authority to Process Personally Identifiable Information. Determine and document the [organization-defined] that permits the [organization-defined] of personally identifiable information; and Restrict the [organization-defined] of personally identifiable information to only that which is authorized

• The documented authority that permits each processing of personally identifiable information, naming the statute, regulation or other basis
• Mapping from each processing activity to its authority
• Evidence processing is restricted to what the authority permits, such as configuration or procedural limits
• Records of review where a new processing activity was assessed against existing authority
• Escalation records where processing was stopped or changed because authority was absent

• Authority recorded at system level while individual processing activities within it have no separate basis
• Secondary uses such as analytics and model training added with no reassessment of authority
• Authority documented but nothing restricts processing to it, so the record and the practice diverge

Personally Identifiable Information Processing Purposes. Identify and document the [organization-defined] for processing personally identifiable information; Describe the purpose(s) in the public privacy notices and policies of the organization; Restrict the [organization-defined] of personally identifiable

• The identified and documented purposes for processing personally identifiable information
• The public privacy notices and policies where those purposes are described, showing consistency with the internal record
• Evidence processing is restricted to the identified purposes, such as access controls or data use rules
• Monitoring records showing changes in processing were reviewed against the stated purposes
• Records where the notice was updated because a purpose changed

• Internal purpose register and the public notice describe different purposes, and neither is reconciled
• Purposes stated so broadly that no processing could ever fall outside them, which defeats restriction
• New processing added without any check against the purposes already published

Consent. Implement [organization-defined] for individuals to consent to the processing of their personally identifiable information prior to its collection that facilitate individuals' informed decision-making

• The consent tools and mechanisms implemented, with screenshots of the consent presentation as an individual sees it
• Evidence consent is obtained prior to collection
• Retained records of individual consent, showing what was consented to and when
• Evidence the mechanism supports informed decision making, such as plain language and granular choices
• The withdrawal mechanism and evidence that withdrawal stops the processing

• Consent bundled into a single acceptance covering unrelated processing, so choice is not meaningful
• Consent captured as a flag with no record of the wording the individual actually saw
• Withdrawal accepted at the interface while downstream systems keep processing

Privacy Notice. Provide notice to individuals about the processing of personally identifiable information that: Is available to individuals upon first interacting with an organization, and subsequently at [organization-defined]; Is clear and easy-to-understand, expressing information

• The privacy notice text as published, and evidence it is available on first interaction
• The defined subsequent points at which the notice is provided again
• Assessment or evidence that the notice is clear and easy to understand, such as a readability or plain language review
• Evidence the notice covers the processing described in the internal record
• Version history showing when the notice changed and how individuals were informed

• Notice reachable only from a footer link, not presented on first interaction as the control requires
• Written for legal defensibility rather than comprehension, failing the clear and easy to understand test
• Updated silently, so individuals are not informed the terms of processing changed

System of Records Notice. For systems that process information that will be maintained in a Privacy Act system of records: Draft system of records notices in accordance with OMB guidance and submit new and

• Identification of systems that maintain information in a Privacy Act system of records
• Drafted system of records notices and evidence of submission to the required oversight for review
• The published Federal Register notices for new, modified and rescinded systems of records
• Review records for the notices at the defined frequency
• Evidence the notice content matches how the system actually operates

• System of records identified but the notice never published, so the collection has no public basis
• Notice published at inception and not revised when the routine uses or categories of records changed
• Notices reviewed for existence rather than accuracy, so drift between notice and practice persists

Specific Categories of Personally Identifiable Information. Apply [organization-defined] for specific categories of personally identifiable information

• Identification of the specific categories of personally identifiable information in scope, such as social security numbers or criminal history
• The defined processing conditions or additional safeguards applied to each category
• Evidence those conditions are enforced technically or procedurally
• Agreements, contracts and information sharing arrangements reflecting the category specific requirements
• Records of exceptions and their approval

• Category identified in policy but not labelled in the data, so no control can act on it
• Enhanced safeguards applied in the primary system while extracts and reports carry the same category unprotected
• Third party agreements silent on the special category conditions the organisation applies internally

Computer Matching Requirements. When a system or organization processes information for the purpose of conducting a matching program: Obtain approval from the Data Integrity Board to conduct the matching program; Develop and enter into

• Data Integrity Board approval for each matching program conducted
• The computer matching agreement entered into with the counterpart agency
• Published matching notices as required
• Evidence the matching conducted stayed within the terms and duration of the agreement
• Records of renewal or termination of matching agreements

• Matching conducted under an expired agreement, since expiry is rarely tracked
• Board approval obtained for the programme while subsequent scope expansion is never re-approved
• Matching notices not published, leaving affected individuals without notice of the programme

Personally identifiable information processing has documented authority, purpose specification, consent, individual access, and complaint management mechanisms.

• Authority to process documentation
• Privacy notices
• Consent records
• Data subject access process and metrics
• Complaint handling records

• Authority not documented per system
• Notices outdated
• Consent not granular
• Access requests not tracked

Requires a risk assessment policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved risk assessment policy with scope, approver and date
• Evidence the risk assessment policy reached the personnel or roles it defines
• Written designation of the official accountable for the risk assessment policy and procedures
• Procedures covering assessment method, scoring and risk acceptance
• Review record for the risk assessment policy and procedures against the defined frequency and triggering events

• Policy defines a method that assessments do not actually follow
• Privacy risk to individuals absent from the policy
• No review cadence defined for the risk assessment policy, so it silently ages

Requires a cyber threat hunting capability to be established and maintained to search for indicators of compromise and to detect, track and disrupt threats that have evaded existing controls, and requires that capability to be exercised at an organization-defined frequency.

• Documented threat hunting capability including scope, tooling and data sources
• Hunt plans and completed hunt reports at the defined frequency
• Findings and the disruption or remediation actions they produced
• Evidence hunts are informed by current threat intelligence

• Hunting equated with reviewing alerts already generated by existing tools
• Capability exists on paper but no hunts have been performed at the stated frequency
• Hunt findings never fed back into detection rules

Requires the system and the information it processes, stores and transmits to be categorized, the categorization result and its rationale to be documented in the security plan, and the authorizing official or their representative to review and approve the categorization decision.

• Security categorization determination with supporting rationale
• Information type inventory used to derive the categorization
• Security plan section holding the recorded categorization
• Approval evidence from the authorizing official or designated representative

• Categorization asserted with no rationale or information type analysis behind it
• Never reviewed after the system began handling more sensitive information
• Approved by the system owner rather than the authorizing official

Requires a risk assessment that identifies threats and vulnerabilities, judges how likely each is and how badly the organization would be harmed by unauthorized access, use, disclosure, disruption, modification or destruction, and judges the likelihood and impact of adverse effects on individuals from personal information processing, with results integrated into organizational risk decisions, documented, reviewed at a defined frequency, issued to defined personnel, and updated after defined events or significant change.

• Risk assessment report covering threats, vulnerabilities, likelihood and impact
• Analysis of adverse effects on individuals from personal information processing
• Distribution record to the defined personnel
• Update history showing reassessment at the defined frequency and after significant change
• Evidence results feed organizational and mission level risk decisions

• Assessment addresses organizational harm only and ignores harm to individuals
• Performed once at authorization and never refreshed after major change
• Results never reach the people who make risk decisions

Requires vulnerability monitoring and scanning of the system and hosted applications at a defined frequency or randomly by a defined process and when new relevant vulnerabilities are reported, using tools and techniques that support standardised enumeration, checklists and impact measurement, with results analysed, remediation within defined response times by risk, results shared with defined personnel, and privileged scanning access where required.

• Scan schedule and coverage evidence across the system and hosted applications
• Scan reports with findings ranked by severity
• Defined remediation timeframes by risk level and evidence they are met
• Records of scan result distribution to the defined personnel
• Configuration showing authenticated or privileged scanning where required

• Unauthenticated scanning only, which understates the real vulnerability position
• Remediation timeframes defined but routinely exceeded with no risk acceptance
• Coverage gaps for containers, cloud services and short lived infrastructure

Technical Surveillance Countermeasures Survey. Employ a technical surveillance countermeasures survey at [organization-defined] [organization-defined]

• The defined locations and the defined frequency or events at which a technical surveillance countermeasures survey is employed
• Survey reports for the period, produced by the surveying party
• Findings raised by surveys and the remediation of each
• Evidence of survey trigger events such as post construction or post visitor access
• Handling and distribution controls over the survey reports themselves

• Survey conducted once at fit out with no recurring or event driven cadence
• Findings recorded with no remediation tracking, so a detected weakness persists
• Survey scope covers meeting rooms while equipment areas and cabling paths are excluded

Requires findings raised by assessments, monitoring activity and audits, covering both security and privacy, to be responded to in line with the organization's stated risk tolerance, so each is remediated, mitigated, transferred or formally accepted.

• Documented risk tolerance used to judge findings
• Finding register showing the response decision and owner for each item
• Formal risk acceptance records where a finding is not remediated
• Evidence responses are completed and verified

• Findings tracked but neither remediated nor formally accepted, leaving them open indefinitely
• Risk tolerance never expressed in terms that can decide a specific finding
• Acceptance made by someone without the authority to accept that level of risk

Privacy Impact Assessments. Conduct privacy impact assessments for systems, programs, or other activities before: Developing or procuring information technology that processes personally identifiable information; and Initiating a new collection of personally identifiable information that:

• Completed privacy impact assessments for systems, programs and activities in scope
• Evidence each assessment was conducted before developing or procuring technology that processes personally identifiable information
• Evidence of assessment before initiating a new collection of personally identifiable information
• The privacy risks identified and the mitigations agreed, with owners
• Records showing the assessment was revisited when the processing changed

• Assessment completed after the system is built, when the design decisions it should influence are already fixed
• New collections added to an existing system with no fresh assessment
• Mitigations agreed in the assessment never tracked to implementation

Requires critical system components and functions to be identified through a criticality analysis of organization-defined systems, components or services, performed at organization-defined decision points in the system development life cycle.

• Criticality analysis results identifying critical components and functions
• Documented decision points in the life cycle at which the analysis is performed
• Evidence the analysis informs protection and supply chain decisions
• Update records when architecture or dependencies changed

• Criticality assumed from system importance rather than analysed at component level
• Analysis performed at design only and never repeated as the architecture changed
• Results not used, so critical components receive no additional protection

Requires a system and services acquisition policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved system and services acquisition policy with scope, approver and date
• Evidence the system and services acquisition policy reached the personnel or roles it defines
• Written designation of the official accountable for the system and services acquisition policy and procedures
• Procedures covering requirements definition, contract terms and developer obligations
• Review record for the system and services acquisition policy and procedures against the defined frequency and triggering events

• Policy applies to formal procurement while cloud services are bought on a card outside it
• Security requirements not carried into contract templates
• No review cadence defined for the system and services acquisition policy, so it silently ages

Requires the developer of the system, component or service to perform configuration management during defined life cycle stages, to document and control the integrity of changes to defined configuration items, to implement only organization-approved changes, to document approved changes with their potential security and privacy impacts, and to track security flaws and their resolution and report findings to defined personnel.

• Contract or agreement clauses imposing developer configuration management duties
• Developer change records showing approval before implementation
• Documented configuration items under developer configuration management
• Flaw tracking records and reports received from the developer

• Obligations assumed from the developer's own process with nothing in the contract
• No visibility of developer changes, so approval is nominal
• Flaw tracking exists at the developer but findings are never reported to the organization

Requires the developer, at all stages after design, to plan and perform ongoing security and privacy control assessment, to carry out defined testing types at a defined frequency, depth and coverage, to produce evidence of the assessment plan being executed and its results, to implement a verifiable flaw remediation process, and to correct the flaws that testing identifies.

• Developer assessment and test plan covering the required testing types
• Test execution evidence and results supplied by the developer
• Flaw remediation records showing identified flaws corrected and verified
• Contract clauses requiring the testing depth, coverage and frequency

• Testing evidence claimed but never provided to the organization for review
• Depth and coverage undefined, so a single scan satisfies the requirement on paper
• Flaws found in testing closed without verification that the fix works

Requires the developer to work to a documented process that deals expressly with the security and privacy requirements, names the standards and tools in use, records the tool options and configurations chosen, and controls the integrity of changes to that process and toolchain, with the organization reviewing all of it at a defined frequency against defined criteria.

• Developer development process documentation showing security and privacy requirements addressed
• Register of standards, tools, tool options and configurations used
• Change control evidence for the development process and toolchain
• Organizational review records at the defined frequency against the defined criteria

• Process documented by the developer but never reviewed by the acquiring organization
• Tool configurations undocumented, so security relevant settings can change silently
• Review criteria never defined, so the review has no pass or fail meaning

Developer-provided Training. Require the developer of the system, system component, or system service to provide the following training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms:

• Contract or solicitation clauses requiring the developer to provide the defined training
• The training materials delivered by the developer on correct use and operation of the security and privacy functions and mechanisms
• Attendance or completion records for the organisational personnel who received it
• Evidence the training covered the implemented functions specifically, not generic product training
• Arrangements for training refresh when the developer changes those functions

• Standard vendor product training accepted in place of training on the implemented security and privacy mechanisms
• Training delivered once at handover with no provision for new operators or later releases
• Requirement stated in the contract with no evidence the training was ever delivered

Developer Security and Privacy Architecture and Design. Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that: Is consistent with the organization's

• Contract requirement for the developer to produce a design specification and security and privacy architecture
• The delivered architecture, showing consistency with the organisation's enterprise architecture
• Documentation of how the architecture accurately and completely describes the required security and privacy functionality
• Evidence the architecture expresses the allocation of functionality among components and the design rationale
• Organisational review and acceptance of the delivered architecture

• Developer supplies a solution diagram rather than a security and privacy architecture with allocation and rationale
• No check for consistency with the organisation's enterprise architecture, so the delivered design conflicts with it
• Architecture accepted without review, so gaps surface only at assessment

Requires high level security and privacy requirements for the system or service to be established during mission and business process planning, the resources needed to protect it to be identified, documented and allocated through capital planning and investment control, and a discrete security and privacy line item to exist in programming and budgeting documentation.

• Documented high level security and privacy requirements from the planning stage
• Budget or investment documentation showing a discrete security and privacy line item
• Resource allocation records tied to the protection of the system
• Evidence security requirements were considered before funding decisions

• Security funded from residual project budget with no separate line item
• Requirements determined after design, when funding is already committed
• Ongoing operational security costs omitted, only build costs funded

Customized Development of Critical Components. Reimplement or custom develop the following critical system components: [organization-defined]

• The defined list of critical system components to be reimplemented or custom developed, with the criticality rationale
• Development records for those components under the organisation's secure development life cycle
• Evidence of why the commercially available component was unacceptable, linking to a supply chain risk finding
• Assurance evidence for the custom component, such as design review and testing results
• Ongoing maintenance ownership for the custom component

• Criticality rationale absent, so the choice to custom develop cannot be justified or bounded
• Custom component built and then maintained by nobody, becoming a greater risk than the product it replaced
• Custom development held to a lower assurance bar than the acquired products it replaced

Developer Screening. Require that the developer of [organization-defined]: Has appropriate access authorizations as determined by assigned [organization-defined] ; and Satisfies the following additional personnel screening criteria: [organization-defined]

• Definition of the systems, components or services whose developers must be screened
• The assigned access authorisations required of those developers
• The additional personnel screening criteria defined, and evidence each developer satisfies them
• Contract clauses imposing the screening requirement on the developer organisation
• Records of rescreening or of access withdrawal when a developer no longer meets the criteria

• Screening imposed on the prime developer with subcontracted developers unscreened
• Screening evidence held by the developer and never verified by the organisation
• No re-screening trigger, so authorisation persists after the basis for it lapses

Requires system components to be replaced once the developer, vendor or manufacturer no longer provides support, or alternative sources of continued support to be provided, with documented justification and approval where an unsupported component has to stay in use.

• Policy and procedures covering replacement, or justified continued use, of unsupported system components
• Hardware and software inventory recording vendor support status and end of support dates per component
• Records of components actually replaced once vendor support ended, with dates
• Documented approvals carrying the justification for each unsupported component still in use, and the compensating measures relied on
• Contracts or agreements evidencing alternative continued support, in house or from an external provider, for components the vendor no longer supports
• System security plan and supply chain risk management plan sections identifying unsupported components and the plan for them

• Inventory lists components but never records the vendor end of support date, so nothing triggers replacement
• Unsupported components still running in production with no documented approval or justification on file
• An exception approved once and never re-reviewed, so a temporary acceptance became permanent
• Alternative support claimed for an unsupported component with no contract or in house capability behind it
• Replacement identified in a plan with no funded date, owner or tracking to completion
• Only software tracked for support status while firmware, hardware and embedded components are ignored

Specialization. Employ [organization-defined] on [organization-defined] supporting mission essential services or functions to increase the trustworthiness in those systems or components

• Identification of the systems or components supporting mission essential services or functions that are in scope
• The specialisation employed, such as design modification, augmentation or reconfiguration, documented for each
• Evidence linking the specialisation to the increase in trustworthiness sought
• Documented evidence of the modification, augmentation or reconfiguration as implemented
• Assessment or test results confirming the specialisation achieved its intent without breaking function

• Hardening applied generically rather than specialised to the mission essential function it protects
• Modification implemented with no record, so it is lost at the next refresh or vendor update
• Trustworthiness increase asserted with no assessment behind it

Design For Cyber Resiliency. Design organizational systems, system components, or system services to achieve cyber resiliency by: Defining the following cyber resiliency goals: [organization-defined]. Defining the following cyber resiliency objectives: [organization-defined]. Defining the following

• The defined cyber resiliency goals, objectives, techniques and design principles recorded for the system
• Design documentation showing how each technique and design principle was applied
• Traceability from the resiliency objectives to concrete design decisions and components
• Evidence resiliency was addressed at design time rather than added afterwards
• Test or analysis results demonstrating the system behaves as intended under the adversary conditions the goals name

• Resiliency goals stated at a level that no design decision can be traced to
• Techniques selected from a list with no analysis of which adversary effects they actually counter
• Resiliency claimed from redundancy alone, which addresses failure rather than adversary presence

Requires the system to be acquired, developed and managed using an organization-defined system development life cycle that incorporates security and privacy considerations, with security and privacy roles defined and documented across that life cycle, the individuals holding them identified, and organizational risk management integrated into life cycle activities.

• Documented system development life cycle showing security and privacy activities at each stage
• Defined security and privacy roles across the life cycle and the named individuals holding them
• Evidence risk management activities are integrated into life cycle gates
• Records showing the life cycle was actually followed for this system

• Life cycle documented centrally while delivery teams follow their own process
• Security roles defined but unassigned, so nobody performs the activity
• Risk management runs parallel to delivery instead of gating it

Requires acquisition contracts for the system, component or service to include, directly or by reference and using standardised contract language, the security and privacy functional requirements, strength of mechanism and assurance requirements, the controls needed, documentation requirements, protection of that documentation, description of the development environment and intended operating environment, allocation of responsibility for control implementation, and acceptance criteria.

• Contract or purchase agreement containing the required security and privacy requirement sets
• Standardised contract language or clause library used in acquisition
• Documented acceptance criteria and the acceptance decision record
• Allocation of control responsibility between the organization and the supplier

• Requirements sent to the supplier during evaluation but never written into the signed contract
• Acceptance criteria absent, so delivery is accepted on demonstration alone
• Responsibility for shared controls left ambiguous between the parties

Requires administrator documentation covering secure configuration, installation and operation, effective use of security and privacy functions, and known vulnerabilities in privileged functions, plus user documentation covering user accessible security and privacy functions and responsibilities, with action taken when documentation is unavailable, and documentation distributed to defined personnel.

• Administrator documentation covering secure configuration, installation and operation
• User documentation covering security and privacy functions and user responsibilities
• Record of action taken where documentation was unavailable or inadequate
• Distribution evidence to the defined personnel or roles

• Documentation exists for the product generally but not for the configuration deployed here
• No documented response where a supplier could not provide documentation
• Documentation held by one engineer and never distributed

Requires organization-defined systems security and privacy engineering principles to be applied when specifying, designing, developing, implementing and modifying the system and its components, so that protection is designed in rather than added afterwards.

• Documented set of security and privacy engineering principles adopted by the organization
• Design documentation showing how the principles were applied to this system
• Design review records that check the principles
• Evidence the principles are applied to modifications, not only new build

• Principles named in policy but absent from any actual design artefact
• Applied at initial build and abandoned during later changes
• Privacy engineering principles omitted entirely

Requires providers of external system services to meet the organization's security and privacy requirements and to operate organization-defined controls, requires oversight and user roles and responsibilities for those services to be defined and documented, and requires defined methods to monitor provider compliance on a continuing basis.

• Contracts or agreements imposing the organizational requirements and defined controls
• Documented oversight roles and responsibilities for each external service
• Ongoing monitoring evidence such as reviewed assurance reports or service reviews
• Register of external system services in use and their assessed risk

• Assurance report collected once at onboarding and never reviewed again
• Shadow services adopted by teams without any oversight arrangement
• Requirements imposed contractually but nothing monitors whether they hold

Requires a system and communications protection policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved system and communications protection policy with scope, approver and date
• Evidence the system and communications protection policy reached the personnel or roles it defines
• Written designation of the official accountable for the system and communications protection policy and procedures
• Procedures covering boundary protection, cryptography and transmission protection
• Review record for the system and communications protection policy and procedures against the defined frequency and triggering events

• Policy describes perimeter architecture that cloud adoption has already replaced
• Cryptographic standards referenced but never maintained as algorithms age
• No review cadence defined for the system and communications protection policy, so it silently ages

Requires the network connection behind a communications session to be terminated when the session ends or after an organization-defined period of inactivity, rather than left established once it is no longer in use.

• Documented inactivity period for network disconnection
• Device and application configuration enforcing session and connection termination
• Sample logs showing idle connections being closed
• Coverage evidence across remote access, administrative and application sessions

• Application session ends while the underlying network connection stays open
• Inactivity period never defined, leaving vendor defaults measured in hours
• Administrative sessions to network devices exempt from any timeout

Trusted Path. Provide a [organization-defined] isolated trusted communications path for communications between the user and the trusted components of the system; and Permit users to invoke the trusted communications path for communications between the

• Identification of the trusted components and the security functions the trusted path serves
• Design documentation showing the path is logically isolated and distinguishable from other communications
• Evidence users can invoke the trusted path themselves, with the invocation mechanism documented
• Configuration showing the path cannot be imitated or intercepted by other software on the endpoint
• Independent test or assessment results confirming isolation

• Path claimed from TLS to a login page, which does not isolate the path from software on the user's own machine
• No user invocable mechanism, so the user cannot establish that they are talking to the real system
• Isolation asserted from design intent with no independent testing

Requires cryptographic keys to be established and managed in line with organization-defined key management requirements wherever cryptography is used in the system, covering generation, distribution, storage, access, rotation and destruction.

• Documented key management requirements covering the full key life cycle
• Key inventory identifying keys, owners, purposes and expiry
• Evidence of protected key generation and storage, such as a key management service or hardware module
• Key rotation and destruction records

• Keys and secrets embedded in code or configuration files
• Rotation defined but never performed because usage is undocumented
• No destruction step, so retired keys remain available in backups

Requires the organization to determine the specific uses for which cryptography is required in the system and to implement the types of cryptography defined for each of those uses, so that algorithm and mechanism choices follow a stated purpose.

• Documented cryptographic uses for the system and the cryptography required for each
• Configuration evidence showing the specified algorithms and modes in use
• Inventory of cryptographic implementations and their validation status
• Review evidence that the choices remain appropriate as standards change

• Cryptographic uses never enumerated, so implementation choices are made per project
• Deprecated algorithms remain enabled for backwards compatibility
• Validation status of cryptographic modules unknown

Requires collaborative computing capability such as cameras and microphones to be barred from remote activation except in the circumstances the organization has defined, and requires people physically at the device to be given a clear indication when it is in use.

• Policy prohibiting remote activation and listing any approved exceptions
• Configuration evidence disabling remote activation on in scope devices
• Evidence of a visible or audible indication of use at the device
• Inventory of collaborative computing devices in scope

• Conferencing platforms allow hosts to enable participant cameras remotely by default
• Indication of use provided in software only, which a compromised host can suppress
• Meeting room equipment omitted from the device inventory

Transmission of Security and Privacy Attributes. Associate [organization-defined] with information exchanged between systems and between system components

• The defined security and privacy attributes required to accompany information exchanged between systems and components
• Design and configuration evidence showing attributes travel with the information across each exchange
• Evidence the receiving system interprets and honours the transmitted attributes
• Integrity protection over the attributes in transit so they cannot be altered
• Records of exchanges where attribute mismatch caused the transfer to be refused

• Attributes present inside each system but dropped at the interface between them
• Receiving system accepts attributes and ignores them, so transmission has no effect
• Attributes transmitted without integrity protection, so a downgrade in transit is undetectable

Requires public key certificates to be issued under an organization-defined certificate policy or obtained from an approved service provider, and requires trust stores managed by the organization to contain only approved trust anchors.

• Certificate policy or the approval record for the external certificate provider
• Certificate inventory with issuer, subject and expiry
• Trust store contents reviewed against the approved trust anchor list
• Procedures for certificate issue, renewal and revocation

• Self signed certificates in production with no governing policy
• Trust stores carry inherited defaults that nobody has reviewed
• Expiry unmanaged, so outages and emergency exceptions follow

Mobile Code. Define acceptable and unacceptable mobile code and mobile code technologies; and Authorize, monitor, and control the use of mobile code within the system

• The defined lists of acceptable and unacceptable mobile code and mobile code technologies
• Authorisation records for the use of mobile code within the system
• Configuration enforcing the restriction, such as browser, endpoint or gateway policy blocking unacceptable technologies
• Monitoring evidence showing mobile code use is observed and unauthorised use detected
• Review record showing the acceptability lists were revisited as technologies changed

• Lists written years ago naming technologies no longer in use while current script and macro technologies are unaddressed
• Policy defined with no enforcement point, so the lists describe an intent rather than a control
• No monitoring, so unauthorised mobile code use is invisible

Requires user functionality, including user interface services, to be kept separate from system management functionality so that ordinary use of the system does not expose administrative interfaces and capabilities.

• Architecture documentation showing separation of user and management planes
• Configuration evidence such as separate management interfaces, networks or hosts
• Access control showing administrative functions are unreachable from user contexts
• Test results confirming management functions are not exposed to ordinary users

• Administrative console served from the same interface and address as the user application
• Management network reachable from the general user network
• Separation designed but broken by a convenience path added later

Requires the system, when it is the authoritative source for name resolution, to return origin authentication and integrity artefacts with its responses, and within a hierarchical namespace to publish the security status of delegated child zones so a chain of trust between parent and child can be verified.

• Configuration evidence for signed authoritative zones
• Validation output showing origin authentication artefacts are returned
• Records showing delegation material for child zones is published and current
• Key management and rollover procedures for zone signing

• Signing enabled for the main zone while subdomains and delegations are unsigned
• Key rollover unmanaged, so validation breaks or signing is quietly abandoned
• Chain of trust broken at delegation because parent records were not updated

Requires the system, when acting as a recursive or caching resolver, to request and perform data origin authentication and integrity verification on the name resolution responses it receives from authoritative sources.

• Resolver configuration showing validation of responses is enabled
• Test evidence that deliberately invalid responses are rejected
• Monitoring or logs of validation failures
• Inventory of resolvers in use, including those provided by cloud platforms

• Validation enabled on central resolvers while endpoints use unvalidated public resolvers
• Validation disabled to work around a broken zone and never re-enabled
• Failures unmonitored, so a silent loss of validation is invisible

Requires the set of systems that together provide name resolution for the organization to be fault tolerant and to implement separation between internal and external resolution roles.

• Architecture documentation showing redundant name resolution servers
• Evidence of internal and external role separation in the resolution design
• Failover test results for name resolution services
• Diversity evidence such as separate networks or providers

• Two servers presented as redundant while sharing one host, network or provider
• Internal and external resolution served by the same instances
• Failover never tested, so redundancy is assumed rather than proven

Requires the authenticity of communications sessions to be protected so that sessions cannot be hijacked, replayed or impersonated between the legitimate parties.

• Configuration evidence for authenticated and integrity protected session establishment
• Session identifier handling design covering generation, binding and invalidation
• Test results demonstrating resistance to session fixation and replay
• Coverage across web, application programming interface and machine to machine sessions

• Session identifiers not regenerated after authentication, allowing fixation
• Session tokens transmitted or stored in ways that allow reuse from another context
• Server side invalidation missing, so logout only clears the client

Fail in Known State. Fail to a [organization-defined] for the following failures on the indicated components while preserving [organization-defined] in failure: [organization-defined]

• The defined list of failures that require the system to fail to a known state
• The defined known state and the system state information to be preserved in failure
• Design and configuration evidence implementing the fail to known state behaviour on the named components
• Test records demonstrating the behaviour for each defined failure type
• Evidence that preserved state does not itself leak information or leave access open

• Failure list covers component crash but not the security function failures that matter most
• Known state undefined, so the system fails open on some paths and closed on others
• Behaviour never tested, so the fail safe design is unverified

Thin Nodes. Employ minimal functionality and information storage on the following system components: [organization-defined]

• The defined system components required to operate as thin nodes
• Configuration evidence showing minimal functionality and minimal local information storage on those components
• Baseline showing what functions and storage were removed or disabled
• Verification that data does not accumulate locally, for example through inspection of local storage
• Change control preventing functionality being added back to thin nodes

• Thin client deployed while local caching, print spooling and profile storage retain data on the device
• Minimal build defined at rollout with agents and tools added afterwards, restoring the surface
• No verification of local storage, so the minimal claim is untested

Decoys. Include components within organizational systems specifically designed to be the target of malicious attacks for detecting, deflecting, and analyzing such attacks

• Identification of the decoy components deployed and their placement within the system
• Design documentation showing decoys are isolated so an attack on them cannot reach production
• Detection configuration showing interaction with a decoy raises an alert
• Records of interactions detected and how each was analysed
• Evidence legitimate users and scanners cannot trip decoys routinely, which would destroy their signal value

• Decoys deployed with alerts routed nowhere, so interaction is recorded but never seen
• Decoy shares credentials or network paths with production, turning it into an entry point
• Vulnerability scanners trip decoys constantly, so alerts are muted and real interaction is missed

Platform-independent Applications. Include within organizational systems the following platform independent applications: [organization-defined]

• The defined platform independent applications included within the system
• Design or build evidence showing the application does not depend on a specific platform
• Evidence the application has been run on more than one platform, demonstrating the independence claimed
• Rationale linking platform independence to the resilience or diversity objective it serves
• Maintenance evidence that platform independence is preserved through change

• Independence claimed from the language runtime while the application depends on platform specific services
• Never actually deployed on a second platform, so portability is theoretical
• Platform specific dependencies introduced during maintenance with no check against the requirement

Requires the confidentiality or integrity, as the organization determines, of organization-defined information at rest to be protected, so that stored information is safeguarded independently of the access controls in front of it.

• Definition of the information at rest in scope and whether confidentiality, integrity or both are protected
• Encryption configuration for storage, databases and backups
• Key management arrangements supporting the protection
• Verification evidence such as storage configuration reports

• Primary storage encrypted while backups, exports and logs are not
• Encryption keys held beside the data they protect
• Scope never defined, so protection is applied inconsistently across data stores

Heterogeneity. Employ a diverse set of information technologies for the following system components in the implementation of the system: [organization-defined]

• The defined system components required to use diverse information technologies
• List of technologies actually deployed for those components, showing the diversity achieved
• Analysis of the common mode failure or common vulnerability the diversity is intended to break
• Acquisition documentation showing diversity was a selection requirement
• Evidence the diverse technologies are each maintained and patched, since diversity multiplies maintenance

• Different vendor products that share the same underlying library or platform, so the common mode remains
• Diversity introduced at one layer while all instances still run on one hypervisor or one cloud region
• Secondary technology poorly maintained, so diversity increases risk rather than reducing it

Security Function Isolation. Isolate security functions from nonsecurity functions

• The list of security functions required to be isolated from non-security functions
• Design documentation showing the isolation boundary and the mechanism enforcing it
• Configuration evidence that non-security code cannot access or modify security function state
• Test or assessment results demonstrating the isolation holds
• Evidence that interfaces crossing the boundary are minimal and defined

• Security functions running in the same address space or privilege level as application code, with isolation claimed from process separation alone
• Administrative tooling given access across the boundary, defeating the isolation for the highest risk accounts
• Boundary designed but never tested, so bypass paths are unknown

Concealment and Misdirection. Employ the following concealment and misdirection techniques for [organization-defined] at [organization-defined] to confuse and mislead adversaries: [organization-defined]

• The defined concealment and misdirection techniques employed, and the systems and time periods they apply to
• Configuration or design evidence implementing each technique
• Rationale linking each technique to the adversary behaviour it is intended to confuse
• Records of adversary activity observed or misdirected during the period
• Evidence the techniques do not impair legitimate operation or troubleshooting

• Technique deployed permanently rather than at the defined times, so an adversary can characterise and discount it
• Concealment breaks legitimate monitoring, so operators disable it quietly
• No observation of effect, so it is impossible to say whether the technique does anything

Covert Channel Analysis. Perform a covert channel analysis to identify those aspects of communications within the system that are potential avenues for covert [organization-defined] channels; and Estimate the maximum bandwidth of those channels

• The covert channel analysis documentation identifying potential storage or timing channels
• The defined channel types analysed, and the scope of communications covered
• Estimated maximum bandwidth for each channel identified
• Decisions on each channel, whether accepted, reduced or eliminated, with rationale
• Evidence the analysis was repeated after significant design change

• Analysis covers storage channels while timing channels, which the defined type may include, are skipped
• Bandwidth estimated qualitatively as low, which does not meet the estimation requirement
• Analysis performed at accreditation and never revisited despite architecture change

System Partitioning. Partition the system into [organization-defined] residing in separate [organization-defined] domains or environments based on [organization-defined]

• The defined system components and the separate physical or logical domains they are partitioned into
• The defined circumstances or criteria on which the partitioning is based
• Architecture and facility diagrams showing the partitions and the boundaries between them
• Configuration evidence that communication between partitions is restricted to defined interfaces
• Verification that no component spans partitions in a way that defeats the separation

• Partitioning at the network layer while a shared management plane or shared storage crosses every partition
• Criteria for partitioning undocumented, so new components are placed by convenience
• Partition boundaries drawn in the diagram but not enforced by configuration

Non-modifiable Executable Programs. For [organization-defined] , load and execute: The operating environment from hardware-enforced, read-only media; and The following applications from hardware-enforced, read-only media: [organization-defined]

• Definition of the systems in scope and the operating system components and applications required to load from read-only media
• Evidence the media enforcement is hardware based, such as a physical write protect or read only device, not a software attribute
• Boot or load records showing the operating environment executed from that media
• Procedure for updating the read-only media, including who authorises and how integrity is re-established
• Verification that the executing image matches the authorised image

• Read only enforced by file system permissions rather than hardware, which the control specifically excludes
• Operating environment loaded from protected media while applications load from writable storage
• Update procedure undefined, so the write protect is left disabled after maintenance

External Malicious Code Identification. Include system components that proactively seek to identify network-based malicious code or malicious websites

• Identification of the system components deployed to proactively seek network based malicious code or malicious websites
• Configuration of those components, including the sources and frequency of proactive checking
• Records of malicious code or sites identified during the period and the action taken
• Evidence the components operate proactively rather than only inspecting user initiated traffic
• Isolation of the seeking component so its own exposure does not become a compromise path

• Capability limited to inspecting traffic users generate, with no proactive seeking, which is the distinguishing requirement
• Identified malicious sites recorded but never fed into the blocking mechanism that would act on them
• The seeking component runs on the production network, so its deliberate contact with malicious content endangers the estate

Distributed Processing and Storage. Distribute the following processing and storage components across multiple [organization-defined]: [organization-defined]

• The defined processing and storage components required to be distributed, and the defined locations they are distributed across
• Architecture documentation showing the actual distribution achieved
• Evidence the locations are genuinely independent, covering power, network and provider dependencies
• Monitoring of the distributed components for compromise, since distribution alone does not detect it
• Test evidence that loss of one location leaves the function operating

• Distribution across availability zones sharing one region, one provider and one control plane
• Storage distributed while the processing that depends on it sits in a single location
• Distribution never failure tested, so the surviving location's capacity is unknown

Out-of-band Channels. Employ the following out-of-band channels for the physical delivery or electronic transmission of [organization-defined] to [organization-defined]: [organization-defined]

• The defined out-of-band channels employed and the defined information they carry, such as keys, tokens or credentials
• The defined individuals or systems the information is delivered to
• Procedure showing the out-of-band channel is genuinely separate from the primary channel
• Delivery records for the period, showing recipient verification
• Evidence of what happens when out-of-band delivery fails, and that fallback does not use the primary channel

• Second channel that terminates on the same device, so a compromised endpoint sees both
• Recipient identity not verified before delivery, so the channel is separate but the recipient is unproven
• Fallback on failure quietly reverts to the primary channel, defeating the control

Operations Security. Employ the following operations security controls to protect key organizational information throughout the system development life cycle: [organization-defined]

• The defined operations security controls employed to protect key organisational information across the development life cycle
• Identification of the key information the controls protect, such as architecture, vulnerabilities and plans of action
• Evidence of application at each life cycle stage, including during procurement and disposal
• Assessment of what an observer could infer from publicly available organisational information
• Records where an operations security control changed a disclosure decision

• Controls applied to production information while design and procurement documents naming weaknesses circulate freely
• Job advertisements, supplier lists and conference material disclosing architecture with no operations security review
• Applied at development only, with disposal and decommissioning uncovered

Requires a separate execution domain to be maintained for each executing process, so that one process cannot read or interfere with the memory and execution state of another.

• Documentation of the platform mechanisms providing per process isolation
• Configuration evidence for virtualisation, container or operating system isolation features
• Assessment of shared tenancy risks and the isolation relied upon
• Evidence isolation features remain enabled after platform changes

• Containers on a shared kernel treated as equivalent to full isolation without analysis
• Isolation features disabled for performance and never reinstated
• Legacy applications running privileged so isolation boundaries are moot

Requires the system to prevent unauthorized and unintended transfer of information through shared resources such as memory, storage and caches, so that residual data from one user or process is not exposed to another.

• Design documentation of how shared resources are cleared or partitioned between users
• Configuration evidence for memory and storage sanitisation on release
• Test results showing no residual data is readable by a subsequent process
• Treatment of shared caches and temporary storage in multi tenant components

• Temporary files and caches persist between users on shared systems
• Object storage reused without clearing, exposing previous content
• Shared caches keyed in a way that lets one tenant read another tenant's response

Wireless Link Protection. Protect external and internal [organization-defined] from the following signal parameter attacks: [organization-defined]

• Identification of the external and internal wireless links in scope
• The defined signal parameter attacks the links are protected from, such as jamming, direction finding or exploitation of signal characteristics
• Configuration and design evidence of the protections applied to each link
• Wireless network diagrams showing which links carry the protection
• Test or measurement records confirming the protection performs as intended

• Protection scoped to confidentiality of the payload while the signal parameter attacks the control names are unaddressed
• Internal wireless links excluded on the assumption that the perimeter protects them
• No measurement, so protection against jamming or detection is asserted rather than shown

Port and I/O Device Access. [organization-defined] disable or remove [organization-defined] on the following systems or system components: [organization-defined]

• The defined connection ports or input output devices to be disabled or removed, and the systems or components in scope
• Configuration evidence showing the ports or devices are disabled or physically removed
• Records of any exception, with approval and compensating control
• Verification such as inspection or scan output confirming the state on live systems
• Change control preventing re-enablement without approval

• Ports disabled in the build image while systems in the field, imaged earlier, remain enabled
• Software disablement that a local administrator can reverse, where physical removal was intended
• No verification, so the disabled state is assumed from policy rather than confirmed

Sensor Capability and Data. Prohibit [organization-defined] ; and Provide an explicit indication of sensor use to [organization-defined]

• The defined sensor uses prohibited, such as remote activation or collection in particular facilities
• Configuration or physical measures enforcing the prohibition
• The explicit indication of sensor use provided, with evidence of what an individual actually sees or hears
• Identification of the individuals or groups the indication is provided to
• Records of sensor data collection and its handling where personal data is captured

• Prohibition stated for organisation owned devices while personally owned devices in the same space are unaddressed
• Indicator controlled by the same software that operates the sensor, so it can be suppressed together with it
• Sensor data retained with no handling rules despite capturing individuals

Usage Restrictions. Establish usage restrictions and implementation guidelines for the following system components: [organization-defined] ; and Authorize, monitor, and control the use of such components within the system

• The defined system components subject to usage restrictions, and the restrictions and implementation guidelines established for each
• Authorisation records for use of those components within the system
• Monitoring records showing use is observed against the restrictions
• Evidence of control action taken when unauthorised use was detected
• Review of the restrictions when the component or its risk profile changed

• Restrictions written for a component class with no way to detect which instances are actually in use
• Authorisation granted once with no expiry, so components stay authorised after the need ends
• Monitoring absent, so the authorise, monitor and control triad reduces to authorise alone

Detonation Chambers. Employ a detonation chamber capability within [organization-defined]

• Identification of where the detonation chamber capability is employed, such as at mail or web ingress or in an isolated analysis environment
• Design evidence showing the chamber is isolated from production networks and identity systems
• Configuration showing which content types are detonated and the verdict handling
• Records of detonations performed and malicious verdicts acted on
• Evidence of anti evasion measures, since malware that detects analysis will behave benignly

• Chamber network connected in a way that lets detonated code call out to production or to the identity provider
• Only executable attachments detonated while archives, links and document macros bypass
• Verdicts produced after the content has already been delivered, with no retraction step

System Time Synchronization. Synchronize system clocks within and between systems and system components

• Identification of the authoritative time source and the synchronisation hierarchy for systems and components
• Configuration on representative systems showing the time source in use and the synchronisation interval
• Monitoring evidence of clock offset across the estate, showing drift within an acceptable bound
• Alerting when a system loses synchronisation or drifts beyond tolerance
• Evidence that time on log producing and log receiving systems agrees, since log correlation depends on it

• Servers synchronised while network devices, appliances and containers use their own or the hypervisor clock
• No offset monitoring, so a silently failed time client is invisible until log correlation fails during an investigation
• Different time zones recorded without offset, making cross system sequencing ambiguous

Cross Domain Policy Enforcement. Implement a policy enforcement mechanism [organization-defined] between the physical and/or network interfaces for the connecting security domains

• Identification of the connecting security domains and the interfaces between them
• Design documentation of the policy enforcement mechanism sited between those interfaces
• The policy the mechanism enforces, expressed as permitted data types, directions and transformations
• Evidence no path exists between the domains that bypasses the mechanism
• Assessment or accreditation evidence for the cross domain mechanism itself

• Enforcement mechanism deployed alongside an administrative or backup path that connects the domains directly
• Policy expressed as network rules rather than content rules, so permitted protocols carry unpermitted data
• Mechanism itself never assessed, despite being the single point the separation depends on

Alternate Communications Paths. Establish [organization-defined] for system operations organizational command and control

• The defined alternate communications paths established for system operations command and control
• Evidence the alternate path is physically or logically diverse from the primary, including carrier and route diversity
• Test records of command and control conducted over the alternate path
• Activation procedure naming who switches and under what conditions
• Evidence the alternate path is protected to the same standard as the primary

• Alternate path sharing the same physical duct, provider or exchange as the primary
• Path exists but is never used, so credentials and configurations on it have expired
• Alternate path protected less strongly than the primary, making it the attractive target

Sensor Relocation. Relocate [organization-defined] to [organization-defined] under the following conditions or circumstances: [organization-defined]

• The defined sensors or monitoring capabilities eligible for relocation and the defined locations they may move to
• The defined conditions or circumstances that trigger relocation
• Change control and configuration management records for each relocation performed
• Evidence monitoring coverage was maintained during and after the move
• Rationale showing relocation responds to adversary awareness rather than convenience

• Sensors moved without change records, so the monitoring baseline no longer matches the deployment
• Relocation leaves a coverage gap at the vacated location that nobody assesses
• Trigger conditions undefined, so relocation is ad hoc and predictable

Hardware-enforced Separation and Policy Enforcement. Implement hardware-enforced separation and policy enforcement mechanisms between [organization-defined]

• Identification of the domains or components required to be separated
• Documentation of the hardware mechanism enforcing the separation, such as physical separation, hardware memory protection or dedicated devices
• Evidence the enforcement is in hardware and cannot be reconfigured by software running in either domain
• Policy enforced at the boundary and the interfaces permitted to cross it
• Assessment or test results confirming separation holds under fault and attack conditions

• Virtualisation presented as hardware enforced separation when the hypervisor is software the domains share
• Hardware separation at the data path while a shared management processor spans both domains
• Separation asserted from product marketing with no assessment specific to this deployment

Requires the effects of organization-defined denial of service event types to be protected against or limited, and requires organization-defined controls to be employed to achieve that objective for each event type.

• Documented denial of service event types considered in scope
• Configuration of the protective controls such as rate limiting, filtering or upstream scrubbing
• Capacity and resilience evidence for the protected services
• Test or incident records showing the protection performing under load

• Protection procured for volumetric attacks only, leaving application layer attacks untreated
• Controls in place upstream but the origin remains directly reachable
• Event types never defined, so nothing determines whether protection is adequate

Software-enforced Separation and Policy Enforcement. Implement software-enforced separation and policy enforcement mechanisms between [organization-defined]

• Identification of the domains or components separated by software mechanisms
• Documentation of the software separation mechanism and the privilege level it operates at
• Configuration showing the policy enforced between the domains
• Evidence the mechanism is protected from the domains it separates, including from privileged users within them
• Test results demonstrating the separation and the handling of mechanism failure

• Separation mechanism runs at the same privilege as the workloads, so a compromise of either defeats it
• Patching of the separation mechanism treated as routine, leaving known escape paths open
• Failure behaviour untested, so mechanism failure silently merges the domains

Hardware-based Protection. Employ hardware-based, write-protect for [organization-defined] ; and Implement specific procedures for [organization-defined] to manually disable hardware write-protect for firmware modifications and re-enable the write-protect prior to returning to operational mode

• The defined components carrying hardware based write protection for firmware
• Evidence the write protect is hardware based, such as a jumper, switch or one time programmable setting
• The specific procedures for the defined personnel to manually disable write protect for firmware modification
• Records of each firmware modification showing write protect was disabled, the change made, and protection re-enabled before return to operation
• Verification that write protect is enabled on operational systems

• Write protect left disabled after a firmware update because re-enablement is not a checklist step
• Protection implemented as a software setting the firmware itself can change
• No verification sweep, so a system running unprotected is only found by chance

Resource Availability. Protect the availability of resources by allocating [organization-defined] by [organization-defined]

• The defined resources allocated for protection, such as processing, bandwidth, storage or connection capacity
• The defined allocation method, such as priority, quota or partition, and its configuration
• Evidence the allocation protects availability of the priority workload when the resource is contended
• Monitoring showing resource consumption against the allocations
• Test or incident evidence showing the allocation held under load

• Quotas configured but set above the resource actually available, so they never bind
• Priority defined for production workloads while shared infrastructure such as storage or the control plane has none
• Allocation never tested under contention, so its behaviour under real exhaustion is unknown

Requires communications to be monitored and controlled at external managed interfaces and at key internal interfaces, publicly accessible components to sit in subnetworks physically or logically separated from internal networks, and connections to external networks or systems to pass only through managed interfaces built from boundary protection devices arranged per the security architecture.

• Network architecture diagram identifying external and key internal managed interfaces
• Firewall and gateway rule sets with review records
• Evidence publicly accessible components are separated from internal networks
• Inventory of external connections showing each passes through a managed interface

• Undocumented external connections such as vendor tunnels bypass the managed interfaces
• Internal interfaces unmonitored, so lateral movement is invisible
• Publicly accessible components share a network segment with internal services

Requires the confidentiality or integrity, as the organization determines, of transmitted information to be protected, so that data in transit cannot be read or altered by parties along the path.

• Definition of the transmissions in scope and the protection required for each
• Configuration evidence for transport encryption and its accepted versions and ciphers
• Scan results confirming protection across in scope endpoints
• Treatment of internal service to service traffic as well as external traffic

• External traffic encrypted while internal traffic between services is in the clear
• Deprecated transport versions and weak ciphers left enabled
• Certificate validation disabled in application clients, so encryption gives no assurance of peer identity

Requires a system and information integrity policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved system and information integrity policy with scope, approver and date
• Evidence the system and information integrity policy reached the personnel or roles it defines
• Written designation of the official accountable for the system and information integrity policy and procedures
• Procedures covering flaw remediation, malicious code protection and monitoring
• Review record for the system and information integrity policy and procedures against the defined frequency and triggering events

• Policy sets no patching timeframes, leaving remediation open ended
• Monitoring responsibilities undefined between operations and security
• No review cadence defined for the system and information integrity policy, so it silently ages

Requires the validity of organization-defined information inputs to be checked, so that data entering the system is verified for syntax, type and value before it is processed.

• Documented list of information inputs subject to validation
• Design or code evidence of server side validation rules
• Test results including negative testing with malformed input
• Handling procedure for inputs that fail validation

• Validation implemented in the client only and bypassable by direct requests
• Interfaces and file imports omitted while user forms are validated
• Invalid input rejected without logging, so attack attempts go unseen

Error Handling. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and Reveal error messages only to [organization-defined]

• Documentation of the structure and content of error messages generated by the system
• Evidence error messages carry what is needed for corrective action without revealing exploitable detail such as stack traces, queries or paths
• The defined personnel or roles to whom error messages are revealed, and the configuration enforcing that
• Test evidence showing error output at the user boundary under failure conditions
• Retention and access rules for the detailed error information kept for diagnosis

• Detailed diagnostics shown to end users in non production configuration that is carried into production
• Errors sanitised at the application while the web server, database or framework returns verbose defaults
• Detailed error stores accessible to anyone with log access rather than the defined roles

Requires information held in the system and information produced as output to be managed and retained in line with applicable laws, directives, regulations, policies, standards, guidelines and operational needs, covering how long it is kept and when it is disposed of.

• Retention schedule mapping information types to retention periods and their legal basis
• Configuration or process evidence implementing retention and disposal
• Disposal records for information that reached the end of its retention period
• Coverage evidence for system outputs such as reports, extracts and archives

• Retention defined for records systems while exports, reports and backups are unmanaged
• Data kept indefinitely because deletion is harder than storage
• Legal basis for the retention period never recorded

Predictable Failure Prevention. Determine mean time to failure (MTTF) for the following system components in specific environments of operation: [organization-defined] ; and Provide substitute system components and a means to exchange active and standby

• Determined mean time to failure figures for the defined components in their specific environments of operation
• Source of the figures, whether manufacturer data or observed failure history
• Evidence substitute components are available, and the means to exchange active and standby components
• Records of exchanges performed and the time taken
• Evidence the exchange preserves the security state of the component being replaced

• Manufacturer figures used without adjusting for the actual operating environment, which is what the control asks for
• Substitutes held for common parts while long lead single sourced components have none
• Exchange mechanism untested, so the standby is unproven at the moment it is needed

Non-persistence. Implement non-persistent [organization-defined] that are initiated in a known state and terminated [organization-defined]

• The defined non-persistent components or services, and the defined termination condition or period
• Evidence each is initiated in a known state from a trusted source rather than from its previous state
• Records showing components are actually terminated and refreshed at the defined interval
• Verification that no state persists across the refresh, including credentials, caches and local data
• Rationale linking the refresh period to the dwell time the control aims to limit

• Instances rebuilt from a running image rather than a trusted source, so compromise survives the refresh
• Refresh interval long enough that it has no effect on adversary dwell time
• Persistent volumes, secrets or session stores attached to non-persistent compute, carrying state across

Information Output Filtering. Validate information output from the following software programs and/or applications to ensure that the information is consistent with the expected content: [organization-defined]

• The defined software programs and applications whose output is validated
• Definition of the expected content that output is validated against
• Configuration of the validation mechanism and its behaviour when output does not match
• Records of outputs rejected or flagged during the period
• Evidence validation covers all output paths from the named applications, including files and interfaces as well as screens

• Validation applied to user facing output while machine to machine interfaces from the same application are unchecked
• Expected content defined loosely, so almost any output passes
• Non-conforming output logged and released anyway, so the filter does not filter

Requires organization-defined controls to be implemented to protect system memory from unauthorized code execution, such as platform level execution protection and exploit mitigation features.

• Documented memory protection controls selected for the system
• Configuration evidence that the protections are enabled on in scope components
• Verification output confirming mitigations are active at runtime
• Exception records where a protection had to be disabled, with compensating controls

• Protections available in the platform but disabled for legacy application compatibility
• Controls verified at build and never re-checked after platform updates
• Server and appliance components excluded while workstations are protected

Fail-safe Procedures. Implement the indicated fail-safe procedures when the indicated failures occur: [organization-defined]

• The defined failure conditions and the fail-safe procedure implemented for each
• Design and configuration evidence implementing each fail-safe procedure
• Test records demonstrating the procedure executes on the defined failure
• Evidence the fail-safe state does not itself create exposure, such as an open bypass
• Operator instructions for recovery from the fail-safe state

• Fail-safe procedures documented for hardware failures while security mechanism failures fail open
• Procedures never triggered in test, so their real behaviour is unverified
• Recovery from fail-safe undefined, so operators improvise under pressure and leave the state inconsistent

Personally Identifiable Information Quality Operations. Check the accuracy, relevance, timeliness, and completeness of personally identifiable information across the information life cycle [organization-defined] ; and Correct or delete inaccurate or outdated personally identifiable information

• Records of accuracy, relevance, timeliness and completeness checks on personally identifiable information at the defined frequency
• The checking method and the thresholds or rules applied
• Correction and deletion records for inaccurate or outdated personally identifiable information
• Evidence checks span the information life cycle rather than the point of collection only
• Quality reports showing trend and the action taken on recurring defects

• Validation at entry only, so information that ages out of accuracy is never re-checked
• Corrections applied without propagating to copies and prior recipients
• Checks run and reported with no correction workflow behind them

De-identification. Remove the following elements of personally identifiable information from datasets: [organization-defined] ; and Evaluate [organization-defined] for effectiveness of de-identification

• The defined elements of personally identifiable information removed from datasets, and the de-identification procedure applied
• Sample de-identified datasets alongside the source, showing what was removed or transformed
• The defined evaluation performed for effectiveness of de-identification, and its results
• Assessment of re-identification risk from remaining quasi-identifiers and from linkage with other available data
• Controls over the de-identification keys or mappings where the process is reversible

• Direct identifiers removed while a combination of remaining attributes still singles individuals out
• Effectiveness never evaluated, which is the second half of the control
• Re-identification mapping retained alongside the de-identified data with the same access controls

Requires system flaws to be identified, reported and corrected, updates related to flaw remediation to be tested for effectiveness and side effects before installation, security relevant software and firmware updates to be installed within an organization-defined period of release, and flaw remediation to be run through the configuration management process.

• Defined installation timeframes for security relevant updates by severity
• Patch deployment records measured against those timeframes
• Test evidence for updates before production installation
• Change records showing remediation passed through configuration management
• Exception register for systems that cannot be patched, with compensating controls

• Timeframes defined but routinely missed with no risk acceptance recorded
• Firmware and appliance updates outside the patch process entirely
• Emergency patches installed without testing and without a change record

Tainting. Embed data or capabilities in the following systems or system components to determine if organizational data has been exfiltrated or improperly removed from the organization: [organization-defined]

• The defined systems or components in which tainted data or capabilities are embedded
• Description of the taint used and how it is designed to be indistinguishable from real data
• The detection mechanism that observes taint appearing outside the organisation
• Records of taint detections and the investigations they triggered
• Controls preventing the taint from causing operational harm if acted on as real data

• Taint placed only in the store least likely to be exfiltrated, such as a test database
• Taint distinguishable from real records, so an adversary filters it out
• No monitoring for the taint outside the organisation, so embedding it achieves nothing

Information Refresh. Refresh [organization-defined] at [organization-defined] or generate the information on demand and delete the information when no longer needed

• The defined information subject to refresh and the defined refresh frequency, or the decision to generate on demand
• Configuration evidence implementing the refresh or on demand generation
• Deletion evidence showing the information is removed when no longer needed
• Records showing refresh actually occurred at the stated frequency
• Verification that deleted information is gone from caches, backups and derived stores within the retention rules

• Refresh implemented as an overwrite that leaves prior versions recoverable
• On demand generation adopted while a cached copy persists indefinitely
• Deletion at the primary store only, with the derived and backup copies untouched

Information Diversity. Identify the following alternative sources of information for [organization-defined]: [organization-defined] ; and Use an alternative information source for the execution of essential functions or services on [organization-defined] when the primary source of

• The defined essential functions or services in scope and the alternative information sources identified for each
• Evidence the alternative source is genuinely independent of the primary in origin and supply
• The defined circumstances under which the alternative source is used
• Records of use of an alternative source when the primary was compromised or unavailable
• Assessment of the alternative source's accuracy and timeliness relative to the primary

• Alternative source that ultimately derives from the same upstream provider as the primary
• Alternative identified but never validated, so its quality is unknown at the moment of need
• Switching criteria undefined, so the alternative is adopted late or not at all

Information Fragmentation. Based on [organization-defined]: Fragment the following information: [organization-defined] ; and Distribute the fragmented information across the following systems or system components: [organization-defined]

• The defined circumstances on which fragmentation is based, such as a threat assessment or risk trigger
• The defined information fragmented and the fragmentation method used
• The defined systems or components across which fragments are distributed, with evidence of the actual distribution
• Evidence that no single location holds enough fragments to reconstruct the information
• Reconstitution procedure and evidence it has been tested

• Fragments distributed across systems that share one administrator, one key or one storage platform
• Reconstitution never tested, so availability of the fragmented information is unproven
• Fragmentation applied without an assessment of how many fragments actually reveal the content

Requires malicious code protection mechanisms to be implemented at system entry and exit points, updated automatically as new releases appear under configuration management, configured to scan periodically at a defined frequency and in real time as files arrive from external sources, to take defined action on detection and alert defined personnel, and requires false positives and their operational impact to be addressed.

• Deployment coverage report for malicious code protection across the estate
• Update status showing definitions or engines are current
• Configuration showing scan frequency, real time scanning and the action on detection
• Alert and response records for detections
• Assessment of false positive handling and its operational impact

• Coverage gaps on servers, appliances and unmanaged systems
• Detections logged locally with nobody alerted or responding
• Real time scanning disabled on high load systems without compensating controls

Requires monitoring of the system to detect attacks and attack indicators against defined monitoring objectives, and to detect connections that were not authorized whether local, networked or remote, with unauthorized use identified by defined techniques, monitoring capability placed strategically and at ad hoc points, the monitoring itself protected from tampering, activity heightened on credible threat information, legal review obtained where required, and findings issued to defined personnel at a defined frequency.

• Documented monitoring objectives and the techniques used to identify unauthorized use
• Monitoring architecture showing sensor placement and coverage
• Detection records for unauthorized connections and suspicious activity
• Reports issued to the defined personnel at the defined frequency
• Evidence monitoring components are protected from unauthorized modification

• Monitoring covers the perimeter while internal and remote connection paths are unwatched
• Monitoring objectives never defined, so alerting is driven by vendor defaults
• Monitoring infrastructure itself unprotected, so an attacker can disable it

Requires security alerts, advisories and directives to be received from organization-defined external sources on an ongoing basis, internal alerts to be generated as needed, alerts to be disseminated to defined recipients, and directives to be implemented within the established timeframes or the issuing organization notified of the degree of noncompliance.

• List of external sources subscribed to for alerts, advisories and directives
• Records of internal alerts generated and their distribution
• Tracking of directives received with implementation dates against required timeframes
• Notifications issued where a directive could not be met in full

• Advisories arrive in an individual mailbox with no onward distribution
• No tracking of directive deadlines, so compliance cannot be demonstrated
• Vendor advisories monitored while sector and government sources are not

Security and Privacy Function Verification. Verify the correct operation of [organization-defined]; Perform the verification of the functions specified in SI-6a [organization-defined]; Alert [organization-defined] to failed security and privacy verification tests; and [organization-defined] when anomalies

• The defined security and privacy functions subject to verification
• The defined verification frequency or trigger, such as at startup, on command or periodically
• Verification results for the period, including passes and failures
• Alerting configuration and records showing the defined personnel were alerted on a failed verification
• The defined action taken when verification fails, such as shutdown, restart or notification, with evidence it executed

• Verification covers whether a service is running rather than whether the security function operates correctly
• Failures logged with no alert, so a silently broken control persists
• The defined failure action never exercised, so its effect on availability is unknown and it is disabled in practice

Requires integrity verification tools to be employed to detect unauthorized changes to organization-defined software, firmware and information, and requires organization-defined actions to be taken when such unauthorized changes are detected.

• Defined list of software, firmware and information subject to integrity verification
• Integrity monitoring tool configuration and coverage report
• Alerts generated by integrity checks and the response records
• Documented actions to be taken on detection of unauthorized change

• Integrity monitoring produces constant noise from routine change and is therefore ignored
• Firmware excluded because tooling only covers the operating system layer
• No defined response, so detections are acknowledged and closed without investigation

Spam Protection. Employ spam protection mechanisms at system entry and exit points to detect and act on unsolicited messages; and Update spam protection mechanisms when new releases are available in accordance with organizational configuration

• Identification of the system entry and exit points where spam protection mechanisms are deployed
• Configuration of the mechanisms, including the actions taken on detection such as quarantine, tag or reject
• Evidence protection is applied at exit as well as entry, which the control requires
• Update records showing signature and engine releases applied under the organisational configuration management process
• Detection statistics and records of false positive handling

• Inbound filtering deployed while outbound messaging passes unfiltered, missing compromised account abuse
• Updates applied automatically outside configuration management, so the deployed version is unknown
• No false positive handling route, so users bypass the mechanism with alternative channels

Requires a supply chain risk management policy with supporting procedures to be developed, approved, disseminated to defined personnel, owned by a named official, and reviewed and updated on a defined frequency and after defined events.

• Approved supply chain risk management policy with scope, approver and date
• Evidence the supply chain risk management policy reached the personnel or roles it defines
• Written designation of the official accountable for the supply chain risk management policy and procedures
• Procedures covering supplier assessment, component authenticity and disposal
• Review record for the supply chain risk management policy and procedures against the defined frequency and triggering events

• Policy covers hardware suppliers only and omits software and service dependencies
• Procurement operates without reference to the policy
• No review cadence defined for the supply chain risk management policy, so it silently ages

Requires organization-defined systems or components to be inspected to detect tampering, either at random, at organization-defined frequencies, or upon organization-defined indications that tampering may have occurred.

• Defined inspection scope, trigger conditions and frequency
• Inspection records with findings for each inspection performed
• Tamper evident measures applied to in scope components
• Escalation records where tampering indications were found

• Inspection defined for delivery only and never repeated in service
• Triggers undefined, so indications of tampering do not cause an inspection
• No baseline of expected condition, so tampering cannot be recognised

Requires anti-counterfeit policy and procedures to be developed and put into practice, including how counterfeit components are detected and kept out of the system, and requires any counterfeit component found to be reported to the recipients the organization has defined, such as the supplier it came from or an external reporting body.

• Anti-counterfeit policy and procedures including detection methods
• Evidence of purchasing through authorised distributors or original manufacturers
• Inspection or verification records for received components
• Reporting records where counterfeit components were identified

• Components sourced from secondary markets during shortages with no additional verification
• Detection relies on visual checks alone with no provenance verification
• No reporting path defined, so counterfeits are returned quietly and never reported

Requires organization-defined data, documentation, tools or system components to be disposed of using organization-defined techniques and methods, so that disposal does not release information or usable components to unauthorized parties.

• Defined disposal techniques per item type and classification
• Disposal records including certificates from any third party disposal provider
• Evidence that data and documentation are destroyed as well as hardware
• Verification records confirming disposal was completed as specified

• Hardware disposal managed while documentation and development tooling are not
• Third party disposal used with no certificate or verification obtained
• Disposal method chosen by cost rather than by the classification of what is held

Requires a plan for managing supply chain risk covering the full life of the defined systems, components or services, from research, design and manufacture through purchase, delivery, integration, running and maintenance to disposal, reviewed and updated at a defined frequency or when threats, the organization or the environment change, and protected from unauthorized disclosure or modification.

• Supply chain risk management plan covering the full life cycle stages
• Defined scope of systems, components or services the plan covers
• Review and update history at the defined frequency and after significant change
• Restrictions preventing unauthorized disclosure or alteration of the supply chain risk management plan

• Plan addresses acquisition only and stops at contract signature
• Scope never defined, so it is unclear which components the plan governs
• Plan not updated after major supplier or architecture changes

Requires processes that find and deal with weaknesses in the supply chain elements behind the defined system or component, worked in coordination with the defined supply chain personnel, organization-defined controls to reduce supply chain risk and limit the harm from supply chain events, and documentation of the processes and controls chosen in the security and privacy plans or the supply chain risk management plan.

• Documented process for identifying and addressing supply chain weaknesses
• Record of supply chain controls selected and where they are documented
• Evidence of coordination with the defined supply chain personnel
• Findings from supply chain reviews and the actions taken

• Weaknesses identified in assessment but no controls selected in response
• Supply chain work performed by security with no involvement from procurement or logistics
• Controls chosen but never recorded in the plans, so they are not maintained

Provenance. Document, monitor, and maintain valid provenance of the following systems, system components, and associated data: [organization-defined]

• The defined systems, components and associated data whose provenance is maintained
• Provenance records showing history of ownership, custody, location and changes for each
• Evidence provenance is monitored, not just documented once at acquisition
• The method for validating provenance claims from suppliers
• Records where a provenance discrepancy was identified and investigated

• Provenance captured at purchase and abandoned once the component is in service, missing repairs and replacements
• Supplier assertions accepted with no validation method behind them
• Software and firmware provenance omitted while hardware provenance is tracked

Requires the organization to use defined acquisition strategies, contract tools and procurement methods that reduce supply chain risk, help identify it and mitigate it, so that risk treatment is built into the way things are bought.

• Documented acquisition strategies and procurement methods adopted for supply chain risk
• Contract clause library covering supply chain obligations
• Evidence of the strategies applied in specific acquisitions
• Records of supplier diversity, provenance or blind buying measures where used

• Strategies documented but procurement continues to buy on price and delivery alone
• Supply chain clauses omitted from lower value purchases that still carry risk
• No evidence the strategies were applied to any actual acquisition

Requires assessment and review, at an organization-defined frequency, of the supply chain risk attached to each supplier or contractor and to the particular system, component or service they deliver.

• Supplier assessment records covering the supply chain risks of what is provided
• Defined assessment frequency and evidence reviews occur at that cadence
• Risk ratings and the treatment decisions arising from assessments
• Evidence assessments cover subcontractors and fourth party dependencies where relevant

• Assessment performed at onboarding only with no defined review cadence
• Assessment covers the supplier's corporate posture but not the specific component supplied
• Subcontractors invisible, so the assessed supply chain stops at the first tier

Supply Chain Operations Security. Employ the following Operations Security (OPSEC) controls to protect supply chain-related information for the system, system component, or system service: [organization-defined]

• The defined operations security controls employed to protect supply chain related information
• Identification of the supply chain information being protected, such as supplier identities, quantities, delivery schedules and configurations
• Evidence of application across procurement, logistics and disposal
• Agreements requiring suppliers to apply equivalent protection to the same information
• Assessment of what supply chain information is inferable from public sources

• Protection applied internally while suppliers publish the relationship in case studies and press releases
• Delivery schedules and locations shared over unprotected channels with logistics providers
• Disposal and decommissioning revealing component inventory and configuration

Requires agreements and procedures to be established with entities in the supply chain for notification of supply chain compromises, and of any other organization-defined events such as vulnerabilities or component changes, so the organization learns of them from the supplier rather than after the fact.

• Contract clauses or agreements requiring notification of supply chain compromise
• Documented notification procedures including recipients and expected timeframes
• Records of notifications received and how they were handled
• Register of supply chain entities covered by such agreements

• Notification obligations absent from agreements with smaller or indirect suppliers
• No internal procedure for handling a notification when it arrives
• Notification expected but no timeframe agreed, so disclosure can be indefinitely delayed

Tamper Resistance and Detection. Implement a tamper protection program for the system, system component, or system service

• The tamper protection programme documentation covering the system, component or service
• The anti-tamper measures applied, such as seals, enclosures, cryptographic attestation or packaging controls
• Inspection procedures and records showing tamper indicators are actually checked on receipt and in service
• Records of tamper indications found and the response taken
• Coverage across the life cycle including transit, storage, maintenance and return

• Tamper evident seals applied but never inspected, so evidence of tampering is collected and ignored
• Programme covers delivery while maintenance returns and warranty exchanges bypass it
• No defined response to a tamper indication, so a found seal breach is rationalised away

The organization manages account types, access enforcement, separation of duties, least privilege, unsuccessful logon attempts, system use notification, session management, remote access, and wireless access controls.

• Access control policy and procedures
• Account inventory by type with review records
• Role-based access matrices
• Least privilege analyses
• Remote access architecture diagrams

• Privileged accounts unreviewed
• Service accounts unmanaged
• Separation of duties not enforced in code
• Remote access without MFA for privileged users

Systems generate audit records for defined events, with content sufficient to support investigation, with protection of audit information and review and reporting on audit findings.

• Audit policy and event list
• Centralized log management evidence (SIEM)
• Log retention schedule
• Audit review and analysis procedures
• Time synchronization configuration

• Inconsistent event coverage across systems
• Logs not protected from tampering
• Retention shorter than incident discovery window
• Review not performed or not documented

Users and devices are uniquely identified and authenticated using mechanisms appropriate to assurance levels, with management of authenticators and identity proofing.

• Identity proofing records aligned to NIST SP 800-63A
• MFA enforcement evidence per system
• Authenticator management procedures
• Device authentication configurations
• Federation agreements

• MFA not enforced for all privileged paths
• Identity proofing weak for remote onboarding
• Shared accounts in use
• Federation trust not periodically reviewed

The organization protects communications and applies cryptographic protections, boundary protections, denial of service mitigation, and resource availability mechanisms.

• Network architecture with boundary protections
• Cryptographic standards documentation aligned with FIPS 140-3
• TLS configuration scans
• DDoS protection records
• Key management procedures

• Internal segmentation flat
• Weak cipher suites not retired
• DDoS protection not tested
• Keys not rotated on schedule

The organization identifies, reports, and corrects information system flaws, provides malicious code protection, monitors systems, and protects information from unauthorized modification.

• Patch management records with SLAs
• Endpoint protection deployment evidence
• Intrusion detection logs
• Spam and email filtering metrics
• Memory protection configurations

• Patching SLAs missed on high severity items
• Endpoint protection coverage gaps
• Detection signatures stale
• Information input validation absent