Guida per un CISO al NIST Cybersecurity Framework

The NIST Cybersecurity Framework is not a rigid set of rules to be followed, but a system for structuring and communicating cybersecurity risk management. It is designed to create a clear line of communication between technical implementation teams and executive leadership, translating security activities into business risk terms.

Understanding the NIST Framework and Its Purpose

The NIST Cybersecurity Framework (CSF) is a system for organising and improving an organisation's security posture, not a compliance checklist. Instead of mandating specific tools or controls, it provides a flexible, risk-based structure that integrates into existing security programmes.

Its primary function is to create a common vocabulary for risk. This allows technical teams and executive leaders to discuss cybersecurity in a consistent, understandable manner, connecting day-to-day security operations to strategic business objectives.

A De Facto Standard for Risk Management

Over time, the CSF has become a leading model for security and risk management due to its practical and adaptable design. With a significant majority of organisations using at least one security framework, the NIST CSF is the most widely adopted choice, according to recent cybersecurity research.

For CISOs and risk officers, particularly in regulated industries, the framework is a foundational tool. It enables the development and justification of a structured approach to risk without being locked into a single, inflexible standard. This makes it a cornerstone of any modern cyber risk strategy and governance programme.

Evolution to CSF 2.0

The framework is designed to evolve with the threat landscape. The update to CSF 2.0 expands its applicability to all organisations, not just those in critical infrastructure.

The most significant change in CSF 2.0 is the addition of a "Govern" function. This move elevates cybersecurity governance to a central component of the framework, establishing it as an enterprise risk on par with financial or operational risk.

This shift from version 1.1 to 2.0 demonstrates the framework's continued relevance and reinforces its role as a foundational element of organisational resilience. With this context, we can examine its core components.

Deconstructing the Six Core Functions

Viewing the NIST Cybersecurity Framework as a checklist is a fundamental misunderstanding. The Framework Core is not a list of tasks but a continuous lifecycle for managing risk. Its six high-level Functions are the pillars of a comprehensive cybersecurity programme.

The framework evolved from version 1.0 in 2014, to 1.1 in 2018, and to CSF 2.0 in February 2024. This progression reflects the increasing sophistication of cyber threats. The introduction of the 'Govern' function in CSF 2.0 is a direct response to this reality, emphasising the need for strategic oversight. You can find a detailed review of the changes in IBM's analysis of the new framework.

The New 'Govern' Function: Strategy Comes First

CSF 2.0 places the Govern function at the centre of the framework. This is a formal acknowledgement that cybersecurity is a core business risk, equivalent to financial or operational risk.

Govern represents the strategic direction for the security posture. It defines accountability, establishes the organisation's risk appetite, and aligns security with business objectives. Without a solid governance foundation, the other five functions become a set of disconnected tactical activities lacking clear purpose and accountability.

Identify: Know Your Assets and Risks

An organisation cannot protect what it does not know it has. The Identify function is about building a foundational understanding of the operational environment. This discovery phase is non-negotiable.

It requires a systematic inventory of key areas:

• Asset Management: What hardware, software, and data assets exist? Where are they located?
• Business Environment: What are the organisation's critical processes? Where does it fit within the supply chain? What are its most valuable assets?
• Risk Assessment: What are the credible threats and vulnerabilities? What would be the business impact of an incident?

This is not about creating a perfect, exhaustive catalogue but about focusing security efforts on the assets and processes that are most critical to the organisation.

Protect: Implement Defences

Once critical assets are identified, the Protect function focuses on implementing appropriate safeguards to ensure the continued operation of critical services. This is where risk theory is translated into practice by deploying controls to limit the impact of a potential cybersecurity event.

This function translates risk assessment into action. It is not about eliminating all risk, but about deploying proportionate controls—such as access control, data security, and protective technology—to reduce risk to an acceptable level defined by the Govern function.

For example, if the Identify function classifies a customer database as a critical asset, the Protect function would involve implementing controls such as data encryption, strict access policies, and regular vulnerability scanning for that system.

Detect: Identify Anomalies and Events

No defence is perfect. The Detect function operates on the assumption that a breach will eventually occur. Its goal is to enable the timely discovery of cybersecurity events.

The speed of detection is critical, as shorter detection times reduce the potential for damage. This involves continuous monitoring for indicators of compromise through systems like a SIEM, log analysis, and defined processes for investigating security alerts. A mature Detect capability is what distinguishes a minor incident from a major crisis.

Respond: Contain the Impact of Incidents

