Skip to main content
Readiness Authority
Category: Security Controls

CISA Cybersecurity Performance Goals

Also known as: CPGs, Cross-Sector Cybersecurity Performance Goals, Cybersecurity Performance Goals 2.0, CPG 2.0
Simply put

The CISA Cybersecurity Performance Goals are a voluntary set of recommended cybersecurity practices published by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to help organizations, particularly those in critical infrastructure, improve their defenses. They are meant to work for organizations of all sizes and levels of cybersecurity experience by identifying a prioritized subset of practices rather than a complete security program. They are guidance and best-practice goals, not an insurance policy term and not a mandatory regulation on their own.

Formal definition

The Cross-Sector Cybersecurity Performance Goals (CPGs) are a prioritized subset of cybersecurity practices selected by CISA through an industry engagement process and intended as a common baseline of protections for critical infrastructure entities across sectors. The CPGs are organized around functional categories reflected in CISA's materials, including Identify, Protect, Detect, Respond, and Recover, along with incident planning and preparedness, and the 2.0 revision emphasizes measurable actions. As a security and resilience framework, the CPGs describe controls and outcomes; they are distinct from cyber insurance policy terms such as coverage triggers, retentions, or sublimits, and adoption of the CPGs does not itself constitute risk transfer. Whether alignment with the CPGs affects underwriting, premium, or the applicability of failure-to-maintain-standards exclusions depends on the specific insurer, policy wording, and jurisdiction, and is outside the scope of the CPGs themselves. Precise version dates, adoption figures, and any regulatory mandates tied to the CPGs should be verified against current CISA materials rather than assumed.

Why it matters

For organizations that lack the resources to build a comprehensive security program from scratch, the CPGs offer a prioritized, voluntary starting point rather than an exhaustive checklist. By identifying a common baseline of protections intended to work for critical infrastructure entities of all sizes and levels of cyber maturity, they help organizations focus limited budgets and staff on a defined subset of practices. This prioritization matters most to smaller entities and those early in their cybersecurity journey, who may struggle to interpret and implement broader frameworks in full.

For insurance and risk transfer professionals, the CPGs are relevant as a reference point for organizational hygiene, but they are a security and resilience framework, not a policy term. Adopting the CPGs does not transfer risk, does not by itself constitute resilience, and does not reduce the likelihood of an incident being covered under any particular policy. Whether alignment with the CPGs influences underwriting appetite, premium, or the applicability of exclusions such as failure-to-maintain-standards provisions depends entirely on the specific insurer, policy wording, and jurisdiction. Those questions sit outside the CPGs themselves and should not be assumed from adoption alone.

The CPGs also evolve. The 2.0 revision emphasizes measurable actions, which can make it easier for an organization to demonstrate progress internally, but users should verify current version details, functional categories, and any sector-specific expectations against live CISA materials rather than relying on a static understanding. Because the CPGs are voluntary guidance and not a mandatory regulation on their own, their weight in any given context is a matter of how organizations, regulators, or counterparties choose to reference them.

Who it's relevant to

CISOs and security leaders
Security leaders can use the CPGs as a prioritized baseline to focus effort on a defined subset of high-value practices, particularly where a full framework implementation is not immediately feasible. The 2.0 emphasis on measurable actions supports internal tracking of progress, but the CPGs are a starting point, not a complete security program, and do not substitute for a broader controls framework.
Resilience and continuity planners
Because the CPGs include Respond and Recover functions alongside incident planning and preparedness, they touch on capabilities relevant to continuity and recovery planning. The CPGs describe outcomes and controls at a baseline level and do not replace detailed business continuity or disaster recovery planning, nor do they define recovery metrics such as RTO or RPO.
Underwriters and insurance brokers
Underwriters and brokers may encounter the CPGs as a reference for an applicant's cybersecurity hygiene. However, the CPGs are guidance, not a policy term, and adoption does not by itself affect coverage. Whether CPG alignment influences underwriting, premium, or the applicability of exclusions such as failure-to-maintain-standards provisions depends on the specific insurer, policy wording, and jurisdiction.
Critical infrastructure operators
CISA presents the CPGs as a common set of protections intended for all critical infrastructure entities, from large to small. Operators can use them to establish or benchmark a baseline, while confirming current version content and any sector-specific expectations directly against CISA materials. The CPGs remain voluntary guidance and are not a mandatory regulation on their own.
Legal and compliance professionals
Compliance teams may reference the CPGs when evaluating baseline expectations or contractual security commitments. Because the CPGs are voluntary and defined by CISA rather than a regulator, any legal or regulatory weight they carry in a given context should be verified against applicable law and current CISA publications rather than assumed.

Inside CPGs

Voluntary Baseline Practices
A set of prioritized, voluntary cybersecurity practices published by the U.S. Cybersecurity and Infrastructure Security Agency intended to help organizations, particularly in critical infrastructure sectors, establish a foundational security posture. They are guidance rather than a binding regulation, though they may be referenced or incorporated by other regimes.
Cross-Sector Focus
The goals are designed to be broadly applicable across critical infrastructure sectors rather than tailored to a single industry, offering a common reference point. Sector-specific requirements or supplemental goals may apply differently depending on the sector and its lead agency.
Prioritization by Risk and Impact
The practices are organized to help resource-constrained organizations prioritize actions expected to yield meaningful risk reduction, rather than presenting an exhaustive control catalog. This is a risk mitigation orientation, distinct from risk transfer through insurance.
Alignment with Established Frameworks
The goals are generally intended to complement, not replace, broader frameworks and standards. As a security and resilience guidance construct, they are not policy terms and do not themselves define insurance coverage triggers, sublimits, or retentions.
Practice Areas Spanning People, Process, and Technology
The guidance addresses foundational hygiene topics such as access management, threat detection, response and recovery readiness, and governance. The specific organization and labeling of these areas should be confirmed against the current published version rather than assumed.

