Introduction
The NIST Cybersecurity Framework (CSF) 2.0, published by the United States National Institute of Standards and Technology in February 2024, is the most widely adopted voluntary framework for managing and reducing cybersecurity risk. Unlike prescriptive certification standards, the CSF is an outcome-based framework: it describes what good cybersecurity looks like at the level of measurable outcomes, and it deliberately leaves the choice of controls, tooling and processes to each organisation. This flexibility is precisely why it has become the lingua franca of cybersecurity programmes across sectors, geographies and organisation sizes, and why it is frequently used as the connective tissue that binds together more prescriptive regimes such as PCI DSS, ISO/IEC 27001, SOC 2 and India's DPDP Act obligations.
CSF 2.0 represents a significant evolution from the original 2014 (v1.0) and 2018 (v1.1) editions. The headline change is the addition of a sixth Function, GOVERN, which elevates cybersecurity risk management to a governance and enterprise-risk concern rather than a purely technical one. CSF 2.0 also formally broadened its intended audience beyond US critical-infrastructure operators to organisations of every size and sector worldwide, and it introduced a supporting suite of Implementation Examples, Informative References and Community Profiles delivered through the online CSF 2.0 Reference Tool. This guide provides an auditor-grade, end-to-end walkthrough of CSF 2.0: its structure, every Function and Category, a master assessment checklist, scoping guidance, a phased implementation approach, the Tier maturity model, evidence expectations, roles, KPIs and cross-framework mappings.
Copyright and usage note
The NIST Cybersecurity Framework (CSF) 2.0 and NIST Special Publications are US Government works and are generally not subject to copyright protection in the United States; they may be freely used and reproduced. NIST is a trademark of the National Institute of Standards and Technology. The Function, Category and Subcategory identifiers (for example GV.OC, ID.AM-01) referenced in this guide are the property and terminology of NIST. This guide is original CyberSigma commentary and interpretation written for educational purposes; it paraphrases and does not reproduce the verbatim text of the official Core. Always refer to the authoritative NIST CSF 2.0 publication and the online CSF 2.0 Reference Tool for the canonical wording of each outcome.
What is NIST CSF 2.0
The NIST Cybersecurity Framework is a taxonomy of cybersecurity outcomes and a common language for describing, assessing and communicating cybersecurity risk posture. It is intentionally technology-neutral, sector-agnostic and non-prescriptive. Rather than telling an organisation 'you must deploy control X', the CSF says 'you should achieve outcome Y', and then leaves the organisation free to select the safeguards, standards and tools appropriate to its risk appetite, size and threat environment.
CSF 2.0 is built from three principal components that work together:
- The CSF Core: a hierarchical set of desired cybersecurity outcomes organised into six Functions (Govern, Identify, Protect, Detect, Respond, Recover), which decompose into 22 Categories and 106 Subcategories. The Subcategories are the atomic, assessable outcome statements of the framework.
- The CSF Tiers: four levels (Partial, Risk Informed, Repeatable, Adaptive) that characterise the rigour and maturity of an organisation's cybersecurity risk governance and management practices. Tiers describe how an organisation views and manages risk, not a compliance score.
- The CSF Profiles: a description of an organisation's Current profile (what it does today) versus a Target profile (what it aims to achieve). The gap between the two drives the action plan. NIST also publishes Community Profiles for specific sectors and use cases as reusable baselines.
Surrounding the Core, CSF 2.0 provides online resources to make outcomes actionable: Implementation Examples (illustrative, non-mandatory actions that help achieve each Subcategory), Informative References (mappings to other standards such as ISO 27001, SP 800-53, CIS Controls and COBIT) and Quick-Start Guides for particular audiences such as small businesses, enterprise risk managers and those creating Profiles. Critically, none of these is a checklist to be certified against; the framework is a decision-support tool, and 'compliance' is measured relative to a self-defined Target Profile.
How CSF 2.0 differs from CSF 1.1
| Aspect | CSF 1.1 (2018) | CSF 2.0 (2024) |
|---|---|---|
| Functions | 5 (Identify, Protect, Detect, Respond, Recover) | 6 — GOVERN added as a central function |
| Categories | 23 | 22 (reorganised, some merged/renamed) |
| Subcategories | 108 | 106 |
| Scope | Primarily US critical infrastructure | All organisations, all sectors, global |
| Supply chain | Limited (ID.SC) | Elevated and expanded (GV.SC) with governance framing |
| Guidance delivery | Static PDF | Online Reference Tool, Implementation Examples, Community Profiles, Quick-Start Guides |
| Emphasis | Technical risk outcomes | Governance, enterprise risk integration, continuous improvement |
Who must comply
NIST CSF 2.0 is a voluntary framework; no law mandates the CSF by name for private-sector organisations in most jurisdictions. However, adoption is frequently required contractually, imposed indirectly by regulation, or adopted voluntarily as the backbone of an enterprise security programme. The following table summarises the categories of organisation that typically adopt or are effectively obliged to use the CSF.
| Organisation type | Nature of obligation |
|---|---|
| US federal agencies | Effectively mandatory — Executive Order 13800 and OMB guidance direct federal agencies to use the CSF to manage cyber risk; underpinned by FISMA and SP 800-53. |
| US critical-infrastructure operators (energy, water, finance, healthcare, transport) | Strongly expected and often sector-regulated; sector-specific agencies (e.g. FERC/NERC CIP, TSA directives) reference or align with the CSF. |
| Federal contractors and their suppliers | Contractually required — DFARS/CMMC and prime-contractor flow-downs frequently require CSF-aligned programmes and evidence. |
| Global enterprises and multinationals | Voluntary but near-universal as the common risk language and board reporting structure; used to harmonise ISO 27001, SOC 2 and local regimes. |
| Financial services firms | Regulator expectation — NYDFS 500, FFIEC and many central-bank frameworks map to or require CSF-style governance and outcomes. |
| Healthcare organisations | Used to operationalise HIPAA Security Rule risk analysis; NIST publishes the HIPAA-to-CSF crosswalk (SP 800-66r2). |
| SMEs and startups | Voluntary — CSF 2.0 Small Business Quick-Start Guide makes it the recommended starting point for building a right-sized programme. |
| Indian enterprises (SigmaCRM ICP) | Voluntary but increasingly demanded by global customers, and useful to structure CERT-In directions, DPDP Act security safeguards, RBI and SEBI cyber expectations under one model. |
Structure of NIST CSF 2.0
The CSF Core is a three-level hierarchy. Functions are the highest-level organising concept and represent the concurrent, continuous pillars of a cybersecurity programme. Each Function contains Categories (groups of related outcomes), and each Category contains Subcategories (specific, measurable outcome statements identified by codes such as ID.AM-01). Subcategories are what an assessor actually evaluates. The table below enumerates all six Functions and their 22 Categories with the official Category identifiers.
| Function | Category (ID) — Name | Focus |
|---|---|---|
| GOVERN (GV) | GV.OC — Organizational Context | Mission, stakeholders, legal/regulatory requirements understood |
| GOVERN (GV) | GV.RM — Risk Management Strategy | Risk appetite, tolerance and strategy established |
| GOVERN (GV) | GV.RR — Roles, Responsibilities & Authorities | Accountability and authority for cyber risk defined |
| GOVERN (GV) | GV.PO — Policy | Cybersecurity policy established and maintained |
| GOVERN (GV) | GV.OV — Oversight | Strategy outcomes reviewed to inform risk management |
| GOVERN (GV) | GV.SC — Cybersecurity Supply Chain Risk Management | C-SCRM programme established and managed |
| IDENTIFY (ID) | ID.AM — Asset Management | Assets (data, hardware, software, systems, people) inventoried |
| IDENTIFY (ID) | ID.RA — Risk Assessment | Cybersecurity risk to the organisation understood |
| IDENTIFY (ID) | ID.IM — Improvement | Improvements identified across all Functions |
| PROTECT (PR) | PR.AA — Identity Management, Authentication & Access Control | Access limited to authorised users, services, hardware |
| PROTECT (PR) | PR.AT — Awareness & Training | Personnel provided with security awareness and training |
| PROTECT (PR) | PR.DS — Data Security | Data managed consistent with confidentiality, integrity, availability |
| PROTECT (PR) | PR.PS — Platform Security | Hardware/software managed to protect confidentiality, integrity, availability |
| PROTECT (PR) | PR.IR — Technology Infrastructure Resilience | Security architectures protect asset resilience |
| DETECT (DE) | DE.CM — Continuous Monitoring | Assets monitored to find anomalies and adverse events |
| DETECT (DE) | DE.AE — Adverse Event Analysis | Anomalies and events analysed to characterise incidents |
| RESPOND (RS) | RS.MA — Incident Management | Responses to incidents managed |
| RESPOND (RS) | RS.AN — Incident Analysis | Investigation to ensure effective response and support recovery |
| RESPOND (RS) | RS.CO — Incident Response Reporting & Communication | Response activities coordinated with stakeholders |
| RESPOND (RS) | RS.MI — Incident Mitigation | Activities to prevent expansion and mitigate effects |
| RECOVER (RC) | RC.RP — Incident Recovery Plan Execution | Restoration activities performed to restore assets/operations |
| RECOVER (RC) | RC.CO — Incident Recovery Communication | Recovery activities coordinated with stakeholders |
Reading the identifiers
Every outcome is addressed by a code of the form Function.Category-NN. For example ID.AM-01 is the first Subcategory of the Asset Management Category within the Identify Function ('Inventories of hardware managed by the organization are maintained'). When assessing, always cite Subcategory codes so findings map cleanly to the Core and to cross-framework references.
Master assessment checklist
This is the operational heart of the guide. For each Function we provide an h3 group, a short orientation, and a TABLE of what an auditor should verify at the Subcategory level together with the typical evidence to collect. The verification statements paraphrase the CSF 2.0 Subcategory outcomes; they are grouped by Category so no control area is skipped. Assessors should score each row against the organisation's Target Profile and Tier ambition.
GOVERN (GV) — Organizational Context, Risk Strategy, Roles, Policy, Oversight, Supply Chain
Govern establishes and monitors the organisation's cybersecurity risk management strategy, expectations and policy. It informs how the other five Functions are implemented and is the outcome most often missing in immature programmes.
| What to verify | Typical evidence |
|---|---|
| GV.OC-01/02: Organisational mission and internal/external stakeholder expectations for cybersecurity are understood and documented | Mission statement, stakeholder register, business context document, board briefings |
| GV.OC-03: Legal, regulatory and contractual cybersecurity requirements are understood and managed | Regulatory obligations register, contract clauses matrix, legal sign-off, DPDP/CERT-In mapping |
| GV.OC-04/05: Critical objectives, capabilities and services that stakeholders depend on are understood; outcomes/dependencies communicated | Business impact analysis, service catalogue, critical dependency map |
| GV.RM-01 to 07: Risk management objectives, risk appetite and risk tolerance statements are established, agreed and communicated | Risk management strategy, risk appetite statement approved by leadership, risk register methodology |
| GV.RR-01: Leadership is accountable for cybersecurity risk and fosters a risk-aware culture | Board/exec charter, CISO reporting line, culture survey results |
| GV.RR-02/03/04: Roles, responsibilities and authorities are established; adequate resources allocated; cybersecurity included in HR practices | RACI matrix, org chart, budget allocation, JD security clauses, onboarding/offboarding records |
| GV.PO-01/02: Cybersecurity policy is established, communicated, enforced and reviewed for relevance | Approved policy suite with version/owner/review dates, acknowledgement logs |
| GV.OV-01/02/03: Cybersecurity risk management strategy results are reviewed to inform and adjust the strategy; performance is evaluated | Management review minutes, KRI/KPI dashboards, strategy adjustment records |
| GV.SC-01 to 10: A cybersecurity supply chain risk management (C-SCRM) programme, strategy, roles and processes are established, integrated into procurement, and suppliers are assessed, monitored and included in incident planning | C-SCRM policy, supplier risk tiering, due-diligence questionnaires, contract security requirements, supplier monitoring, supplier incident clauses |
IDENTIFY (ID) — Asset Management, Risk Assessment, Improvement
Identify develops the organisational understanding needed to manage cybersecurity risk to systems, people, assets, data and capabilities. You cannot protect what you have not identified.
| What to verify | Typical evidence |
|---|---|
| ID.AM-01/02: Inventories of hardware and software (including firmware and services) are maintained | Asset management CMDB, software inventory, endpoint discovery reports |
| ID.AM-03: Representations of authorised network communication and data flows are maintained | Network diagrams, data-flow diagrams, firewall rulebase |
| ID.AM-04/05: Inventories of services provided by suppliers are maintained; assets are prioritised by classification, criticality and business value | Third-party service register, asset classification scheme, criticality ratings |
| ID.AM-07/08: Inventories of data and metadata are maintained; systems, hardware, software and services are managed throughout their life cycle | Data inventory/RoPA, lifecycle policy, decommissioning records |
| ID.RA-01/02: Vulnerabilities in assets are identified, validated and recorded; cyber threat intelligence is received from information-sharing forums | Vulnerability scan reports, penetration test findings, CTI feed subscriptions, CERT-In advisories |
| ID.RA-03/04/05: Internal and external threats are identified; potential impacts and likelihoods are identified; threats, vulnerabilities, likelihoods and impacts are used to determine risk | Threat register, risk assessment reports, risk register with scoring |
| ID.RA-06/07/08: Risk responses are chosen, prioritised, tracked; changes are managed; processes for receiving and acting on vulnerability disclosures are established | Risk treatment plan, change tickets, vulnerability disclosure policy, remediation tracker |
| ID.RA-09/10: Authenticity and integrity of hardware and software are assessed before acquisition/use; critical suppliers are assessed | Supplier attestations, SBOM review, product security assessments |
| ID.IM-01 to 04: Improvements are identified from evaluations, security tests, operational activities and lessons learned; cybersecurity plans (including incident response) are established, communicated and maintained | Assessment findings log, tabletop/lessons-learned reports, continuous improvement register, updated plans |
PROTECT (PR) — Access Control, Awareness, Data Security, Platform Security, Infrastructure Resilience
Protect supports the ability to limit or contain the impact of a potential cybersecurity event through safeguards for identity, data, platforms and infrastructure.
| What to verify | Typical evidence |
|---|---|
| PR.AA-01/02/03: Identities and credentials for authorised users, services and hardware are managed; identities are proofed and bound to credentials; users, services and hardware are authenticated | IAM/IGA records, identity proofing procedures, authentication policy |
| PR.AA-04/05: Identity assertions are protected; access permissions, entitlements and authorisations are defined, managed and enforced incorporating least privilege and separation of duties | Access control policy, RBAC/ABAC matrix, entitlement reviews, SoD conflict reports |
| PR.AA-06: Physical access to assets is managed, monitored and enforced | Badge/access logs, CCTV, visitor logs, data-centre access records |
| PR.AT-01/02: Personnel are provided awareness and training so they perform general and privileged/specialised duties securely | LMS completion records, phishing simulation results, role-based training records |
| PR.DS-01/02: Confidentiality, integrity and availability of data-at-rest and data-in-transit are protected | Encryption standards, TLS configs, key management records, DLP policy |
| PR.DS-10/11: Confidentiality, integrity and availability of data-in-use are protected; backups of data are created, protected, maintained and tested | Backup schedules, restore test logs, immutable/offline backup evidence |
| PR.PS-01 to 06: Configuration management practices are established; software is maintained/patched; hardware is maintained/replaced; log records are generated and available; installation/execution of unauthorised software is prevented; secure software development practices are integrated | Hardening baselines/CIS benchmarks, patch reports, logging config, application allow-listing, SSDLC/SAST/DAST evidence |
| PR.IR-01 to 04: Networks and environments are protected from unauthorised access; technology assets are protected from environmental threats; mechanisms achieve resilience requirements in normal and adverse situations; adequate resource capacity is maintained | Network segmentation, redundancy/HA design, capacity monitoring, environmental controls records |
DETECT (DE) — Continuous Monitoring, Adverse Event Analysis
Detect finds and analyses possible cybersecurity attacks and compromises in a timely manner, enabling successful incident response and recovery.
| What to verify | Typical evidence |
|---|---|
| DE.CM-01: Networks and network services are monitored to find potentially adverse events | IDS/IPS logs, NDR/network monitoring dashboards, netflow analysis |
| DE.CM-02: The physical environment is monitored to find potentially adverse events | Physical security monitoring, alarm logs, environmental sensor data |
| DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events | UEBA reports, privileged-session monitoring, insider-threat alerts |
| DE.CM-06: External service provider activities and services are monitored to find potentially adverse events | Third-party access logs, vendor SLA/SIEM feeds, supplier monitoring reports |
| DE.CM-09: Computing hardware, software, runtime environments and their data are monitored to find potentially adverse events | EDR/XDR alerts, integrity monitoring (FIM), vulnerability posture feeds |
| DE.AE-02/03: Potentially adverse events are analysed to understand associated activity; information is correlated from multiple sources | SIEM correlation rules, analyst triage notes, case management records |
| DE.AE-04/06: Estimated impact and scope of events are understood; information on adverse events is provided to authorised staff and tools | Incident scoping documents, alert enrichment, ticketing integration |
| DE.AE-07/08: Cyber threat intelligence and other contextual information are integrated into analysis; incidents are declared when event criteria are met | CTI enrichment records, incident declaration criteria, escalation logs |
RESPOND (RS) — Incident Management, Analysis, Reporting, Mitigation
Respond supports the ability to take action regarding a detected cybersecurity incident, containing its effects.
| What to verify | Typical evidence |
|---|---|
| RS.MA-01 to 05: The incident response plan is executed once an incident is declared; incidents are triaged, validated, categorised, prioritised and escalated | IR plan, incident tickets with categorisation/priority, escalation records |
| RS.AN-03: Analysis is performed to establish what has taken place during an incident and the root cause | Forensic reports, root-cause analysis, timeline reconstruction |
| RS.AN-06/07/08: Actions performed during investigation are recorded and their integrity/provenance preserved; incident data and metadata are collected and preserved; magnitude of the incident is estimated and validated | Chain-of-custody logs, evidence handling records, impact assessment |
| RS.CO-02/03: Internal and external stakeholders are notified of incidents; information is shared consistent with response plans | Notification templates, regulator/CERT-In reporting (6-hour rule), comms logs, breach notifications |
| RS.MI-01/02: Incidents are contained and eradicated | Containment action records, isolation logs, eradication/remediation tickets |
RECOVER (RC) — Recovery Plan Execution, Recovery Communication
Recover restores assets and operations affected by a cybersecurity incident, supporting timely return to normal operations and reducing the impact of incidents.
| What to verify | Typical evidence |
|---|---|
| RC.RP-01: The recovery portion of the incident response plan is executed once initiated from the incident response process | Recovery runbook, activation records |
| RC.RP-02/03: Recovery actions are selected, scoped, prioritised and performed; integrity of backups and restoration assets is verified before restoration | Restoration task list, backup integrity checks, restore validation logs |
| RC.RP-04/05/06: Critical mission functions and cyber risk management are considered in restoration; the integrity of restored assets is verified and systems/services restored to normal; the end of incident recovery is declared and documentation completed | Business function restoration checklist, verification test results, incident closure report |
| RC.CO-03/04: Recovery activities and progress are communicated to designated internal and external stakeholders; public updates are shared using approved methods and messaging | Stakeholder comms log, status updates, approved public statements/press messaging |
Scoping
Because the CSF is applied through Profiles rather than certified as a fixed boundary, scoping means deciding which parts of the organisation the Profile covers, which Subcategories are in scope, and to what Tier ambition. Poor scoping is the most common reason CSF programmes lose credibility, so scope decisions must be documented and approved.
Steps to define scope
- Define the organisational unit(s) covered — the whole enterprise, a business unit, a product line, or a specific system or environment (for example the SigmaCRM SaaS platform).
- Identify the mission, critical services and stakeholders (GV.OC) that anchor why cybersecurity matters for that scope.
- Enumerate in-scope assets: systems, applications, data stores, cloud tenants, networks, third-party services and physical locations.
- Determine applicable legal, regulatory and contractual drivers (DPDP Act, CERT-In directions, sector rules, customer contracts) that constrain the Target Profile.
- Select the Subcategories that apply — for most organisations all 106 apply, but a Community or sector Profile may prioritise a subset and set priorities/timeframes.
- Set the Tier ambition per Category (see Tier model), reflecting risk appetite and resourcing.
- Document exclusions with justification (for example, no operational technology, therefore certain OT-specific Implementation Examples are not applicable).
Profiles, not perimeters
CSF scoping is best captured as a Current Profile and a Target Profile spreadsheet with one row per Subcategory: current state, target state, priority, gap and owner. This artefact is simultaneously your scope statement, your gap analysis and your roadmap input.
Implementation approach
NIST recommends a repeatable, iterative cycle for creating and using Profiles. We express it as five phases, each with activities and deliverables. The cycle is continuous — you re-run it as risk, business and threat context change.
Phase 1 — Scope and govern
- Activities: obtain leadership sponsorship; establish governance (GV Function) including risk appetite, roles and policy; define the scope and the mission/stakeholder context.
- Deliverables: programme charter, approved risk management strategy and risk appetite statement, RACI, scope statement.
Phase 2 — Assess current state (Current Profile)
- Activities: gather information across all six Functions; interview owners; collect evidence; rate each in-scope Subcategory against its current outcome achievement.
- Deliverables: Current Profile with per-Subcategory ratings, evidence index, initial Tier assessment.
Phase 3 — Define target state (Target Profile)
- Activities: select or adapt a Community Profile if relevant; set target outcomes and Tier ambitions driven by risk appetite, regulation and business objectives; agree priorities.
- Deliverables: Target Profile, prioritised list of desired outcomes, Tier targets per Category.
Phase 4 — Analyse gaps and plan
- Activities: compare Current and Target Profiles; identify and prioritise gaps by risk and effort; map gaps to Implementation Examples and specific projects; build a costed, time-bound action plan.
- Deliverables: gap analysis, cyber risk register updates, prioritised remediation roadmap and business case.
Phase 5 — Implement, measure and improve
- Activities: execute remediation projects; operationalise controls; measure KPIs/KRIs; report to leadership (GV.OV); feed lessons learned back (ID.IM) and re-baseline.
- Deliverables: implemented controls, KPI dashboard, management review records, updated Profile — completing the continuous improvement loop.
Tier (maturity/capability) model
CSF Tiers characterise the degree to which cybersecurity risk management practices exhibit the characteristics of the framework — rigour, integration with enterprise risk, and how the organisation views and responds to risk. Tiers are not a maturity certification and are not intended to be a compliance score; an organisation should select a Tier that reflects its risk appetite and reduces risk to acceptable levels. Tiers can be applied to individual Categories, not just the whole programme.
| Tier | Name | Risk management process | Integrated risk programme | External participation |
|---|---|---|---|---|
| Tier 1 | Partial | Ad hoc, reactive, not formalised; risk managed inconsistently | Limited awareness; cyber risk managed in silos; irregular | Does not understand its role in the ecosystem; limited sharing |
| Tier 2 | Risk Informed | Risk-informed practices approved by management but not organisation-wide policy | Awareness exists but organisation-wide approach not established; some prioritisation | Understands its role but acts inconsistently; informal collaboration |
| Tier 3 | Repeatable | Formally approved, expressed as policy, regularly updated based on business/threat change | Organisation-wide approach; consistent methods; risk-informed decisions; skilled staff | Understands dependencies and dependents; collaborates and receives/shares information formally |
| Tier 4 | Adaptive | Continuously improves practices using lessons learned and predictive indicators; adapts to changing threats | Cyber risk is part of culture and enterprise risk; real-time, informed decisions; budget reflects risk | Actively shares information; uses real-time intelligence; leads in the ecosystem |
Choosing a Tier
Higher is not automatically better. NIST advises selecting the Tier that meets organisational goals, is feasible to implement, and reduces cybersecurity risk to acceptable levels. Many SMEs sensibly target Tier 2 to Tier 3 for core Categories rather than Tier 4 everywhere.
Assessment and audit approach
A CSF assessment is a structured evaluation of Current Profile against Target Profile with supporting evidence. The following steps produce an auditor-grade result.
- Confirm scope, Profile definitions and Tier ambitions with the sponsor and document them.
- Build an evidence request list mapped to Subcategories and issue it in advance.
- Conduct interviews with control owners across all six Functions (Govern through Recover).
- Perform document review of policies, standards, procedures, registers and plans.
- Perform technical validation and sampling — inspect configurations, logs, scan/pen-test results and system settings rather than relying on assertions alone.
- Rate each in-scope Subcategory (for example: Not Achieved / Partially / Largely / Fully, or a 0-4 scale) and record the supporting evidence reference.
- Assess the Tier per Category using the rated Subcategories and governance observations.
- Perform gap analysis between Current and Target Profiles and rank gaps by risk and effort.
- Produce a report with executive summary, per-Function findings, heat map, prioritised roadmap and re-assessment cadence.
- Agree remediation owners and dates; schedule follow-up validation of remediated items.
Evidence request list
Collect evidence categorised by Function so gaps are visible and traceable. The list below is representative, not exhaustive; tailor it to scope.
- Govern: risk management strategy, risk appetite/tolerance statements, cybersecurity policy suite, RACI/org charts, board and management review minutes, regulatory obligations register, C-SCRM policy and supplier risk assessments.
- Identify: hardware/software/data inventories (CMDB), network and data-flow diagrams, asset classification scheme, vulnerability scan and penetration test reports, threat intelligence subscriptions, risk register and treatment plan, lessons-learned records.
- Protect: IAM/IGA and access review records, least-privilege and SoD reports, MFA configuration, encryption and key management standards, backup schedules and restore test logs, hardening baselines, patch management reports, SSDLC and secure-coding evidence, awareness and role-based training records.
- Detect: SIEM/EDR/XDR configuration and alerts, log sources inventory and retention policy, monitoring dashboards, correlation rules, incident declaration criteria, threat-intel enrichment records.
- Respond: incident response plan, incident tickets with triage/categorisation, forensic and root-cause reports, chain-of-custody records, regulator/CERT-In notification evidence, stakeholder communication logs.
- Recover: recovery runbooks and BCP/DR plans, backup integrity verification, restore validation results, incident closure reports, recovery communication logs and approved public messaging.
Roles and responsibilities
| Role | CSF responsibility |
|---|---|
| Board / Senior Leadership | Own cyber risk accountability (GV.RR-01), set risk appetite, approve strategy and policy, receive oversight reporting (GV.OV) |
| Chief Information Security Officer (CISO) | Own the CSF programme, define Target Profile, drive implementation, report posture and KRIs to leadership |
| Risk / GRC Manager | Maintain risk register, run Profile assessments, track remediation, manage cross-framework mappings |
| Enterprise / IT Asset Owner | Maintain asset, data and software inventories (ID.AM); own lifecycle and classification |
| Security Operations (SOC) | Operate Detect and Respond outcomes — monitoring, triage, incident handling |
| IT / Platform Engineering | Implement Protect outcomes — access control, hardening, patching, encryption, backups |
| Incident Response Lead | Execute RS and RC plans, coordinate analysis, containment, recovery and communications |
| Procurement / Vendor Management | Operate C-SCRM (GV.SC) — supplier due diligence, contract security terms, ongoing monitoring |
| HR | Support GV.RR and PR.AT — background checks, onboarding/offboarding, awareness training enrolment |
| Internal Audit | Provide independent assurance over Profile ratings and control operation |
KPIs to track
- Percentage of in-scope Subcategories at or above Target Profile rating (overall and per Function).
- Average Tier achieved per Category versus Tier ambition.
- Asset inventory coverage and accuracy (percentage of assets discovered and classified).
- Mean time to detect (MTTD) and mean time to respond/contain (MTTR) for incidents.
- Percentage of critical and high vulnerabilities remediated within SLA.
- Patch compliance rate across in-scope systems.
- MFA and privileged-access coverage; percentage of access reviews completed on schedule.
- Backup restore test success rate and recovery time/point objective (RTO/RPO) achievement.
- Security awareness training completion rate and phishing simulation failure rate.
- Percentage of critical suppliers assessed and monitored under the C-SCRM programme.
- Number of open high-risk gaps and average age of remediation items.
- Percentage of incidents reported to regulators/CERT-In within mandated timelines.
Readiness checklist
- Leadership sponsorship secured and cyber risk accountability assigned (GV.RR-01)
- Risk appetite and risk management strategy documented and approved (GV.RM)
- Cybersecurity policy suite established, communicated and version-controlled (GV.PO)
- Scope, Current Profile and Target Profile defined and approved
- Tier ambitions set per Category and agreed with leadership
- Complete hardware, software and data inventories maintained (ID.AM)
- Risk assessment performed with a maintained risk register and treatment plan (ID.RA)
- Access control with least privilege, SoD and MFA enforced (PR.AA)
- Data protected at rest and in transit; backups created and restore-tested (PR.DS)
- Configuration, patch and platform security baselines in place (PR.PS)
- Continuous monitoring (SIEM/EDR) operational with defined log sources (DE.CM)
- Incident response plan tested via tabletop exercise (RS.MA / ID.IM)
- Recovery/DR runbooks documented with verified backups (RC.RP)
- C-SCRM programme covering critical suppliers established (GV.SC)
- Awareness and role-based training delivered and evidenced (PR.AT)
- KPI/KRI dashboard reporting posture to leadership on a cadence (GV.OV)
- Regulatory and contractual obligations (DPDP, CERT-In, sector) mapped to Subcategories
- Gap analysis complete with a prioritised, owned remediation roadmap
Common gaps
- No formal Govern function — risk appetite, policy ownership and oversight reporting are absent, so the programme lacks direction and board visibility.
- Incomplete asset and data inventories (ID.AM), meaning controls cannot be scoped or verified and shadow IT goes unmanaged.
- Supply chain risk treated informally — no C-SCRM programme, no supplier tiering or contract security terms (GV.SC) despite it being a top attack vector.
- Detect capability limited to logging without correlation, tuning or 24x7 coverage, producing high MTTD.
- Backups exist but are never restore-tested, so RC.RP fails during a real ransomware event.
- Least privilege and separation of duties not enforced; standing privileged access and unreviewed entitlements (PR.AA).
- Incident response plan exists on paper but is never exercised, so roles and escalation break down under pressure.
- Profiles are created once for an audit and never maintained — no continuous improvement loop (ID.IM / GV.OV).
- Tiers confused with maturity certification, leading to over-investment chasing Tier 4 everywhere instead of risk-based targeting.
- Awareness training is annual and generic, with no role-based or phishing-simulation reinforcement (PR.AT).
NIST CSF mapped to other frameworks
A key strength of the CSF is that it acts as a Rosetta Stone across regimes. NIST publishes Informative References that map Subcategories to other standards; the table below gives an indicative Function-level crosswalk useful for harmonising a multi-framework programme.
| NIST CSF 2.0 Function | ISO/IEC 27001:2022 (Annex A) | SP 800-53 Rev 5 families | CIS Controls v8 | PCI DSS v4.0 | DPDP Act 2023 / CERT-In |
|---|---|---|---|---|---|
| GOVERN (GV) | A.5 Organisational controls; Clauses 4-6 (context, leadership, planning) | PM, PL, RA (governance/programme) | CIS 1, 17 (governance, IR mgmt) | Req 12 (policies, governance) | Reasonable security safeguards obligation; accountability of Data Fiduciary |
| IDENTIFY (ID) | A.5.9 asset inventory; A.5.7 threat intel; risk assessment clauses | CM, RA, PM, SA | CIS 1, 2, 3 (inventory, data) | Req 9.5, 12.5 (asset/scope) | RoPA-style data inventory; risk assessment for personal data |
| PROTECT (PR) | A.8 technological; A.5.15-18 access; A.8.24 crypto | AC, IA, SC, MP, PE, AT | CIS 3, 4, 5, 6, 11, 14 | Req 3, 4, 7, 8 (data, access, crypto) | Encryption and access safeguards; purpose limitation controls |
| DETECT (DE) | A.8.15-16 logging/monitoring | AU, SI, CA | CIS 8, 13 | Req 10, 11 (logging, testing) | Log retention (CERT-In 180-day direction) |
| RESPOND (RS) | A.5.24-28 incident management | IR, AU | CIS 17 | Req 12.10 (incident response) | 6-hour incident reporting to CERT-In; breach notification |
| RECOVER (RC) | A.5.29-30 continuity; A.8.13 backup | CP, IR | CIS 11 (recovery) | Req 12.10 (recovery within IR) | Continuity of data-processing safeguards |
How CyberSigma helps
CyberSigma runs your NIST CSF 2.0 journey end to end: we scope your Current and Target Profiles, rate all 106 Subcategories with evidence, assess your Tier per Category, and deliver a prioritised, costed remediation roadmap. Our CERT-In empanelled and PCI QSA led team then implements the gaps — from governance and C-SCRM through monitoring, incident response and recovery testing — and harmonises the CSF with your ISO 27001, PCI DSS, SOC 2 and DPDP Act obligations so a single programme satisfies every stakeholder. The result is an audit-ready, continuously improving cybersecurity programme with board-level reporting, not just a one-off gap report. Talk to CyberSigma to book a NIST CSF 2.0 readiness assessment.
Free 1-minute check
Try it free →Free Security Assessment
Get a complimentary, no-obligation assessment from CERT-In empanelled senior auditors.
Frequently asked questions
Is NIST CSF mandatory?
The CSF itself is voluntary. However, many US government contracts and sector regulators effectively require it (or NIST SP 800-53/800-171), and customers increasingly ask for it in security questionnaires.
What changed in CSF 2.0?
The headline change is the new Govern Function, plus broader applicability beyond critical infrastructure, clearer supply-chain guidance and implementation resources.
How does NIST CSF relate to ISO 27001?
They are complementary. ISO 27001 certifies a management system; CSF is a flexible outcome model. Controls map closely, so work done for one accelerates the other.
Need help with NIST CSF?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.