Cybersecurity Frameworks: NIST, ISO, and CIS

Cybersecurity frameworks give an organization a common vocabulary and a structured checklist to work from, instead of every team improvising its own definition of “secure.” The three that most enterprises actually use are the NIST Cybersecurity Framework (CSF), ISO/IEC 27001, and the CIS Controls. They overlap a lot, but each has its own shape and its own reason for existing, and knowing them matters as much on the offensive side as the defensive one, since a red team engagement’s findings usually end up mapped back into whichever framework the customer runs on.

NIST Cybersecurity Framework

#

The NIST CSF is a voluntary, risk-based framework originally developed in response to Executive Order 13636 (2013) and released in 2014. The version most people learned it as, CSF 1.1, had five functions: Identify, Protect, Detect, Respond, Recover.

That’s outdated as of February 2024. CSF 2.0 added a sixth function, Govern, which sits at the center of the framework and informs how the other five are implemented rather than being a bolt-on. Any current reference to the CSF should use the six-function structure:

• Govern: cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.
• Identify: current cybersecurity risks are understood, including assets, dependencies, and vendor relationships.
• Protect: safeguards to manage those risks are in place, including access control, awareness training, and protective technology.
• Detect: possible cybersecurity attacks and compromises are found and analyzed, via continuous monitoring, vulnerability assessment, and detection processes.
• Respond: actions on a detected incident are taken, including incident response, communication, and forensic analysis.
• Recover: assets and operations affected by an incident are restored, including backup restoration, validation, and lessons-learned review.

Govern was added specifically because CSF 1.1’s five functions covered the operational security lifecycle well but left supply chain risk, vendor management, and organizational cybersecurity governance implicit. CSF 2.0 makes those first-class. Red teams and pentesters mostly still map their findings against Identify/Protect/Detect/Respond, but understanding where Govern fits matters for how those findings get consumed by the customer’s leadership.

ISO/IEC 27001

#

ISO/IEC 27001 is the international standard for information security management systems (ISMS). It’s more formal and audit-oriented than the NIST CSF; organizations pursue ISO 27001 certification, they don’t usually pursue CSF certification. The current version is ISO/IEC 27001:2022, published October 2022, which superseded the 2013 revision most references online still describe.

The standard has two parts. The main body has 10 numbered clauses covering the ISMS itself (clause 0 is the introduction and isn’t counted toward the ten):

1. Scope
2. Normative References
3. Terms and Definitions
4. Context of the Organization
5. Leadership
6. Planning
7. Support
8. Operation
9. Performance Evaluation
10. Improvement

These describe how the ISMS itself is built, run, and audited. They haven’t changed structurally between the 2013 and 2022 revisions.

The Annex A control set is where the technical and organizational controls actually live, and it was substantially restructured in the 2022 revision. The old 14 control domains (114 controls) were reorganized into 93 controls under 4 themes: Organizational (37 controls), People (8), Physical (14), and Technological (34). If you see references to “ISO 27001’s 14 sections” or “114 controls,” they’re describing the 2013 version’s Annex A, not the current standard.

For most organizations, ISO 27001’s practical value is that it’s directly aligned with common regulatory requirements (HIPAA, PCI DSS, GDPR), so the same ISMS documentation that gets you certified also does a lot of the compliance work. For red teams, ISO 27001-shaped engagements typically emphasize access control, asset management, and cryptographic controls in Annex A’s Technological theme.

CIS Controls

#

The CIS Controls are a prioritized set of cybersecurity best practices maintained by the Center for Internet Security. The current version is v8.1 (June 2024), which added a Governance element aligned with NIST CSF 2.0’s Govern function. v8 (May 2021) is where the structure most references still describe was set.

Two things about the current CIS Controls that a lot of older material gets wrong:

There are 18 controls, not 20. v8 consolidated the older v7/v7.1 structure (20 controls organized as Basic, Foundational, Organizational) into 18 controls organized differently. Any reference to “20 controls” or the Basic/Foundational/Organizational split is describing v7, which is two versions behind.

Controls are grouped by Implementation Group (IG), not category. IG1 (56 safeguards) is the essential baseline every organization should be able to implement; IG2 (adds 74 more) covers organizations with more resources or higher risk; IG3 (adds another 23, for the full 153-safeguard set) is for organizations facing sophisticated attackers or handling highly sensitive data.