Common questions

Answers to the questions practitioners most commonly ask about CPGs.

Do the CISA Cybersecurity Performance Goals count as a coverage requirement or trigger under a cyber insurance policy?
No. The CPGs are a voluntary set of prioritized security practices published by CISA; they are a resilience and security reference, not an insurance policy term. Whether an insurer references, requires, or credits alignment with the CPGs depends entirely on the specific application, underwriting guidelines, endorsements, and policy wording. The CPGs do not by themselves create, trigger, or extend coverage, and they should not be confused with coverage conditions, warranties, or conditions precedent that a particular insurer may impose separately.
Does implementing the CPGs make an organization compliant with mandatory regulations or a formal framework like NIST CSF?
Not on their own. The CPGs are intended as a baseline, prioritized subset of practices and are not a comprehensive framework or a regulatory compliance regime. They are informed by and map toward broader references such as the NIST Cybersecurity Framework, but adopting the CPGs does not equate to full framework implementation or satisfy any specific statutory or sector regulatory obligation. Organizations should treat them as a starting baseline and confirm separately what any applicable regulation, standard, or contract actually requires.
How should we prioritize which CPGs to implement first?
The CPGs are structured as prioritized, high-impact practices intended to be broadly achievable, which makes them useful as an initial baseline rather than an exhaustive program. In practice, organizations commonly sequence implementation against their own risk assessment, existing control gaps, and threat exposure. Because the goals are outcome-oriented, prioritization typically considers which gaps present the greatest likelihood or impact of an incident for that specific organization. This is a mitigation exercise; it reduces likelihood or severity but does not transfer residual risk, which remains a separate decision involving insurance, acceptance, or avoidance.
Can we use the CPGs to demonstrate our security posture to an underwriter?
You can present CPG alignment as one input into an underwriting conversation, but whether and how an insurer weighs it varies. Underwriters differ in the frameworks and control sets they recognize, and some may map their questions to their own standards rather than the CPGs. Any representation you make about your control posture may be relevant to application warranties or misrepresentation provisions, so accuracy matters. Alignment with the CPGs is not a substitute for the specific attestations, questionnaires, or evidence an insurer requires, and it does not guarantee more favorable terms.
Do the CPGs address business continuity and disaster recovery, or only security controls?
The CPGs emphasize prioritized security practices and incident-related readiness, but they are not a substitute for a formal business continuity or disaster recovery program. Continuity planning, defined recovery time objectives (RTO) and recovery point objectives (RPO), and disaster recovery capabilities are distinct disciplines addressed more directly by standards oriented to those functions. Organizations relying on the CPGs should confirm separately that their resilience planning defines and tests these objectives rather than assuming the CPGs cover them.
How do the CPGs relate to the rest of our resilience and risk-transfer strategy?
The CPGs sit within risk mitigation: they aim to reduce the likelihood or impact of incidents through improved security practices. They do not, by themselves, constitute resilience, and they do not transfer financial risk. A complete strategy typically pairs mitigation practices like the CPGs with continuity and recovery planning, incident response and crisis management processes, and a deliberate treatment of residual risk through insurance, acceptance, or avoidance. Insurance in particular addresses financial consequences after an event and does not reduce the probability that an incident occurs.

Common misconceptions

The CISA Cybersecurity Performance Goals are a mandatory regulation that organizations must comply with.
They are voluntary baseline guidance. While they may be referenced by regulators, insurers, or contracts, they are not in themselves a legally binding compliance mandate, and whether they carry obligation depends on the specific regime or agreement that adopts them.
Meeting the goals guarantees cyber insurance coverage or satisfies underwriting requirements.
The goals are a security and resilience construct, not policy terms. Insurers set their own underwriting criteria, and whether any loss is covered depends on the specific policy wording, endorsements, exclusions, and conditions. Alignment with the goals may support an application but does not create or guarantee coverage.
Adopting the goals makes an organization resilient or eliminates cyber risk.
The goals represent risk mitigation intended to reduce likelihood and impact of incidents; they do not eliminate risk, do not by themselves constitute a business continuity or disaster recovery capability, and are distinct from risk transfer. Resilience also requires tested recovery objectives, incident response, and crisis management capabilities.

Best practices

Treat the goals as a prioritized starting point for foundational security hygiene, not as a complete control set or a substitute for a broader framework your organization may already use.
Map the goals against controls you already have in place to identify gaps, and document your rationale where you deviate or defer, since that record can support both risk decisions and insurance applications.
Keep security and resilience efforts distinct from insurance decisions: use the goals to reduce likelihood and impact, and separately evaluate risk transfer, retention, avoidance, and acceptance for residual exposure.
Confirm the current published version and any sector-specific supplements that apply to your organization rather than relying on prior or generic versions.
Pair adoption with tested recovery capabilities by defining and validating recovery time and recovery point objectives, incident response procedures, and crisis management plans, since the goals alone do not establish these.
When engaging brokers or underwriters, present evidence of implementation qualitatively and accurately, recognizing that alignment may inform underwriting but does not determine coverage, which remains subject to the specific policy wording.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.