NIST Cybersecurity Framework 2.0

Potentially adverse events are analyzed to better understand associated activities. Control from NIST Cybersecurity Framework 2.0 framework, domain: DE - Detect.

• SIEM correlation rule library with detection logic versioning
• Adverse event triage runbook with severity scoring criteria
• Analyst case notes documenting activity reconstruction
• Threat hunting reports tied to correlated events
• MITRE ATT&CK technique mapping for detected behaviors

• Correlation rules tuned only for known IOC patterns, missing behavioral chains
• No documented hypothesis when escalating events to incidents
• Analyst notes stored in chat threads rather than the case system
• ATT&CK mapping inconsistent across analysts

Information is correlated from multiple sources. Control from NIST Cybersecurity Framework 2.0 framework, domain: DE - Detect.

• Log source inventory with coverage matrix against asset register
• Data normalization schema for SIEM ingest pipelines
• Cross-source correlation queries (network, endpoint, identity, cloud)
• SOAR playbooks that enrich events with threat intelligence
• Sample correlated alert with multi-source citation trail

• SaaS and PaaS logs not piped to the SIEM
• Timestamp skew across sources defeats correlation joins
• Identity provider logs not joined to endpoint telemetry
• Enrichment relies on stale threat feeds

The estimated impact and scope of adverse events are understood

• Impact scoring rubric tied to business service catalog
• Blast radius assessment template populated for recent events
• Service dependency map referenced during triage
• Data classification overlay used to estimate exposure
• Severity decision log with assessor identity and timestamp

• Impact estimates not linked to the service catalog
• No method to estimate scope when telemetry is partial
• Data classification missing on cloud storage assets
• Severity overridden without rationale captured

Information on adverse events is provided to authorized staff and tools

• Notification matrix mapping event severity to recipient roles
• Ticketing workflow with mandatory acknowledgement step
• On-call rotation roster with paging path tested quarterly
• Distribution list governance with review log
• Sample notification trace from event detection to receipt

• Recipients lists outdated when staff change roles
• Pager fatigue causes acknowledgement timeouts
• Critical vendors not in notification matrix
• No closed loop confirming receipt by named individual

Cyber threat intelligence and other contextual information are integrated into the analysis

• Threat intelligence platform integration with SIEM
• Indicator lifecycle policy with expiry and tiering
• Analyst pivot guide combining CTI with internal context
• Subscription roster with feed quality scoring
• Quarterly CTI value assessment report

• CTI feeds duplicated rather than deduplicated
• No mapping of CTI to crown jewel assets
• Stale indicators inflate false positive rate
• Intel only consumed in SOC, not informing IR or risk

Incidents are declared when adverse events meet the defined incident criteria

• Incident declaration criteria document with examples
• Triage decision tree from event to incident
• Declared incident log with criteria citation
• Tabletop exercise demonstrating declaration thresholds
• Post-incident review on declaration timing

• Criteria framed in security jargon, not business outcomes
• Analysts hesitant to declare due to escalation overhead
• No retro on declarations that should have been earlier
• Criteria not refreshed after major architecture changes

Networks and network services are monitored to find potentially adverse events. Control from NIST Cybersecurity Framework 2.0 framework, domain: DE - Detect.

• Network flow telemetry coverage map by segment
• IDS or NDR sensor inventory with placement diagram
• DNS query analytics pipeline configuration
• East-west traffic monitoring sample alerts
• Egress monitoring policy and exception register

• Encrypted traffic not inspected at chokepoints
• Container and service mesh traffic invisible
• Egress rules logged but not alerted on
• DNS sinkhole only covers known bad domains

The physical environment is monitored to find potentially adverse events. Control from NIST Cybersecurity Framework 2.0 framework, domain: DE - Detect.

• Physical access logs integrated with security operations
• CCTV coverage map with retention policy
• Environmental sensor telemetry feed (door, temperature, motion)
• Tailgating detection review records
• Visitor management system reports with anomaly flags

• Physical and logical SOCs operate in silos
• Co-location facilities outside the monitoring scope
• CCTV retention shorter than incident discovery windows
• Sensor alerts not joined to identity context

Personnel activity and technology usage are monitored to find potentially adverse events. Control from NIST Cybersecurity Framework 2.0 framework, domain: DE - Detect.

• User and entity behavior analytics deployment scope
• Insider risk indicator catalog with thresholds
• DLP policy library with detection telemetry
• Privileged session recording configuration
• Acceptable use monitoring notice and acknowledgement records

• Behavior baselines stale after org changes
• DLP only covers email, not cloud sharing
• Privileged sessions recorded but not reviewed
• Workforce notice not refreshed for new monitoring tools

External service provider activities and services are monitored to find potentially adverse events

• Vendor monitoring agreement with telemetry obligations
• Third party access logging configuration
• Continuous control monitoring reports from MSP
• Vendor risk dashboard with anomaly indicators
• Joint monitoring runbook with named contacts

• Vendor logs not ingested into the central SIEM
• Privileged third party access not separately tagged
• No alerting on vendor anomalies, only periodic review
• Contract clauses not enforced when telemetry stops

Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events