The 18 current controls, in v8 order:

1. Inventory and Control of Enterprise Assets
2. Inventory and Control of Software Assets
3. Data Protection
4. Secure Configuration of Enterprise Assets and Software
5. Account Management
6. Access Control Management
7. Continuous Vulnerability Management
8. Audit Log Management
9. Email and Web Browser Protections
10. Malware Defenses
11. Data Recovery
12. Network Infrastructure Management
13. Network Monitoring and Defense
14. Security Awareness and Skills Training
15. Service Provider Management
16. Application Software Security
17. Incident Response Management
18. Penetration Testing

For red teams and pentesters, Control 18 (Penetration Testing) is where the CIS Controls formally include what you’re doing, and the customer’s IG level is a useful signal for what depth of testing they’re expecting.

How the frameworks fit together

#

The three overlap heavily but aren’t interchangeable. A rough characterization:

• NIST CSF is a strategic framework: functions and categories, no prescriptive controls. Good for organizing risk conversations at the executive level and mapping across other frameworks.
• ISO/IEC 27001 is an ISMS certification standard: prescriptive audit requirements plus a mandatory control set (Annex A). Good when you need a formal, internationally recognized certification.
• CIS Controls are a prioritized safeguard list: concrete, technical, tell-you-what-to-do controls with implementation guidance. Good for teams that want a defensible technical baseline without ISO’s audit overhead.

Most mature security programs use more than one, typically CSF as the strategic overlay, CIS Controls as the technical baseline, and ISO 27001 as the certification vehicle when the business needs it.

Real-world examples

#

SolarWinds

#

The 2020 SolarWinds compromise (SUNBURST) is often cited as an argument for the CSF, but the framing that “Identify and Protect would have prevented it” doesn’t really hold up. SolarWinds was a software supply chain attack: attackers breached SolarWinds’ build environment and trojanized signed Orion updates, which victim organizations then installed through normal, trusted vendor channels. That specific delivery mechanism defeats most Protect-function controls because the malicious code arrived as a legitimate, digitally signed update from a trusted vendor.

The parts of the CSF that would actually have mattered:

• Govern and Identify (specifically supply chain risk management, which is why CSF 2.0 elevated Govern) could have reduced blast radius via vendor risk assessment, network segmentation, and reducing the number of systems that trust a given vendor’s software.
• Detect was what actually surfaced the attack (FireEye’s own detection, December 2020, based on anomalous outbound C2 traffic from a “trusted” Orion binary).
• Respond was what contained it.

The lesson isn’t “Identify would have prevented it,” it’s “no single function would have; the framework works because it forces you to think about all of them together.”

WannaCry

#

WannaCry (May 2017) hit organizations that hadn’t applied MS17-010, released a month earlier in March 2017. The CIS Continuous Vulnerability Management control (Control 7 in v8) points directly at the patch gap, but the full story needs a few more controls to explain why some organizations that had patched their known assets still got hit:

• Asset inventory (Control 1): you can’t patch what your inventory doesn’t know about. Shadow IT, unmanaged assets, and forgotten legacy systems were WannaCry infection vectors for organizations that thought their patching was complete.
• Legacy/embedded systems: medical devices, ICS, and older Windows versions that couldn’t be patched on the normal cycle carried the vulnerability well past the patch date.
• Network segmentation (Control 12): WannaCry’s worm behavior relied on SMBv1 being reachable between systems. Flat internal networks let one infected host reach everything else; segmented networks limited the blast radius.

So the modernized read is: patch management would have closed the primary vector, but a comprehensive CIS Controls implementation covers the other gaps that let the attack propagate anyway. That’s a stronger argument for the framework than “one control would have stopped it.”

Conclusion

#

The frameworks aren’t interchangeable, and they’re not static either. NIST CSF 2.0’s Govern function and its emphasis on supply chain risk, ISO/IEC 27001:2022’s restructured Annex A, and CIS Controls v8/v8.1’s move from 20 category-grouped controls to 18 IG-organized ones are all recent enough that a lot of online material is still describing older versions. If you’re referencing any of these in a report or an engagement, worth checking that you’re citing the current revision rather than what you learned three years ago.