Detection is only effective if followed by a planned response. The Respond function is that plan in action. It involves executing a pre-planned, coordinated effort to contain the impact of a detected cybersecurity incident.

This is where the incident response plan transitions from a document to a real-world operation. Key activities include stakeholder communication, forensic analysis to understand the scope of the breach, and immediate mitigation activities. The quality of the response is a direct measure of an organisation's operational resilience.

Recover: Restore Operations

Finally, the Recover function focuses on restoring any capabilities or services that were impaired during an incident. It is the final component of a resilient system.

This involves executing recovery plans, conducting post-incident reviews to improve defences, and managing communications. A well-defined recovery process ensures the organisation can withstand an adverse event and resume its mission.

This table summarises how the six Core Functions of NIST CSF 2.0 operate as a complete, integrated system.

NIST Cybersecurity Framework 2.0 Core Functions

Each function informs and is informed by the others, creating a feedback loop that drives continuous improvement rather than one-time compliance checks.

How the Framework Breaks Down into Actionable Steps

The NIST Cybersecurity Framework is structured hierarchically. The six Core Functions provide the high-level strategy, while their decomposition into Categories and Subcategories enables practical implementation. This is how organisations translate a strategic goal into a specific, measurable security control.

This diagram illustrates how the Govern function is positioned at the centre, coordinating the other five functions in NIST CSF 2.0.

This visual representation serves as a reminder that governance is not a separate bureaucratic task but the central mechanism driving how an organisation identifies risks, protects assets, and manages incidents.

From Functions to Actionable Controls

Each Core Function is divided into Categories, which represent groups of cybersecurity outcomes aligned with specific business needs. For example, under the Identify (ID) function, one finds Categories such as 'Asset Management' (ID.AM) and 'Risk Assessment' (ID.RA). These are broad but more focused than the parent function.

Categories are further broken down into Subcategories. This is the most granular level of the framework, where policy is translated into specific technical or management activities that can be measured and audited.

For example, the 'Asset Management' (ID.AM) Category includes Subcategories such as:

• ID.AM-01: Physical devices and systems within the organisation are inventoried.
• ID.AM-02: Software platforms and applications within the organisation are inventoried.

This structure creates a clear line of traceability from a strategic objective (e.g., "we need to know what assets we have") to a specific, auditable outcome ("we have a complete software inventory"). This is how the framework transforms high-level strategy into verifiable evidence of control.

Understanding Implementation Tiers

In addition to the Core, the framework provides Implementation Tiers. It is critical to understand that Tiers are not maturity levels. They are a diagnostic tool for assessing how an organisation manages cybersecurity risk from a process and governance perspective. They provide a common language for executives and technical leaders to discuss risk posture.

The Tiers help an organisation determine if its current risk management processes are sufficient for its business objectives, risk tolerance, and threat environment. They help answer the question, "Are our cybersecurity processes as formal and integrated as they need to be?"

Tiers describe the degree to which an organisation's risk management practices are formalised, ranging from informal and reactive to proactive and data-driven.

From Tier 1 to Tier 4

The four Tiers represent a progression in the formality and integration of cybersecurity risk management. Selecting a target Tier is a strategic business decision, not a race to achieve the highest level.

• Tier 1 (Partial): Risk management is ad-hoc and reactive. Organisational awareness of cybersecurity risk is limited, and processes are applied inconsistently.
• Tier 2 (Risk-Informed): Management has approved some risk management practices, but they are not yet formal, organisation-wide policy. There is an awareness of risk, but coordination remains informal.
• Tier 3 (Repeatable): Formal, approved cybersecurity policies are in place and followed consistently. The organisation understands its dependencies and actively shares threat information.
• Tier 4 (Adaptive): The organisation continuously adapts its cybersecurity practices based on lessons learned and predictive data. It anticipates changes in the threat landscape and uses security insights to inform business strategy.

Ultimately, the Tiers act as a strategic compass. They help an organisation assess its current state, define a realistic target state based on its unique risk profile, and build a roadmap for continuous improvement that aligns security investment with business needs.

A Practical Roadmap for CSF Implementation

Adopting the NIST Cybersecurity Framework is a continuous engineering and governance discipline, not a finite project. It provides the blueprint for ongoing risk management.

Frameworks are conceptual; making them operational requires a repeatable process that translates principles into implemented security controls and measurable outcomes. This practical, seven-step cycle provides such a process.

This cycle ensures that security efforts are tied to business goals, driven by actual risk, and subject to continuous improvement, giving CISOs and their teams a defensible methodology.

Step 1: Prioritise and Scope

