TL;DR
- ISO 27001:2022 alone is 93 controls across 4 themes. CIS Controls v8.1 is 18 controls and 153 safeguards across 3 implementation tiers. No framework is a quick read, and none of them write the enforcing policy for you.
- One Rego policy can close two audit rows at once: a single S3 encryption check that cites both NIST PRs.DS-01 and ISO A.8.24, in their violation messages, satisfy both frameworks with a single rule rather than two.
- Firefly ships prebuilt Policy Packs for CIS, PCI DSS, SOC 2, NIST, and HIPAA, so most teams start with an existing rule set instead of writing 93+ policies in a blank editor.
- 11% of teams call their DR posture "tested and validated," and 30% have little to no confidence they'd hit their RTO, per Firefly's 2026 State of IaC report, numbers that describe organizations with a framework on paper and no continuous way to prove it.
- Firefly's Governance dashboard scores 5 framework-mapped categories continuously, not at audit time, and now extends the same codify-and-drift-detect model to PagerDuty escalation policies through Operations-as-Code
Every mature discipline eventually produces a reference standard: accounting has GAAP, quality management has ISO 9001, and information security has had frameworks for decades. Cyber resilience is going through the same process right now, driven by regulators who grew tired of asking, "Do you have a security policy?" and now ask, "Can you prove you'd recover from a ransomware attack within four hours?"
That shift from policy to provable recovery is why frameworks matter to a technical audience, not just a compliance one. A framework tells an organization what to build and measure. It doesn't tell an engineer which S3 bucket setting satisfies that requirement, how to prove the setting hasn't drifted since the last audit, or how to write the policy code that enforces it. This guide covers what a cyber resilience framework actually is, the major frameworks worth knowing in real technical detail, how to choose among them, who actually writes the technical control that satisfies a framework requirement, and how to prove that control stayed in place over time instead of just being true on the day someone checked.
What Is a Cyber Resilience Framework?
A cyber resilience framework is a published, structured model that defines the capabilities an organization needs to anticipate, withstand, recover from, and adapt to cyberattacks and infrastructure failures. It's a reference document, built by a standards body, regulator, or industry group, not something a single company writes for itself.
That's the distinction worth being precise about: a framework is not the same thing as a resilience strategy. NIST CSF 2.0 is a framework. A specific company's plan to achieve a 1-hour RTO for its payment service, built using the NIST CSF as the reference model, is a strategy. Frameworks give structure and a common vocabulary; strategies are what an organization actually implements against that structure, including the specific tools, policies, and recovery mechanisms it chooses.
Frameworks typically share a few common traits regardless of which one an organization adopts: a small number of top-level functions or domains, a maturity or scoring model to measure progress, and a mapping to specific controls or evidence an auditor can check against. Understanding those shared traits makes it easier to compare frameworks side by side on something more concrete than vibes, which is the next step.
The Major Cyber Resilience Frameworks
Five frameworks recur in cyber resilience conversations, and the vague one-liners that most comparisons use to describe them hide how differently sized and structured they actually are. Each one originated to solve a different problem for a different audience.
Worth flagging if a certification is overdue: ISO 27001:2013 certificates stopped being valid after the transition deadline passed in October 2025, so a 2013-based cert now means a full recertification against the 2022 structure, not a lighter update. NIST CSF 2.0 often serves as the common reference point, even for organizations that formally certify against other standards, since ISO 27001, DORA, and CIS Controls all map to similar underlying functions. That's why it's worth understanding NIST's structure in more detail before considering how to choose among the others.
Why NIST CSF 2.0 Functions as the Common Reference Point
NIST CSF 2.0 organizes cyber resilience work into six functions, and most other frameworks either mirror this structure directly or can be mapped onto it without much distortion.
Govern was added as a standalone function in CSF 2.0, splitting it out from what used to be folded into Identify. That change reflects a real shift in how regulators think about resilience: a technically sound recovery plan that nobody at the leadership level has approved, funded, or tested doesn't count as resilience; it counts as a document. The other five functions describe technical and operational capability. Govern is what makes that capability accountable to someone, a point worth remembering later in this piece when governance processes themselves become something worth codifying, not just the infrastructure they govern.
How to Choose the Right Framework for Your Organization
Choosing a framework isn't about picking the "best" one in the abstract; it's about matching a framework to constraints that are usually already fixed: industry, jurisdiction, and existing compliance obligations.
Most organizations end up mapping to more than one framework over time, not by choice but because different customers, regulators, and investors ask for different ones. A company might build its internal program around NIST CSF 2.0, pursue ISO 27001:2022 certification because enterprise customers require it, and become subject to DORA the moment it starts serving EU financial clients. That layering is normal, and it's exactly why the next problem, translating any of these frameworks into actual technical controls, outweighs which framework sits at the top.
From Framework Language to Enforceable Technical Controls
Every framework speaks in verbs an engineer can't directly implement: protect, detect, govern, restore. A framework that says "protect data at rest" doesn't specify which encryption algorithm, which key rotation policy, or which of the 400 S3 buckets in a given account actually need it applied to. That gap between framework language and infrastructure reality is where most resilience programs stall.
Consider a concrete example. NIST CSF 2.0's Protect function includes a requirement, in plain framework language, that data at rest be protected through appropriate safeguards. ISO 27001:2022's equivalent sits under Annex A.8, the Technological theme, specifically A.8.24 on cryptographic controls. Translated into an actual technical control for a team running AWS, both frameworks converge on the same specific thing: every S3 bucket must have server-side encryption enabled, every EBS volume must be encrypted, and any bucket found without it is a policy violation, not a suggestion.
That translation work has to happen for every requirement in every function, across every resource type an organization runs, which is a genuinely large mapping exercise even for a mid-sized cloud estate: 93 ISO controls, 153 CIS safeguards, six NIST functions, each needing a real answer for what satisfies it technically. Teams that do this manually usually end up with a spreadsheet: one row per control, one column for which framework it maps to, one column for evidence. That spreadsheet is accurate on the day it's created and stale within weeks, since nothing keeps it synchronized with what's actually running in the cloud, and it still leaves open the question this guide keeps returning to: someone has to actually write the policy that enforces each row.
Who Actually Writes the Policy That Enforces a Requirement
This is the step most framework guides skip entirely. "Protect data at rest" becomes "S3 encryption required" on a slide, and the slide moves on as if the translation is finished. It isn't. Somebody has to produce the actual Rego policy, AWS Config rule, or Terraform module that checks for encryption and flags the resources that don't have it, and that work has four realistic paths.
Writing Rego by hand is the most direct path and the one that assumes the most from whoever's doing it. A policy enforcing the S3 encryption requirement looks like this:
package firefly.nist.protect.data_at_rest
deny[msg] {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket"
not resource.change.after.server_side_encryption_configuration
msg := sprintf("S3 bucket %v is missing server-side encryption, violating NIST CSF Protect (PR.DS-01) and ISO 27001 A.8.24", [resource.address])
}Note the msg field doing double duty: it names the specific violation and cites the framework that controls it, which makes this policy's evidence usable across a NIST audit and an ISO audit simultaneously, instead of writing the check twice.
A no-code policy builder removes the Rego-writing step for attribute-based or tag-based rules, letting someone define "flag any S3 bucket without encryption enabled" through a form rather than code, at the cost of flexibility for anything more conditional than a straightforward attribute check.
AI-assisted generation from a plain-English description is the closest thing to a direct framework-to-control translator: describing the requirement in the same language the framework uses, "S3 buckets must have server-side encryption enabled," and having the system generate the Rego policy directly, then validating it against real assets in a testing playground before it goes live, rather than discovering a syntax error or an overly broad match during a live audit.
Starting from a pre-built Policy Pack skips the authoring step entirely for common requirements. Rather than writing the S3 encryption check from scratch, a pack built for CIS, PCI DSS, SOC 2, NIST, or HIPAA ships with that control already defined, tested, and ready to enable. This is the realistic starting point for most teams, since most of what a framework requires (encryption, tagging, public access blocks, retention windows) isn't unique to any one organization, and writing it from a blank slate is effort spent reinventing something that already exists in a maintained package.
None of these four paths is universally correct. A security team with Rego experience and a genuinely unusual requirement writes it by hand. A platform team standardizing 40 straightforward tagging and encryption checks turns to the no-code builder. A team racing to close a gap before an audit deadline, without someone on hand who knows Rego, uses AI generation and reviews the output in the testing playground before trusting it. A team that's just getting a framework program started enables the relevant Policy Pack first and writes custom policies only for what the pack doesn't cover.
Reusing Logic Across Frameworks Instead of Rewriting It Per Audit
The S3 encryption example above satisfies both a NIST control and an ISO control with a single policy, which points to greater efficiency: most frameworks overlap heavily in the underlying technical requirements, even when their language and numbering differ completely. Writing the same encryption check three separate times, once per framework an organization happens to be audited against, is exactly the kind of duplicated effort that makes manual framework mapping collapse under its own weight.
Rego Packages solve this by making shared logic reusable rather than copy-pasted. A helper module defining what "properly encrypted" means across resource types can be written once and imported into every policy that needs it:
package firefly.packages.encryption_baseline
is_encrypted(resource) {
resource.type == "aws_s3_bucket"
resource.change.after.server_side_encryption_configuration
}
is_encrypted(resource) {
resource.type == "aws_ebs_volume"
resource.change.after.encrypted == true
}A NIST-mapped policy, an ISO-mapped policy, and a PCI DSS-mapped policy can all import data.firefly.packages.encryption_baseline and call is_encrypted() rather than each defining their own version of the same check. Editing the package once, say, to add support for a new resource type, updates every policy that imports it at the next evaluation, without anyone having to remember which of a dozen framework-specific policies also needs the same edit. A few hard limits apply to keep this reliable: packages max out at 50 KB, individual lines can't exceed 1,000 characters, and package names can't change after creation, small constraints that keep a shared package from becoming an unmanageable dependency in its own right.
Where Manual Framework Mapping Breaks Down at Scale
The spreadsheet approach fails for the same reason static documentation fails everywhere else in cloud infrastructure: the cloud keeps changing after the mapping is done. A resource that was compliant when the spreadsheet was built can drift out of compliance the moment someone changes a setting in the console, and nothing updates the spreadsheet to reflect the change.
Firefly's 2026 State of IaC report found that only 11% of teams describe their disaster recovery posture as tested and validated, and 30% have little to no confidence they could restore within their recovery time objective. Those numbers describe organizations that likely have a framework and a documented strategy on paper; the gap is between what's documented and what's actually true of the live environment at any given moment. A framework mapping that isn't continuously verified against live infrastructure is functionally equivalent to not having one; it just looks better in an audit folder.
This is also where auditors have gotten sharper. A framework audit used to accept a point-in-time screenshot as evidence. Increasingly, auditors want to see that a control has been in place continuously, not just that it was true on the day someone checked. That requirement, continuous evidence instead of point-in-time evidence, is what makes framework compliance genuinely difficult to sustain by hand.
How Severity and Remediation Paths Tie Back to Framework Risk
Not every violated control carries the same weight, and treating them all identically either buries the genuinely urgent ones in noise or blocks deployment over something trivial. Policies carry five severity levels: Info, Low, Medium, High, and Critical, which is what lets a missing tag and a publicly exposed database sit in the same policy category without competing for the same attention.
When something fails, remediation runs one of two paths. IaC Remediation opens a pull request against the underlying code, the recommended path for anything that should go through normal review. Direct Cloud Remediation runs a CLI command against the live resource instead, reserved for unmanaged resources that have no IaC representation to patch, or for genuine emergencies where waiting for a PR cycle isn't acceptable:
# Direct Cloud Remediation for an unmanaged, non-compliant S3 bucket
firefly remediate --asset-id s3-prod-logs-8821 \
--policy nist.protect.data_at_rest \
--action enable-encryption \
--mode directA Critical-severity finding under a DORA-relevant control and a Low-severity tagging gap under the same framework mapping don't get the same treatment, and shouldn't, which is exactly what severity tiering is for.
How Firefly Maps Live Infrastructure to Framework Requirements
Firefly's Governance dashboard organizes built-in policies into categories that directly mirror the frameworks covered above: NIST, CIS, SOC 2, PCI DSS, HIPAA, and a dedicated Resiliency category built specifically around recovery-blocking configurations, which sit alongside the Built-in Policies, Custom Policies, and Policy Packages tiles. DORA doesn't get its own tile, but Firefly's continuous compliance scoring rolls up into it; the requirements DORA cares about (data protection, resilience testing, ICT risk management) largely overlap with what the NIST, SOC 2, and Resiliency categories already check for. Each policy row shows severity, the specific assets it applies to, a live compliance percentage, and a count of violating assets, so a framework's abstract requirement and the exact resources failing to meet it sit in the same view.
In practice, this produces a dashboard where compliance is a set of live numbers rather than a claim: a real Firefly environment might show SOC 2 at 91%, HIPAA at 96%, NIST at 88%, and PCI DSS at 91%, each derived directly from current infrastructure state rather than assembled by hand before an audit. A score that drops from 91% to 84% overnight is a signal something changed, worth investigating immediately, not something that surfaces three months later during the next audit cycle.
Firefly Governance dashboard filtered to NIST showing 88% compliance
That mapping stays current because it's built on the same continuous scanning that powers Firefly's Cloud Asset Inventory, not a periodic audit scan. When a resource drifts out of compliance with a mapped control, whether that's an unencrypted S3 bucket under NIST's Protect function or a missing snapshot policy under the Resiliency category, the violation shows up immediately, with an AI remediation option that generates the actual fix rather than only flagging the gap. Framework compliance becomes a live number rather than a document that's accurate until the next change. This continuous model is part of why Firefly was named in Gartner's 2026 Hype Cycle for Site Reliability Engineering under a newly defined "Continuous Resilience Automation" category, built around exactly this shift from periodic audits to always-current posture.
For teams that need to check framework status without opening the dashboard, AI SRE answers questions like "which resources are missing encryption under our NIST mapping" directly, pulling from the same live Governance and Inventory data and surfacing them in priority order, so the team knows what to remediate first, not just what's non-compliant. Every policy check, violation, and remediation is logged in Event Center, which turns "we're in compliance" from a claim into something an auditor can verify against a timestamped, tamper-evident history rather than a static spreadsheet.
The same query works entirely from outside the dashboard. Firefly's MCP server exposes live Governance and Inventory data to tools like Claude Code and Cursor, so a compliance question can be asked from inside an IDE during a pre-audit review without ever opening the Firefly UI, and Firefly's REST API (api.firefly.ai/v2/, authenticated with the same access key and secret key pair used elsewhere in the platform) covers the same data for teams building their own compliance reporting on top of it, whether that's a scheduled Slack digest of framework scores or a feed into an internal audit dashboard.
Codifying the Governance Process Itself: Operations-as-Code
Governance isn't limited to infrastructure resources either. Firefly's Operations-as-Code capability extends the same codify-and-drift-detect model to the tools a Govern-function response actually runs on. PagerDuty escalation policies and on-call schedules are a direct example: once codified, a manually altered escalation path gets treated the same way an unencrypted S3 bucket does, as drift from a codified, auditable baseline, not a change that only gets noticed when it causes a problem during an actual incident.
resource "pagerduty_escalation_policy" "framework_incident_response" {
name = "framework-critical-escalation"
num_loops = 2
rule {
escalation_delay_in_minutes = 10
target {
type = "schedule_reference"
id = pagerduty_schedule.security_oncall.id
}
}
}For a Govern function specifically, this closes a gap that's easy to miss: a framework can require documented, tested incident escalation, and a team can genuinely have that process defined, right up until someone edits it manually during a live incident and the change never makes it back into the documentation. Codifying the escalation policy itself means that drift shows up the same way as any other policy violation, rather than only being discovered when the process is next tested.
Building Audit-Ready Evidence Instead of Assembling It Manually
The practical payoff of mapping frameworks to live infrastructure shows up at audit time, which is usually when the gap between documented compliance and actual compliance gets discovered the hard way. Instead of an engineer spending a week before an audit pulling screenshots and cross-referencing tickets, the evidence already exists as a continuous, timestamped record.
That record covers three things auditors consistently ask for: which controls map to which framework requirements, the current compliance percentage for each, and a change history showing whether a control held steady, drifted, or was fixed. Assembling that manually, even across a modest cloud estate, is the kind of work that eats up the two weeks before a SOC 2 or DORA audit every single cycle. Automating the mapping doesn't remove the audit; it removes the fire drill that usually precedes it.
Where Should You Start With a Cyber Resilience Framework?
Starting with the framework a regulator or customer already requires beats starting from a blank slate; most organizations don't get to choose freely, and that's fine. The bigger question is whether its requirements are mapped to something specific enough for an engineer to implement, a Policy Pack, hand-written Rego, a no-code rule, or an AI-generated policy, and specific enough for a tool to verify continuously, rather than living in a policy document nobody checks against the live environment.
The fastest way to know where an organization actually stands isn't picking a framework; it's finding out what percentage of the current environment would pass one. Explore Firefly's Governance dashboard to see that number for NIST, CIS, SOC 2, and PCI DSS against a live environment, or start from a pre-built Policy Pack instead of a blank spreadsheet.
FAQs
What is a cyber resilience framework?
A cyber resilience framework is a published, structured reference model, such as NIST CSF 2.0 or ISO 27001, that defines the capabilities an organization needs to anticipate, withstand, recover from, and adapt to cyberattacks and infrastructure failures. It's a reference standard, not a company's specific implementation plan.
What is the difference between a cyber resilience framework and a cyber resilience strategy?
A framework is a published reference model built by a standards body or regulator. A strategy is what a specific organization implements, using one or more frameworks as references, including the tools, policies, and recovery mechanisms chosen to meet those requirements.
Which cyber resilience framework should I use?
The right framework depends more on industry and jurisdiction than on preference: DORA is mandatory for EU financial entities, ISO 27001:2022 is the most commonly requested certification for enterprise vendor requirements, and NIST CSF 2.0 is the most widely adopted general-purpose starting point for US-based organizations without a specific regulatory mandate.
How many controls does ISO 27001 actually have?
ISO 27001:2022 lists 93 controls in Annex A, organized into four themes: Organizational (37), People (8), Physical (14), and Technological (34). This replaced the 2013 version's 114 controls across 14 domains, and organizations had until October 31, 2025 to transition; certificates issued against the 2013 version are no longer valid.
Who writes the technical policy that enforces a framework requirement?
There are four realistic paths: starting from a pre-built Policy Pack for common requirements, writing the policy code (typically Rego) directly, using a no-code policy builder for straightforward attribute or tag-based checks, or generating the policy from a plain-English description of the requirement and validating it in a testing playground before it goes live.
How does Firefly help with compliance with cyber resilience frameworks?
Firefly's Governance dashboard maps live infrastructure directly to framework-specific policy categories, including NIST, CIS, SOC 2, PCI DSS, and HIPAA, and continuously scores compliance rather than at a point in time. Policies can start from a pre-built Policy Pack, be authored by hand, built with a no-code builder, or generated from plain English. AI remediation then generates fixes for violations directly, with every check logged for audit evidence.
Does Firefly support DORA compliance specifically?
DORA doesn't have its own dedicated policy tile in Firefly's Governance dashboard, but its requirements are largely covered by the NIST, SOC 2, and Resiliency categories that do exist, and Firefly's audit-ready evidence explicitly covers DORA alongside SOC 2 and ISO. For an organization subject to DORA, the practical approach is mapping its specific requirements against those existing categories rather than looking for a single DORA-labeled switch to turn on.
Can framework compliance data be pulled outside the Firefly dashboard?
Yes. Firefly's MCP server exposes live Governance and Inventory data to tools like Claude Code and Cursor, and the REST API (api.firefly.ai/v2/) covers the same data for teams building custom compliance reporting, such as a scheduled digest of framework scores or a feed into an internal audit system.
.avif)
.avif)
.webp)
.webp)