• EDR coverage report by asset class
• File integrity monitoring baseline and drift alerts
• Software inventory reconciliation with allowlist
• Hardware tamper detection telemetry
• Patch and configuration drift dashboard

• EDR exclusions accumulate without review
• FIM only on a subset of critical systems
• Ephemeral workloads outside the monitoring scope
• Drift alerts tuned out due to false positive volume

The organizational mission is understood and informs cybersecurity risk management

• Cybersecurity mission statement endorsed by leadership
• Business context analysis tying cyber program to strategy
• Stakeholder map for cybersecurity governance
• Organizational chart showing security accountability
• Annual context review minutes

• Context document predates major business changes
• Cybersecurity mission not referenced in strategy decks
• Subsidiaries outside the stated scope
• No record of board endorsement

Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered

• Stakeholder register with cybersecurity interests captured
• Internal and external stakeholder communication plan
• Workshop notes from stakeholder discovery sessions
• Regulator and customer engagement log
• Board reporting cadence for cyber matters

• Customers as stakeholders not represented
• Stakeholder needs never re-validated
• Regulators only contacted in incidents
• Internal audit not in the stakeholder map

Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and managed

• Legal and regulatory obligations register with owners
• Contractual security clauses summary across customer base
• Compliance calendar tracking filings and attestations
• Counsel sign off on obligations interpretation
• Change log when new obligations are added

• Register not maintained when laws change
• Customer contracts not parsed for security clauses
• Cross border data flows missing from the register
• No owner assigned to emerging regulations

Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated

• Critical service catalog with objectives and tolerances
• Business impact analysis aligned to critical objectives
• Capability map linking security to mission outcomes
• RTO and RPO commitments per critical service
• Annual critical service review minutes

• BIA outputs not referenced in security investment
• Critical services list inconsistent across teams
• Tolerances expressed in IT terms, not customer outcomes
• Service catalog and CMDB diverge

Outcomes, capabilities, and services that the organization depends on are understood and communicated

• Dependency map covering people, process, technology, suppliers
• Outcome statements for each critical service
• Resilience scenarios spanning interdependencies
• Supplier dependency overlay on the service map
• Annual dependency walkthrough records

• Dependency map limited to internal systems
• Fourth party dependencies invisible
• Outcomes stated for IT, not for the customer
• Scenarios assume single point failures only

Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced

• Cybersecurity risk management policy approved by leadership
• Policy linkage matrix to standards and procedures
• Risk based rationale documented for policy positions
• Policy distribution and acknowledgement records
• Policy exceptions register with approver identities

• Policy boilerplate not tailored to context
• Standards drift from the parent policy
• Acknowledgement coverage gaps for contractors
• Exceptions granted with no expiry

Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission

• Policy review schedule with last and next review dates
• Change log per policy with rationale and approver
• Communication plan for policy updates
• Enforcement evidence (audit findings, disciplinary records redacted)
• Annual policy effectiveness review report

• Reviews slip beyond declared cadence
• Updates not communicated to all populations
• No metrics on enforcement outcomes
• Effectiveness review treated as a tick box

Risk management objectives are established and agreed to by organizational stakeholders

• Risk management charter with objectives and KPIs
• Board approved risk objectives statement
• Mapping of cyber objectives to enterprise objectives
• Risk committee terms of reference
• Annual objectives attestation

• Objectives generic and not measurable
• No mapping to enterprise strategy
• Charter not refreshed after restructures
• Committee minutes lack decision records

Risk appetite and risk tolerance statements are established, communicated, and maintained

• Risk appetite statement signed by the board
• Tolerance thresholds expressed quantitatively where feasible
• Cascade of appetite into operational limits
• Breach handling procedure for appetite excursions
• Annual appetite review minutes

• Appetite stated qualitatively only
• Operational limits not aligned to appetite
• Breaches not surfaced to the board
• No appetite for emerging threats

Cybersecurity risk management activities and outcomes are included in enterprise risk management processes

• ERM framework with cyber risk integrated
• Risk taxonomy shared across enterprise and cyber registers
• Cross register reconciliation reports
• Joint risk committee meeting records
• Combined risk reporting pack for the board

• Cyber register siloed from enterprise register
• Different scoring scales prevent comparison
• Reconciliation manual and infrequent
• Combined reporting summarized to invisibility

Strategic direction that describes appropriate risk response options is established and communicated

• Cybersecurity strategy document with three to five year horizon
• Roadmap aligned to strategic pillars and resourcing
• Strategy approval record from executive leadership
• Annual strategy review and refresh records
• Strategy traceability matrix to investments

• Strategy reads as a backlog rather than direction
• Roadmap unfunded beyond year one
• No traceability from strategy to capability outcomes
• Strategy refreshed only when leadership changes

Lines of communication across the organization are established for cybersecurity risks, including risks from suppliers and other third parties

• Communication plan for cyber risk across stakeholder tiers
• Reporting templates tailored by audience
• Escalation pathway from analyst to board
• Feedback loop records on report usefulness
• Sample board report with decision asks

• Same report sent to every audience
• Escalation only triggered by incidents
• Feedback never incorporated
• Reports lack a decision request

A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated

• Documented risk calculation methodology
• Calibration sessions for likelihood and impact estimates
• Worked examples applied to recent risks
• Methodology peer review notes
• Tooling configuration enforcing the method