Before any technical work begins, it is necessary to determine what is most critical. Attempting to apply the entire framework across the whole organisation simultaneously is impractical and often unnecessary.

Start by identifying the most critical business processes, systems, or data. This is a strategic decision guided by business impact analysis, regulatory obligations, and the organisation's risk tolerance. For example, a financial institution would scope its initial implementation to cover systems processing customer payments, aligning its efforts with both business risk and compliance mandates.

Step 2: Orient and Identify

With the scope defined, the next step is to map the relevant environment. This involves creating inventories of all assets within the defined scope, including hardware, software, data, and dependencies on third-party suppliers.

This phase also requires identifying all applicable legal and regulatory requirements that pertain to these systems. This work directly supports the framework’s Identify function. The objective is to understand the business context, the threat landscape, and the specific assets to be protected.

Step 3: Create a Current Profile

A Current Profile is an objective snapshot of the organisation's current security posture, mapped to the NIST CSF Subcategories. This is not a risk assessment but an inventory of controls that are already in place.

The Current Profile answers the question: "Where are we right now?" You catalogue existing security activities—like firewall rules or backup jobs—and map them to the outcomes described in the framework. This gives you a clear baseline to work from.

For instance, one would document the current user access review process and map it to the relevant Subcategories under the Protect function. The result is a clear depiction of current capabilities against the framework's structure.

Step 4: Conduct a Risk Assessment

With an understanding of the current state, a formal risk assessment is conducted to analyse threats and vulnerabilities within the defined scope. This determines the likelihood and potential impact of a security incident.

This step provides the context needed for informed decision-making, shifting the focus from "what controls we have" to "what risks matter most." This is also where verifiable evidence is critical. You can learn more about structuring and presenting audit evidence in our dedicated guide.

Step 5: Create a Target Profile

The Target Profile defines the desired state of security. Based on the risk assessment and business objectives, the organisation selects the CSF Subcategories and Implementation Tier that represent an appropriate and achievable posture.

This is a strategic document that represents the explicit goal of the security programme and a company-wide agreement on an acceptable level of risk.

Step 6: Analyse and Prioritise Gaps

The next logical step is to compare the Current Profile to the Target Profile. The difference between these two states constitutes the list of security gaps.

However, not all gaps are of equal importance. The risk assessment from Step 4 must be used to prioritise them. A gap associated with a high-impact, high-likelihood risk must be addressed before a gap in a low-risk area. This analysis yields a risk-informed, prioritised action plan.

Step 7: Implement the Action Plan

Finally, the action plan is executed. Resources—budget, personnel, and technology—are allocated to close the identified gaps and implement the controls necessary to achieve the Target Profile.

Implementation is an ongoing cycle of remediation, monitoring, and evidence collection to verify control effectiveness. Upon completion, the cycle begins again. The threat landscape and the business are not static; the NIST CSF is designed for this reality, providing a structure for continuous improvement, not a final destination.

Mapping the NIST CSF to Major Regulations

For organisations subject to DORA, NIS2, and GDPR, managing compliance can become a fragmented and resource-intensive effort.

The NIST Cybersecurity Framework provides a solution by acting as a central, unifying structure. Instead of treating each regulation as a separate project, the CSF can be used to establish a common language for security controls, allowing an organisation to manage them once and use the resulting evidence to satisfy multiple regulatory requirements.

The NIST CSF is the most widely adopted security guide, making it a reliable foundation for a compliance programme that is understood by regulators and auditors.

A Systematic Approach to Mapping

Mapping involves demonstrating that a single, well-managed control also satisfies the requirements of multiple regulations, such as DORA, NIS2, or GDPR. This reframes compliance from the primary goal to a natural output of a well-governed security programme.

The process is systematic:

1. Identify the core requirements of each regulation (e.g., DORA's focus on operational resilience, NIS2's on securing essential services).
2. Recognise the overlap in their fundamental requirements, such as incident response, risk assessment, and access control.
3. Map these common requirements to the corresponding core functions within the NIST CSF.

The principle is: control once, demonstrate many. Instead of generating separate evidence for DORA's incident rules and NIS2’s handling requirements, you map both to the NIST Respond (RS) and Recover (RC) functions. The evidence you generate for your NIST controls becomes the proof for both.

This approach creates significant efficiencies. Technical teams can focus on operating a single, coherent set of controls, while compliance teams can leverage that work to build audit-ready evidence packs for any regulator.

This table provides a high-level overview of how NIST’s Core Functions align with the principles of DORA, NIS2, and GDPR.

