The CISA Cross-Sector Cybersecurity Performance Goals (CPGs) are a set of 37 prioritized cybersecurity practices published by the Cybersecurity and Infrastructure Security Agency in October 2022. They are not a comprehensive framework. They are a deliberately minimal baseline designed for a specific audience: critical infrastructure organizations, particularly State, Local, Tribal, and Territorial (SLTT) government entities and small operators in critical sectors, that have limited security staff, constrained budgets, and no realistic path to full NIST CSF or CIS Controls implementation in the near term.
The CPGs answer a practical question that more comprehensive frameworks often obscure: if an organization can only do a small number of things, which things reduce the most risk? The answer, organized across eight categories, covers account security, device security, data security, governance and training, vulnerability management, supply chain risk, incident response and recovery, and network segmentation.
The political context for the CPGs matters. They were published in direct response to National Security Memorandum 5 (NSM-5), the Biden administration's July 2021 directive to CISA and NIST to develop cybersecurity performance goals for critical infrastructure. NSM-5 acknowledged a reality that federal cybersecurity policy had long underaddressed: a substantial fraction of critical infrastructure is operated by small entities (municipal water authorities, rural electric cooperatives, community health clinics) that cannot implement enterprise-grade security programs. Creating a tiered baseline for those organizations was itself a governance decision, and one that carries through in how the CPGs are designed and maintained.
The CPGs also serve as a signaling document: CISA is communicating, with specificity, which baseline practices it considers non-negotiable for any organization operating critical infrastructure. When CISA publishes sector-specific guidance or responds to a sector incident, the CPGs are the floor it measures against.
---
Before the CPGs, federal critical infrastructure security guidance was primarily delivered through sector-specific frameworks (the NERC CIP standards for electric utilities, the TSA Security Directives for pipelines and rail, the NIST SP 800-82 guidelines for industrial control systems) and the voluntary NIST Cybersecurity Framework (CSF). These resources are genuinely valuable for organizations with the staff and maturity to use them. The NERC CIP standards, for example, are detailed, enforceable, and produce measurable security outcomes in the electric sector.
The problem is scope asymmetry. NIST CSF contains 108 subcategory outcomes across five functions. CIS Controls v8 contains 153 safeguards across 18 controls. An organization with a part-time IT administrator, no dedicated security staff, and a constrained annual budget for all technology cannot meaningfully engage with that volume of guidance. The result: thousands of critical infrastructure entities were either selecting practices arbitrarily or ignoring federal guidance entirely.
CISA's response was the CPG design: take the full landscape of cybersecurity recommendations, identify the 37 practices with the highest impact-to-effort ratio for resource-constrained operators, and publish them as a cross-sector baseline applicable to any critical infrastructure entity regardless of sector. CISA explicitly mapped the CPGs against CIS Controls Implementation Group 1 (IG1), the subset of CIS Controls designed for organizations with limited cybersecurity expertise, making the CPGs interoperable with the most widely adopted implementation-tier framework.
The CPGs are not static. CISA updates them as the threat landscape evolves and as implementation experience accumulates. They are versioned documents, and organizations implementing them should track updates against the version they initially adopted.
---
The CPGs matter at two levels: for the organizations they directly target, and for the broader governance conversation about what "sufficient" security looks like for critical infrastructure operators.
For SLTT and small critical infrastructure operators. The CPGs provide something that most security frameworks do not: a defensible answer to the question "are we doing enough?" For a small water utility with two IT staff and a $50,000 annual security budget, "are you NIST CSF compliant?" is not a useful question. The CPG self-assessment, by contrast, produces a binary result for each of 37 practices: implemented or not. That creates a prioritized remediation queue and a communication artifact the utility board can understand.
The CPGs also provide political cover. When a municipal government is deciding whether to fund security improvements for a water treatment system or a police department records management system, CPG gaps provide a concrete, federally-endorsed basis for the budget argument. "CISA has identified multi-factor authentication as a baseline requirement for all critical infrastructure operators and we do not have it deployed" is a more actionable statement than "we should improve our security posture."
For the governance conversation broadly. The CPGs represent CISA's implicit baseline for critical infrastructure security. When CISA conducts incident response assistance, reviews sector security posture, or engages with Congress on critical infrastructure protection legislation, the CPGs define what "minimum acceptable" looks like. Organizations that cannot demonstrate CPG compliance face increasing regulatory and liability exposure, particularly as states and federal agencies incorporate CPG practices into grant conditions, contract requirements, and regulatory standards.
What happens without baseline governance. The documented pattern in SLTT breaches (ransomware attacks against municipal governments, attacks against water treatment facilities, hospital system compromises) consistently shows organizations that lacked even the most basic CPG-covered practices: no MFA on remote access, unpatched internet-facing systems, no tested incident response plan, no offline backups. The CPGs were designed specifically to address those failure modes.
Misconception to address. The CPGs are not a certification or compliance requirement for most organizations. CISA does not audit CPG compliance for voluntary sectors. The value of the CPGs is not the attestation; it is the prioritization. Organizations that treat them as a checkbox exercise miss the point. Organizations that use them as a genuine gap analysis and remediation roadmap reduce their actual attack surface.
---
The 37 CPGs are organized across eight categories. What follows covers the substance of each category and the specific practices it includes.
Category 1: Account Security. This category targets the most exploited initial access vectors: credential theft, password attacks, and unauthorized remote access. Specific practices include: implementing phishing-resistant MFA for all privileged accounts and all remote access, establishing strong password policies (minimum length requirements, prohibition of known-compromised passwords), implementing privileged access management to limit standing administrative access, and revoking credentials promptly upon employee separation. The CPGs do not prescribe specific MFA technologies but do distinguish between phishing-resistant forms (hardware security keys, certificate-based authentication) and phishing-susceptible forms (SMS-based OTP).
Category 2: Device Security. This category addresses endpoint and infrastructure security from the asset visibility layer down to device hardening. Practices include: maintaining a comprehensive hardware and software asset inventory, running a vulnerability management program with documented patching cadence for critical and high vulnerabilities, applying secure configuration baselines (disabling unnecessary services, removing default credentials, enabling host-based firewalls), and establishing an end-of-life (EOL) device remediation plan. The EOL practice is specifically called out because resource-constrained operators frequently run equipment years past vendor support end dates, creating unpatched vulnerabilities that cannot be remediated without hardware replacement.
Category 3: Data Security. Practices here address sensitive data identification, protection at rest and in transit, and secure cloud storage configuration. Organizations are expected to maintain a sensitive data inventory, enforce encryption for data at rest and in transit for sensitive data categories, and audit cloud storage configurations to prevent unintentional public exposure. The cloud storage practice reflects the frequency of misconfigured S3 buckets, Azure Blob storage, and GCS buckets exposing operational data for critical infrastructure entities that moved to cloud storage without adjusting their security practices.
Category 4: Governance and Training. This category establishes the organizational accountability and human factors that make technical controls effective. Practices include: designating a cybersecurity responsible role (not necessarily a full-time CISO, but a named individual with accountability), implementing role-based cybersecurity training for all staff, establishing vendor and supplier cybersecurity requirements as part of procurement, and developing and maintaining a cybersecurity policy document. The vendor requirement is foundational: many SLTT breaches enter through managed service providers, software vendors, or third-party remote access tools.
Category 5: Vulnerability Management. Beyond the device-level patching in Category 2, this category addresses organizational vulnerability management process. Practices include establishing a vulnerability disclosure program (a mechanism for external researchers to report vulnerabilities to the organization) and defining a documented patching cadence with tracking against compliance. The vulnerability disclosure practice is notable: CISA is explicitly asking small operators to create a channel for the security research community to help them.
Category 6: Supply Chain and Third-Party Risk. Practices address software acquisition integrity (verifying software sources, avoiding pirated or unverified software), third-party remote access controls (limiting vendor remote access to specific systems, specific times, with logging), and vendor contractual security requirements. This category reflects the operational reality that SLTT entities frequently rely on small regional vendors with their own minimal security practices.
Category 7: Response and Recovery. Practices require a documented and tested incident response plan, offline or immutable backups tested for restoration within a defined recovery time objective, and defined roles for incident response. The offline backup practice is the single CPG most directly correlated with ransomware recovery outcomes: organizations with tested offline backups recover from ransomware events without paying; organizations without them frequently cannot.
Category 8: Other. This catch-all category covers network segmentation between operational technology (OT) and IT networks, a practice particularly important for water, energy, and manufacturing operators where IT compromise can translate to physical process disruption.
Mapping to other frameworks. CISA's CPG documentation includes crosswalk tables mapping each goal to CIS Controls IG1, NIST CSF subcategories, and NIST SP 800-53 controls. This allows organizations already using one of those frameworks to identify their CPG coverage status without a redundant assessment.
---
The CPGs map cleanly across all six PDM domains, which is exactly what you would expect from a cross-sector baseline: real security requires coverage at every layer, and gaps at any layer become entry points.
Account Security and privileged access management sit in IAT (Identity Access and Trust), governed by the Zero Possession Architecture (ZPA) methodology. Device Security and vulnerability management sit primarily in VSD (Vulnerability and Surface Defense), governed by the Continuous Surface Reduction (CSR) methodology. Data Security sits in DPS (Data Protection and Sovereignty), governed by the Sovereign Data Protocol (SDP). Governance and Training, Vulnerability Management process, and Supply Chain risk sit in RGA (Risk Governance and Assurance), governed by the Perpetual Compliance Assurance (PCA) methodology. Response and Recovery sits in TID (Threat Intelligence and Defense) and SPH (Security Posture and Hygiene).
The fact that 37 prioritized practices span all six PDM domains confirms a core PDM design principle: you cannot achieve meaningful security by focusing on one layer. The CPGs, as a minimum baseline for resource-constrained operators, still require all six domains to be addressed, even at a rudimentary level.
CDA's approach to government sector clients uses CPG baseline evaluation as the entry point for security program assessment. The CPG self-assessment produces a gap map that CDA then maps to the PDM Shield visualization: which domains are below baseline, which are at baseline, and where investment is most urgently needed. This gives small SLTT entities an actionable, visually legible picture of their security posture without requiring them to understand the full NIST CSF or CIS Controls architecture.
The PCA methodology specifically addresses the governance and supply chain CPG categories. PCA converts CPG evidence requirements into continuous monitoring: rather than conducting a CPG assessment annually, PCA tracks evidence artifacts (vendor contracts with security clauses, training completion records, backup verification logs, IR plan review dates) in real time, surfacing compliance gaps before they become assessment findings.
For federal grant programs (including CISA SLCGP grants and FEMA BRIC funding with cybersecurity components), CPG gaps directly affect eligibility and scoring. CDA's FRM assessment includes CPG baseline evaluation as a standard deliverable for government sector clients applying for federal cybersecurity funding.
---
---
---