• Method exists on paper, not in tooling
• Estimators not calibrated
• Methodology bypassed for time pressure risks
• No peer review of high impact assessments

Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions

• Risk assessment outputs tagged for improvement opportunities
• Improvement backlog seeded from assessments
• Closure tracking from finding to remediation
• Trend analysis on recurring assessment themes
• Annual improvement review by the risk committee

• Findings closed without verifying remediation
• No trending across assessment cycles
• Improvements stuck in backlog beyond SLA
• Committee not informed of recurrence

Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving

• Board cyber accountability charter
• Executive cyber scorecard with named owners
• Leadership performance objectives tied to cyber outcomes
• Minutes showing leadership challenge of cyber decisions
• Public statement of leadership accountability

• Accountability assigned to CISO only
• Board lacks cyber literacy training
• Performance objectives lack measurable cyber criteria
• No leadership challenge captured in minutes

Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced

• RACI matrix across cyber roles
• Job descriptions with cyber duties for non security roles
• Delegations of authority for security decisions
• Annual role review minutes
• Onboarding pack confirming role responsibilities

• RACI exists but not enforced
• Cyber duties missing from line manager roles
• Delegations stale after reorganizations
• Onboarding pack out of date

Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies

• Cyber budget with multi year planning
• Headcount plan tied to capability roadmap
• Tool spend reconciliation against outcomes
• Investment business cases approved by finance
• Resource constraint risks recorded in the register

• Budget tracked but capability outcomes unclear
• Headcount frozen while scope expands
• Tool spend not retired when consolidating
• Constraint risks not visible to leadership

Cybersecurity is included in human resources practices. Control from NIST Cybersecurity Framework 2.0 framework, domain: GV - Govern.

• HR policies covering hiring, transfer, and termination security
• Background screening standards by role sensitivity
• Disciplinary procedure for security violations
• Joiner mover leaver workflow with security gates
• HR audit findings on security integration

• Background screening not refreshed for role changes
• Leaver process delayed beyond same day for cloud assets
• Disciplinary outcomes not measured
• Contractor lifecycle ignored

A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders

• Third party risk management program charter
• Supplier risk policy with tiering criteria
• Program governance committee minutes
• Annual TPRM maturity assessment
• Tooling inventory supporting TPRM workflow

• Program exists for direct suppliers only
• Tiering criteria not enforced consistently
• Maturity self assessed without independent challenge
• Tooling fragmented across business units

Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally

• Supplier security roles and responsibilities matrix
• Vendor management organization chart with cyber liaison
• Internal owners assigned per critical supplier
• Joint operating model documentation
• Annual review of supplier accountability

• No internal owner for critical suppliers
• Liaison role unfilled during turnover
• Joint operating model exists only for top tier
• Annual review not performed

Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes

• Supply chain risks recorded in the enterprise register
• Combined risk reporting incorporating supplier risk
• Reconciliation between TPRM and enterprise risk teams
• Joint scenario planning exercises
• Board reporting on supply chain exposure

• TPRM operates as a separate silo
• Risk taxonomy differs from enterprise
• Board only sees supplier risk after incidents
• Scenarios omit cascading vendor failures

Suppliers are known and prioritized by criticality. Control from NIST Cybersecurity Framework 2.0 framework, domain: GV - Govern.

• Supplier inventory with criticality scoring
• Crown jewel mapping to supplier dependencies
• Concentration risk analysis by service
• Quarterly tiering refresh records
• Supplier exit plan summary for top tier

• Inventory limited to procurement records
• Shadow IT vendors not captured
• Concentration risk underestimated
• Exit plans absent for critical vendors

Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties

• Standard supplier security requirements catalog
• Contract clause library with cyber obligations
• Requirements tailoring guide by supplier tier
• Negotiation log capturing accepted deviations
• Contract management workflow with security review gate

• Requirements not enforced in long term contracts
• Deviations approved without risk acceptance
• Clauses lack audit and notification provisions
• Renewals not re assessed against current standard

Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships

• Due diligence questionnaire with risk based depth
• Pre contract security assessment reports
• Independent attestations collected during diligence
• Risk acceptance decisions tied to diligence outputs
• Onboarding checklist closing residual gaps

• Diligence skipped for urgent procurement
• Attestations accepted without scope verification
• Risk acceptance not signed at appropriate level
• Onboarding gaps never closed

The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship

• Continuous monitoring evidence for critical suppliers
• Periodic reassessment schedule and completion records
• Threat intelligence on supplier ecosystem
• Performance review minutes with security topics
• Findings remediation tracker per supplier

• Continuous monitoring only via marketing dashboards
• Reassessments slip beyond cycle
• Findings never closed
• Performance reviews skip security topics

Relevant suppliers and other third parties are included in incident planning, response, and recovery activities

• Joint incident response playbooks with key suppliers
• Contact directory tested through tabletop exercises
• Notification clauses in contracts with timelines
• Joint tabletop exercise after action reports
• Lessons learned shared with procurement and legal

• No supplier participation in tabletops
• Notification clauses lack timelines
• Contacts stale at the supplier
• Lessons learned not flowing back to contracts

Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle

• Secure development and operations standards extended to suppliers
• Software bill of materials policy and evidence
• Code provenance verification records
• Build pipeline integrity attestations
• Sourcing controls for hardware components

• SBOM collection inconsistent
• Provenance verification absent for open source
• Hardware sourcing not vetted for tamper risk
• Pipeline integrity assumed rather than tested

Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement

• Supplier offboarding checklist with data return and destruction
• Acquisition integration runbook with cyber gates
• Termination notification workflow
• Asset return tracking for departing suppliers
• Post acquisition cyber assessment reports

• Offboarding focuses on logical access only
• Data return certificates not collected
• Acquired entities granted full access immediately
• Post acquisition findings never closed

Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction

• Strategy review meeting cadence and minutes
• KPI/KRI dashboard tied to strategic objectives
• Adjustments documented after strategy reviews
• Annual cyber strategy refresh record
• Action items from prior reviews and their closure status
• Comparison of strategy targets vs. actual outcomes

• Strategy reviews are perfunctory with no resulting adjustments
• KPIs defined but not reviewed at the strategic level
• Action items raised in reviews never tracked to closure
• Strategy updates not linked to outcome data
• Review cadence absent or longer than annual

The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks

• Coverage assessment comparing strategy against requirements and risks
• Gap analysis output with remediation plans
• Strategy adjustment records and approval
• Mapping of risk register categories to strategy elements
• Internal audit reports addressing strategy coverage
• Executive briefings on coverage status

• Strategy never explicitly mapped against the risk register
• Emerging risks (AI, supply chain) not covered by current strategy
• Gap analyses produced but not acted upon
• Coverage assessments rely only on internal viewpoints
• Adjustments approved verbally with no audit trail

Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed

• Performance metrics catalog with targets and actuals
• Internal audit reports on cyber program performance
• Continuous improvement backlog with prioritized items
• Maturity assessment results (e.g., CSF tier ratings)
• Lessons learned from incidents driving performance adjustments
• Executive scorecard tracking program performance over time

• Metrics measure activity (patches applied) rather than outcomes (risk reduced)
• Internal audit cycles too infrequent to influence direction
• Improvement backlog grows but nothing closes
• Maturity assessments performed but never compared year-over-year
• No formal channel from lessons learned to strategy

Inventories of hardware managed by the organization are maintained. Control from NIST Cybersecurity Framework 2.0 framework, domain: ID - Identify.

• Hardware inventory with last seen and owner fields
• Automated discovery feeds reconciled against CMDB
• Onboarding and decommissioning workflows
• Asset tagging policy and audit findings
• Quarterly inventory completeness report

• OT and IoT assets missing from inventory
• Owner field defaults to a generic team
• Discovery overlaps cause duplicates
• Decommission status untracked

Inventories of software, services, and systems managed by the organization are maintained. Control from NIST Cybersecurity Framework 2.0 framework, domain: ID - Identify.

• Software inventory with licensing and version data
• SaaS application register with owner and data class
• Allowlist and denylist with review cadence
• Discovery feed from endpoint and network tools
• Quarterly software lifecycle review

• Shadow SaaS not captured
• Allowlist drift over time
• Versioning unreliable for plugins
• Lifecycle review not performed

Representations of the organization's authorized network communication and internal and external network data flows are maintained

• Network diagrams with current data flow annotations
• Authorized communication matrix with allowed protocols
• Data flow diagrams covering regulated data
• Firewall rule base traceable to authorized flows
• Annual flow validation walkthrough records

• Diagrams outdated after migrations
• Cloud and partner flows missing
• Firewall rules outlive their justification
• No flow validation performed

Inventories of services provided by suppliers are maintained. Control from NIST Cybersecurity Framework 2.0 framework, domain: ID - Identify.

• Inventory of services delivered by suppliers
• Mapping of supplier services to business services
• Service criticality scores
• Renewal and end of life tracking
• Service ownership matrix

• Inventory derived from procurement records only
• Mapping to business services missing
• End of life dates not tracked
• Ownership unclear for shared services

Assets are prioritized based on classification, criticality, resources, and impact on the mission

• Asset prioritization scoring model
• Criticality ratings stored in CMDB
• Resource allocation justification per tier
• Impact based exception register
• Annual prioritization review minutes

• Scoring inconsistent across teams
• Critical assets identified informally
• Resource allocation not aligned to tier
• Annual review skipped

Inventories of data and corresponding metadata for designated data types are maintained

• Data inventory with classification and location
• Metadata tagging policy enforced in storage
• Records of processing activities updated routinely
• Discovery scans for unstructured data
• Annual data inventory attestation

• Unstructured stores omitted from inventory
• Tagging inconsistent across regions
• ROPA outdated
• Discovery scans limited to sanctioned platforms

Systems, hardware, software, services, and data are managed throughout their life cycles

• Asset lifecycle policy from acquisition to disposal
• Stage gates for build, run, retire
• Secure disposal records with chain of custody
• Lifecycle dashboard with stage age metrics
• Lifecycle audit findings and remediation

• Retired assets remain reachable
• Disposal certificates incomplete
• Stage gates skipped for fast track projects
• Dashboard not used by operations

Improvements are identified from evaluations

