NIST CSF 2.0 cybersecurity self-assessment

Cybersecurity strategy and risk appetite are documented and approved at the executive or board level.

Evidence to verify: Approved cyber risk strategy or board minutes referencing it.

Cybersecurity roles, responsibilities, and accountability are assigned and reviewed at least annually.

Evidence to verify: RACI or equivalent for incident response, vulnerability management, and policy ownership.

Third-party and supply-chain cybersecurity risk is identified, contracted, and monitored.

Evidence to verify: Vendor risk register and contractual security clauses (e.g., SOC 2, security questionnaires).

Cybersecurity policies are written, communicated, and reviewed on a defined cadence.

Evidence to verify: Policy library with review dates, last-reviewed within 12 months.

An inventory of hardware, software, and data assets is maintained and reasonably accurate.

Evidence to verify: CMDB, EDR-derived asset list, or cloud-native inventory exports.

Critical business processes and the systems that support them are mapped to recovery objectives.

Evidence to verify: Business impact analysis with RTO/RPO per system.

Cybersecurity risks are assessed regularly and tracked in a risk register.

Evidence to verify: Risk register with likelihood, impact, owner, and treatment per entry.

Vulnerabilities are scanned, prioritized (CVSS plus exploitability), and remediated against SLAs.

Evidence to verify: Scanner output, time-to-patch metrics, and CISA KEV review process.

Identity is centrally managed; access is granted on least-privilege and reviewed periodically.

Evidence to verify: IAM platform, joiner/mover/leaver process, quarterly access reviews.

Multi-factor authentication is required for all privileged and remote access.

Evidence to verify: MFA enforcement policy in IDP and percentage of users covered.

Endpoints are hardened, patched, and monitored by an EDR or equivalent.

Evidence to verify: EDR coverage report, baseline configuration policy, patch SLA metrics.

Security awareness training is delivered to all staff and tested with simulated phishing.

Evidence to verify: LMS completion rates and phishing simulation click-rate trend.

Logs from endpoints, network, identity, and cloud are centralized and retained for at least 90 days.

Evidence to verify: SIEM or log lake with retention policy and ingest from each pillar.

Detection rules are written against MITRE ATT&CK techniques relevant to the threat model.

Evidence to verify: Detection-as-code repo or rule list mapped to ATT&CK technique IDs.

Alerts are triaged within a defined SLA by an in-house or contracted SOC.

Evidence to verify: Mean-time-to-acknowledge metric and SOC runbooks.

Threat intelligence is consumed and operationalized into detections and blocks.

Evidence to verify: Active TI feeds plus evidence of ingestion (sigma rules, IOC blocks, hunts).

An incident response plan exists, names roles, and references decision authority for major incidents.

Evidence to verify: IRP document with severity matrix, escalation tree, and exec contacts.

Tabletop exercises are run at least once per year with key stakeholders.

Evidence to verify: Latest tabletop after-action report and participant list.

Containment, eradication, and forensic procedures are documented for the most likely incident types.

Evidence to verify: Playbooks for ransomware, BEC, credential compromise, and data exfiltration.

External communications during an incident are pre-coordinated with legal, comms, and regulators.

Evidence to verify: Comms templates and pre-approved breach-notification language.

Backups exist, are immutable or offline, and are restoration-tested.

Evidence to verify: Backup architecture diagram and date of last successful restore test.

Recovery time and recovery point objectives are defined per critical system.

Evidence to verify: Documented RTO and RPO per system in the BIA.

A communication plan covers staff, customers, and regulators during recovery.

Evidence to verify: Recovery comms playbook tied to the IRP.

Lessons learned from incidents and exercises are captured and drive program changes.

Evidence to verify: Post-incident review template and changelog of improvements made.