The NIST Cybersecurity Framework (CSF) 2.0, released in February 2024, introduced significant changes that directly impact how organizations should structure their phishing simulation and security awareness programs. The most notable change is the addition of a sixth function, Govern, which elevates cybersecurity risk management to an organizational governance responsibility and includes explicit requirements for human risk management. For organizations that use NIST CSF as their primary security framework, understanding how phishing simulation maps to specific categories and subcategories is essential for both program design and compliance documentation.
How Does Phishing Simulation Map to the Govern Function?
The Govern function (GV) establishes the organizational context, strategy, and supply chain risk management for cybersecurity. GV.AT (Awareness and Training) is the most directly relevant subcategory, requiring that “the organization's personnel are provided cybersecurity awareness and training so that they can perform their cybersecurity-related tasks.” Phishing simulation satisfies this requirement by providing continuous, measurable training that goes beyond awareness into behavioral validation. GV.RM (Risk Management Strategy) is also relevant: your phishing simulation program should be documented as part of your risk management strategy, with clear policies on testing frequency, scope, and remediation procedures. GV.SC (Supply Chain Risk Management) applies when your simulation program extends to third-party vendors and contractors who access your systems.
How Does Simulation Map to Identify, Protect, and Detect?
Under the Identify function, ID.RA (Risk Assessment) requires organizations to identify and assess cybersecurity risks. Phishing simulation data provides quantitative risk assessment for human-layer threats, including click rates, credential submission rates, and department-level vulnerability scores. Under the Protect function, PR.AT (Awareness and Training) requires training that is commensurate with roles and responsibilities. Your simulation program should deliver role-appropriate scenarios: executives receive whaling simulations, finance staff receive invoice fraud simulations, and IT staff receive technical pretexts. Under the Detect function, DE.AE (Adverse Event Analysis) and DE.CM (Continuous Monitoring) are supported when phishing simulation results feed into your SIEM or security monitoring platform, enabling correlation between simulation performance and real incident detection.
How Does Simulation Map to Respond and Recover?
The Respond function (RS) is often overlooked in phishing simulation mapping, but it is directly relevant. RS.AN (Incident Analysis) benefits from simulation data that shows how employees respond to phishing: do they report, ignore, click, or submit credentials? This behavioral data informs your incident response planning by identifying which departments are most likely to be the initial vector for a real attack. RS.CO (Incident Response Reporting and Communication) is supported when your simulation program includes a report button and tracks reporting speed, providing data on your organization's ability to detect and escalate threats at the human layer. The Recover function (RC) is supported indirectly: post-simulation remedial training is analogous to post-incident recovery activities, and documenting these remediation processes demonstrates a mature recovery capability.
How Do You Build a NIST CSF Compliance Evidence Package?
For each NIST CSF category and subcategory that your phishing simulation program supports, maintain an evidence mapping document that includes the NIST CSF reference (for example, GV.AT-01), a description of how your simulation program satisfies the requirement, specific evidence artifacts (campaign reports, training completion records, remediation workflows), the cadence of evidence generation (monthly, quarterly, annually), and the responsible party for maintaining the evidence. This mapping document becomes your primary compliance artifact when auditors or assessors request evidence of NIST CSF alignment. Update it whenever NIST releases guidance updates or when you change your simulation program structure. For related compliance mappings, see our guides on SOC 2 requirements and CMMC 2.0 requirements.