• Penetration test report library with severity and status
• Red team exercise after action reviews
• Tabletop output catalogued with improvement actions
• Improvement backlog with owners and due dates
• Trend analysis across testing programs

• Improvements actioned only after the next test
• Tabletop outputs lost in chat logs
• Trend analysis not performed
• Tests scoped to easy wins

Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties

• Risk and control assessment findings tracker
• Internal audit cyber findings with management responses
• External assessment reports with action plans
• Closure verification evidence per finding
• Trend report across assessment cycles

• Closure declared without retest
• Findings aggregated and forgotten
• Management responses lack measurable actions
• Trends not surfaced to leadership

Improvements are identified from execution of operational processes, procedures, and activities

• Operations metrics dashboard with anomaly indicators
• Incident lessons learned register
• Near miss reporting workflow
• Process improvement initiatives tied to operations data
• Quarterly improvement retro records

• Lessons learned never close out
• Near misses not reported because no impact occurred
• Improvement initiatives lose momentum
• Retros skipped during busy periods

Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved

• Incident response plan with version history
• Business continuity and disaster recovery plans linked to IR
• Communications plan for incidents
• Plan approval records from leadership
• Annual plan test results

• Plans inconsistent across business units
• IR and BC plans not aligned
• Approval expired
• Tests narrow in scope

Vulnerabilities in assets are identified, validated, and recorded. Control from NIST Cybersecurity Framework 2.0 framework, domain: ID - Identify.

• Vulnerability scanning coverage report
• Vulnerability triage workflow with severity SLAs
• Validated findings with proof and remediation status
• Asset coverage exceptions register
• Trend analysis on vulnerability backlog

• Coverage gaps for cloud and container workloads
• SLAs missed for high severity items
• Findings closed without re scan
• Trend backlog growing over time

Cyber threat intelligence is received from information sharing forums and sources

• Threat intelligence subscriptions and ISAC memberships
• Intelligence ingestion workflow with curation
• Intelligence consumption metrics by team
• Strategic threat briefings to leadership
• Annual intel program effectiveness review

• Information sharing one way only
• Curation lacks analyst time
• Briefings recycled without refresh
• Effectiveness review skipped

Internal and external threats to the organization are identified and recorded

• Threat catalog with internal and external sources
• Insider threat assessment findings
• Geopolitical threat watch reports
• Threat modeling outputs for critical systems
• Periodic threat refresh meeting minutes

• Insider threat scope limited to malicious cases
• Geopolitical analysis absent
• Threat modeling done once at design only
• Refresh cadence inconsistent

Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded

• Risk scenario library with impact and likelihood scores
• Scenario simulation outputs and decisions
• Quantitative loss exposure analyses where applicable
• Cross functional risk workshop notes
• Validation of scenarios by independent reviewers

• Scenarios limited to known historical events
• Likelihoods estimated without calibration
• Workshops dominated by single perspective
• Validation skipped

Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization

• Inherent risk register with scoring rationale
• Risk heat map and prioritization output
• Linkage from inherent to residual risk
• Methodology document shared across teams
• Annual register attestation

• Inherent risk inflated to justify spending
• Heat map static between reviews
• Residual calculation opaque
• Methodology applied inconsistently

Risk responses are chosen, prioritized, planned, tracked, and communicated. Control from NIST Cybersecurity Framework 2.0 framework, domain: ID - Identify.

• Risk treatment plan per risk
• Approval records for risk acceptance
• Tracking dashboard for treatment progress
• Communication to stakeholders on chosen responses
• Periodic re evaluation of treatment effectiveness

• Treatments default to acceptance
• Acceptance approvals not at appropriate level
• Dashboard tracks tasks, not outcomes
• Re evaluation skipped

Changes and exceptions are managed, assessed for risk impact, recorded, and tracked. Control from NIST Cybersecurity Framework 2.0 framework, domain: ID - Identify.

• Change management workflow with risk assessment gate
• Exception register with risk impact analysis
• Emergency change reviews and post change validation
• Risk impact decisions logged with approver identity
• Audit findings on change risk integration

• Emergency changes bypass risk review
• Exceptions accumulate without sunset
• Validation absent for high risk changes
• Approver identity captured but not verified

Processes for receiving, analyzing, and responding to vulnerability disclosures are established

• Control effectiveness testing reports
• Key risk indicator trending with thresholds
• Risk response effectiveness review minutes
• Independent validation of high risk responses
• Closure tracking when responses fail

• Control testing infrequent
• KRIs flat with no investigation
• Effectiveness reviews narrative only
• Independent validation absent

The authenticity and integrity of hardware and software are assessed prior to acquisition and use

• Quality assurance procedure for risk assessments
• Peer review records on assessment outputs
• Source citation requirements for risk inputs
• Audit trail of changes to risk records
• Independent validation of high impact assessments

• Peer review absent for time pressured assessments
• Sources not cited for risk inputs
• Audit trail incomplete
• Validation overridden by leadership

Critical suppliers are assessed prior to acquisition

• Critical supplier risk assessment reports
• Supplier risk register with scoring
• Continuous monitoring summaries for top tier suppliers
• Risk acceptance decisions for supplier residual risk
• Annual critical supplier risk review