Mapping NIST CSF Functions to Common Regulations

As the table demonstrates, activities performed to align with the NIST CSF are not just good practice—they produce the type of demonstrable evidence that European regulators require.

Turning Mapping Into an Auditable System

While the concept of mapping is powerful, its implementation through spreadsheets and shared folders often fails to provide the traceability and integrity that auditors demand. A governance platform is necessary to make this process robust.

A platform operationalises mapping by creating a verifiable link between a regulatory requirement, the control that satisfies it, the evidence that proves its effectiveness, and the individual responsible for it.

This system is built on key capabilities:

• Encrypted Evidence: All proof—from penetration test reports to firewall configurations—is encrypted and tied directly to a control, creating an immutable, auditable record.
• Ownership Matrix: A clear matrix assigns accountability for every control, from implementation to evidence gathering, eliminating ambiguity.
• Audit Pack Generation: The platform can instantly assemble audit packs for a specific regulation, pulling the relevant controls, evidence, and ownership details into an exportable package.

This systematic approach makes compliance demonstrable. It allows an organisation to show that a control for a NIST Subcategory like PR.AC-04 (Access Control) directly satisfies a DORA requirement for access management. The platform connects the policy, the control, the logs proving its operation, and the owner into a complete, defensible record. For a deeper analysis of this topic, refer to our guide on the relationship between compliance, risk, and governance.

By using the NIST CSF as a foundation and a dedicated governance platform to manage the process, an organisation can build a compliance programme that is sustainable, efficient, and demonstrably effective.

Frequently Asked Questions

These are direct answers to the most common questions from leadership and technical teams when implementing the NIST Cybersecurity Framework.

Is the NIST Cybersecurity Framework Mandatory?

For most private-sector organisations, the NIST Cybersecurity Framework is voluntary. However, treating it as optional is a strategic error.

Regulators for frameworks like DORA and NIS2 often point to the NIST CSF as a benchmark for managing cybersecurity risk. While an organisation will not be fined for "not using NIST," it can fail an audit if it cannot demonstrate a structured, risk-based security programme.

Adopting the CSF provides a defensible position by showing adherence to a respected, international methodology. It also establishes a common language understood by internal teams, management, and external auditors.

How Do We Choose the Right Implementation Tier?

Selecting a NIST Tier is not a race to achieve Tier 4. The appropriate Tier depends entirely on an organisation's risk profile, business objectives, and regulatory environment.

The Tiers are not maturity levels. They are a communication tool to align business and security on how formally risk needs to be managed.

Begin with an objective assessment of the current state. A small business may operate effectively at Tier 2 (Risk-Informed), where risk practices exist but are not formalised across the enterprise.

Conversely, a critical infrastructure provider will likely need to target Tier 4 (Adaptive), where security is predictive and integrated into business strategy. The goal is to select a target that is both realistic and appropriate for the risks being managed.

What Is the Difference Between a Profile and a Risk Assessment?

NIST Profiles and risk assessments are often confused. They are related but serve distinct purposes.

• A Current Profile is a descriptive snapshot answering, "Where are we today?" It is created by mapping existing activities and controls to the CSF’s Functions, Categories, and Subcategories.
• A Risk Assessment is an analytical process answering, "What could go wrong, and what would be the impact?" It analyses threats and vulnerabilities to determine the likelihood and impact of a security incident.

The Profile provides context for the risk assessment. The process begins with a Current Profile, is followed by a risk assessment, and then a Target Profile is defined to represent the desired state. The gap between the Current and Target Profiles, prioritised by risk, becomes the roadmap for improvement.

How Does AI Affect Our NIST CSF Implementation?

Artificial Intelligence does not invalidate the NIST CSF, but it requires new considerations, particularly under the Govern function. An AI system should be treated as a system component, for which a human must remain accountable.

The risk management strategy, defined under the Govern function (GV.RM), must now explicitly address AI-related risks, such as model poisoning, data bias, or unintended outputs that create new security vulnerabilities.

Controls must also adapt. For example:

• Under the Protect function, awareness and training (PR.AT) must now educate staff on the limitations and appropriate use of AI tools.
• Data integrity controls become even more critical, as the quality of an AI model's output is entirely dependent on the quality of its training data.

At AuditReady, we provide an operational evidence toolkit built for regulated environments. Our platform helps you centralise control evidence, manage ownership, and generate audit-ready documentation for frameworks like DORA and NIS2, turning the principles of the NIST Cybersecurity Framework into a verifiable reality. Simplify your audit preparation at https://audit-ready.eu/?lang=en.