• Critical suppliers defined by spend, not risk
• Assessments rely on supplier self attestation
• Continuous monitoring superficial
• Acceptance decisions not refreshed

Identities and credentials for authorized users, services, and hardware are managed by the organization

• Identity management platform configuration baseline
• Joiner mover leaver workflow with timing SLAs
• Service account inventory with owners
• Hardware credential inventory and reconciliation
• Quarterly identity hygiene reports

• Service accounts owned by individuals who have left
• Hardware credentials manual and stale
• JML SLAs missed for non production systems
• Inventory misses contractor identities

Identities are proofed and bound to credentials based on the context of interactions. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Identity proofing policy aligned to risk tiers
• Issuance and binding records for credentials
• Re proofing triggers for elevated access
• Identity verification audit logs
• Exception register for proofing variances

• Proofing relies on email only
• Binding records incomplete
• Re proofing never triggered
• Exceptions never reviewed

Users, services, and hardware are authenticated. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Multi factor authentication coverage report
• Phishing resistant authentication rollout plan
• Authentication failure analytics
• Workload identity authentication policy
• Periodic authentication strength review

• MFA fatigue not addressed
• Legacy protocols still enabled
• Workload identities use static secrets
• Failure analytics not investigated

Identity assertions are protected, conveyed, and verified. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Token and assertion configuration standards
• Federation trust relationships inventory
• Token signing key management procedures
• Assertion validation telemetry
• Federation incident response plan

• Token lifetimes too long for sensitive apps
• Federation trust list not reviewed
• Signing keys rotated only on incident
• Assertion validation telemetry not monitored

Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties

• Access policy framework with role definitions
• Privileged access management deployment evidence
• Periodic access reviews with sign off
• Segregation of duties matrix
• Just in time access workflow records

• Standing privileges still common
• Access reviews rubber stamped
• SoD conflicts unresolved
• JIT scoped to operations only

Physical access to assets is managed, monitored, and enforced commensurate with risk

• Physical access control system inventory
• Badge issuance and revocation records
• Visitor management policy and logs
• Anti tailgating measures with effectiveness review
• Sensitive area access audit reports

• Badge revocation lags terminations
• Visitor escorts not enforced
• Tailgating measures not tested
• Audits skipped for low traffic areas

Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind

• Security awareness program curriculum
• Completion records by population
• Phishing simulation results and trends
• Awareness campaign artefacts (posters, emails)
• Annual program effectiveness review

• Annual training only with no reinforcement
• Phishing simulations easy and not realistic
• Contractors excluded from awareness
• Effectiveness measured by completion rate only

Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind

• Role based training matrix for security sensitive roles
• Specialized course completion records
• Skills assessments tied to role requirements
• Continuous learning budget records
• Certification tracking for security staff

• Role based training delayed for new hires
• Skills assessments absent
• Certification lapses untracked
• Specialized training reserved for security team only

The confidentiality, integrity, and availability of data-at-rest are protected. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Data at rest encryption inventory by store type
• Key management standards and rotation evidence
• Storage configuration baselines with attestation
• Sensitive data discovery findings remediated
• Audit findings on data at rest protection

• Encryption inventory misses backup media
• Key rotation manual and missed
• Baselines drift in cloud projects
• Sensitive data outside sanctioned stores

The confidentiality, integrity, and availability of data-in-transit are protected. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• TLS configuration standards and scan results
• VPN and zero trust network access policy
• Email transport encryption configuration
• API security policy with mutual authentication
• Network traffic encryption audit

• Weak ciphers still permitted for legacy clients
• Internal traffic unencrypted
• API mutual authentication absent
• Email encryption opportunistic only

The confidentiality, integrity, and availability of data-in-use are protected. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Memory protection technology deployment evidence
• Confidential computing usage for regulated data
• Application level protections for data in use
• Tokenization and masking standards
• Audit on data in use exposure during processing

• Data in use unprotected during analytics
• Confidential computing pilot only
• Masking absent in non production environments
• Memory protection disabled for compatibility

Backups of data are created, protected, maintained, and tested. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Backup policy with frequency and retention
• Backup integrity test reports
• Immutable backup configuration evidence
• Restoration test records with success criteria
• Backup access control and audit logs

• Restoration tests narrow in scope
• Immutability not configured on all critical systems
• Backups exposed via shared admin credentials
• Retention not aligned to recovery objectives

Networks and environments are protected from unauthorized logical access and usage

• Network segmentation design with zones and trust levels
• Firewall and access control list governance
• Zero trust network access deployment evidence
• External attack surface management reports
• Segmentation effectiveness testing results

• Segmentation flat across business units
• Firewall rules grow without rationalization
• Attack surface assets unknown
• Effectiveness testing never performed

The organization's technology assets are protected from environmental threats. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Environmental controls inventory (HVAC, power, fire)
• Site risk assessments with mitigation status
• Cloud region selection rationale for resilience
• Building maintenance and inspection records
• Environmental incident response procedures

• Single region deployments for critical services
• Site risk assessments stale
• Building inspections lapsed
• Environmental incidents not exercised

Mechanisms are implemented to achieve resilience requirements in normal and adverse situations. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Resilience architecture patterns for critical services
• Failover and failback tested with evidence
• Capacity planning and load testing reports
• Chaos engineering exercise outcomes
• Resilience targets traced to business outcomes

• Failback never tested
• Resilience patterns inconsistent across teams
• Chaos engineering absent in production
• Targets not refreshed against business change

Adequate resource capacity to ensure availability is maintained. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Capacity forecasts with growth assumptions
• Performance monitoring telemetry
• Scaling automation configuration evidence
• Reserved capacity and burst contract records
• Availability SLO and error budget reports

• Forecasts not refreshed with demand spikes
• Scaling automation untested under load
• Reserved capacity contracts expired
• SLOs lack error budget enforcement

Configuration management practices are established and applied. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Configuration management standards by platform
• Hardening baselines and compliance reports
• Configuration drift monitoring telemetry
• Approved change management records
• Configuration audit findings and remediation

• Baselines absent for cloud native services
• Drift monitoring noisy and ignored
• Hardening exceptions accumulate
• Audit findings linger past SLA

Software is maintained, replaced, and removed commensurate with risk. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Software lifecycle policy with end of support tracking
• Patch management cadence and exception register
• End of life replacement plan
• Software risk assessments for unsupported tools
• Software retirement records

• EOL software in production beyond plan
• Patch SLAs missed for embedded systems
• Replacement plans unfunded
• Retirement records incomplete

Hardware is maintained, replaced, and removed commensurate with risk. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Hardware lifecycle policy
• Firmware patch management workflow
• Asset refresh schedule
• End of life decommissioning records
• Hardware risk register

• Firmware patching neglected
• Refresh schedule slipping
• Decommissioning ad hoc
• Risk register lacks hardware entries

Log records are generated and made available for continuous monitoring. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

• Logging policy by data class and system tier
• Centralized log collection architecture
• Log retention configuration evidence
• Log integrity protections and audit findings
• Periodic logging coverage review

• Critical systems missing from log feed
• Retention shorter than incident windows
• Log integrity not validated
• Coverage review skipped

Installation and execution of unauthorized software are prevented

• Application allowlist policy and tooling configuration
• Endpoint protection deployment reports
• Software install request workflow
• Unauthorized software detection alerts
• Periodic review of installed software baselines

• Allowlist exceptions overgrown
• Detection alerts only for sanctioned populations
• Install workflow bypassed by admins
• Review of installed software not performed

Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle

• Secure SDLC standard with control gates
• Threat modeling outputs per project
• Static and dynamic analysis pipeline configuration
• Software composition analysis findings
• Pre release security sign off records

• Threat modeling skipped for fast track projects
• Pipeline analysis breaks but does not block
• Composition analysis findings unprioritized
• Sign off absent for emergency releases

Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders

• Stakeholder communication plan for recovery
• Status update templates with cadence
• Distribution evidence for recovery updates
• Stakeholder feedback collection records
• Lessons learned on communication effectiveness

• Updates technical, not business focused
• Cadence drops during long recoveries
• Distribution lists outdated
• Feedback not collected

Public updates on incident recovery are shared using approved methods and messaging

• Public communications policy with approval workflow
• Approved spokesperson list and training records
• Holding statement templates for recovery
• Crisis communications drill outcomes
• Sample public updates issued during incidents

• Spokespeople untrained
• Templates lack regulatory specifics
• Drills omit recovery phase
• Updates inconsistent across channels

The recovery portion of the incident response plan is executed once initiated from the incident response process

• Recovery plan with triggers and decision rights
• Execution log of recovery activities
• Recovery team roster with on call coverage
• Plan invocation tests and outcomes
• Post execution review records

• Triggers unclear in the plan
• Execution log incomplete during incidents
• Roster outdated
• Tests omit the invocation step

Recovery actions are selected, scoped, prioritized, and performed

• Recovery prioritization criteria
• Decision log capturing scope and sequencing
• Recovery sequencing diagrams for critical services
• Resource allocation records during recovery
• Stakeholder sign off on prioritization

• Criteria not used under pressure
• Sequencing diagrams outdated
• Resource decisions ad hoc
• Sign off skipped

The integrity of backups and other restoration assets is verified before using them for restoration

• Backup integrity testing standard
• Pre restoration verification records
• Cryptographic hash validation evidence
• Tabletop exercise on compromised backup scenarios
• Restoration test outcomes

• Integrity checks bypassed under time pressure
• Hash validation absent for some media
• Tabletop scenarios shallow
• Test outcomes not retained

Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms

• Recovery time objective tracking dashboard
• Service restoration verification procedure
• User acceptance evidence per restored service
• Recovery deviation records and rationale
• Post restoration monitoring reports

• RTO measured but not enforced
• Verification absent for dependent services
• User acceptance signed off generically
• Post restoration monitoring brief

The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed

• Integrity verification procedure for restored systems
• File integrity comparison reports
• Application transaction validation records
• Identity and access verification post restore
• Independent verification by an alternate team

• Verification limited to file checksums
• Application level validation absent
• Identity reconciliation skipped
• Independent verification not performed

The end of incident recovery is declared based on criteria, and incident-related documentation is completed

• End of recovery criteria document
• Sign off records from business owners
• Recovery closure communications
• Transition to steady state operations plan
• Lessons learned scheduled and conducted

• End of recovery declared informally
• Business owners not consulted
• Transition plan absent
• Lessons learned never scheduled

Analysis is performed to establish what has taken place during an incident and the root cause of the incident

• Incident investigation procedure
• Forensic analysis reports with timeline reconstruction
• Tooling evidence list (memory captures, disk images, log exports)
• Analyst peer review records
• Quality assurance findings on investigation outputs

• Procedure assumes on premise scenarios only
• Timelines rely on system clocks not synchronized
• Memory captures absent for cloud workloads
• Peer review skipped under time pressure

Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved

• Investigation action log per incident
• Tooling audit trail (queries run, evidence pulled)
• Chain of custody records for evidence
• Decision log for investigative pivots
• QA review on action log completeness

• Actions captured in chat rather than the case system
• Chain of custody incomplete
• Decision rationale missing
• QA review not conducted

Incident data and metadata are collected, and their integrity and provenance are preserved

• Evidence collection standard with integrity controls
• Hash validated evidence storage
• Access controls and audit logs on evidence repository
• Retention schedule for incident evidence
• Independent integrity verification reports

• Evidence stored on shared drives
• Hashes computed but not validated later
• Access logs not reviewed
• Retention undefined

An incident's magnitude is estimated and validated

• Root cause analysis procedure
• Five whys or similar method evidence
• RCA report with contributing factors and lessons
• Action plan from RCA with owners and due dates
• Closure verification of RCA actions

• RCA reduced to a single root cause
• Contributing factors omitted
• Action plans without owners
• Closure verification absent

Internal and external stakeholders are notified of incidents. Control from NIST Cybersecurity Framework 2.0 framework, domain: RS - Respond.

• Incident notification policy and timing matrix
• Internal stakeholder communication templates
• Regulator notification templates with jurisdiction matrix
• Customer notification records
• Notification audit trail

• Notification timing tracked but missed
• Templates generic across jurisdictions
• Customer notification delayed by legal review
• Audit trail incomplete

Information is shared with designated internal and external stakeholders. Control from NIST Cybersecurity Framework 2.0 framework, domain: RS - Respond.

• Information sharing agreements with partners
• Sharing playbook with content controls
• Records of intelligence shared with ISAC and peers
• Internal sharing logs across business units
• Sharing effectiveness review records

• Sharing agreements signed but unused
• Sharing one way (consume only)
• Internal sharing fragmented across teams
• Effectiveness reviewed only after incidents

The incident response plan is executed in coordination with relevant third parties once an incident is declared

• Incident response plan with third party invocation
• Retainer contract evidence for IR vendor
• Joint exercise records with the IR vendor
• Coordination procedure with law enforcement
• Vendor activation log during real incidents

• Retainer in place but contact path untested
• Coordination with law enforcement absent
• Joint exercises infrequent
• Activation log incomplete

Incident reports are triaged and validated. Control from NIST Cybersecurity Framework 2.0 framework, domain: RS - Respond.

• Incident intake workflow with validation steps
• Triage decision criteria
• Sample report validation evidence
• Triage analyst quality reviews
• Trend analysis of false positives

• Validation skipped under volume
• Criteria inconsistent across shifts
• Quality reviews not performed
• False positives not analyzed for tuning

Incidents are categorized and prioritized. Control from NIST Cybersecurity Framework 2.0 framework, domain: RS - Respond.

• Incident categorization taxonomy
• Severity scoring rubric
• Incident ticket evidence showing categories and severity
• Periodic review of taxonomy completeness
• Reporting metrics by category and severity

• Taxonomy stale relative to current threats
• Severity downgraded informally
• Tickets miss category assignment
• Metrics not used for trend analysis

Incidents are escalated or elevated as needed. Control from NIST Cybersecurity Framework 2.0 framework, domain: RS - Respond.

• Escalation procedure with named roles
• Escalation tree tested through drills
• Escalation decision logs
• Executive notification protocols
• After action reviews on escalation timing

• Escalation tree outdated
• Drills omit night and weekend conditions
• Decision logs incomplete
• Reviews skip escalation analysis

The criteria for initiating incident recovery are applied

• Recovery initiation criteria documented
• Decision log linking response to recovery handoff
• Joint review by IR and recovery teams
• Tabletop coverage of the response to recovery boundary
• Closure of recovery initiation actions

• Recovery initiation criteria absent
• Handoff informal and verbal
• Joint reviews not held
• Tabletops omit recovery handoff

Incidents are contained. Control from NIST Cybersecurity Framework 2.0 framework, domain: RS - Respond.

• Containment playbook by incident type
• Network isolation tooling deployment evidence
• Account suspension workflow
• Containment effectiveness review post incident
• Approval records for containment actions with business impact

• Containment delayed pending approvals
• Tooling exists but operators untrained
• Effectiveness review absent
• Approvals not captured

Incidents are eradicated. Control from NIST Cybersecurity Framework 2.0 framework, domain: RS - Respond.

• Eradication procedure by attack technique
• Malware removal verification records
• Persistence removal evidence
• Re imaging and rebuilding policy
• Post eradication validation testing

• Eradication relies on antivirus signatures only
• Persistence checks superficial
• Re imaging avoided for time pressure
• Validation testing not retained