CISA Cybersecurity Performance Goals
a voluntary baseline for internal security teams

CISA Cybersecurity Performance Goals explained

The CISA Cybersecurity Performance Goals (CPGs) are the voluntary, prioritised cybersecurity baseline the Cybersecurity and Infrastructure Security Agency publishes for owners and operators across the sixteen critical infrastructure sectors and any organisation that wants a defensible operating floor. The CPGs are not a regulation. They are not a certification. They are a curated, cost-rated, complexity-rated, impact-rated subset of cybersecurity practices that CISA recommends as the minimum reasonable baseline.

CPGs v2.0, released in 2024, restructured the goal set against the NIST CSF 2.0 functions (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER) and consolidated the cross-sector goal list at 38 goals. Each goal carries a defined Outcome, the Risks Addressed, the Recommended Action, and a rating on cost, complexity, and impact, plus an explicit mapping to NIST CSF 2.0 subcategories so the goal-to-subcategory walk is published rather than improvised.

For internal security teams, AppSec leaders, vulnerability management programmes, GRC owners, and CISOs, the CPGs are the most frequently asked-after baseline below NIST CSF 2.0 and alongside NIST CSF 2.0, CIS Controls, and Essential Eight. Programmes adopt them because the cost-complexity-impact rating turns prioritisation from argument into arithmetic, and the evidence the goals expect is the same operating record an internal security team is already building.

The six CPG functions in CPGs v2.0

CPGs v2.0 reorganises the goal set under the NIST CSF 2.0 function structure. The function ordering below mirrors the published goal numbering and is the order most adoption sequences follow. Each function carries a different evidence weight and a different audit cadence, and the functions compose into a continuous baseline rather than a one-time rollout.

The 38 cross-sector goals at a glance

The 38 cross-sector goals are the floor every critical infrastructure operator and most non-critical operators with comparable risk profiles can read against. The summary below groups the goals by function and names the operating outcome each function carries; the published CPG document carries the full goal-by-goal text, the cost rating, the complexity rating, the impact rating, and the recommended action per goal.

How the CPGs map into NIST CSF 2.0 subcategories

CPGs v2.0 publishes an explicit mapping to NIST CSF 2.0 subcategories per goal, which is the feature that makes the CPGs a defensible first-wave subset rather than an alternate framework. The mappings below are representative of the operating ones programmes encounter most often; each CPG entry in the published document carries the full subcategory list per goal, and the cross-walk reads in both directions.

A practical adoption sequence

The CPGs are designed to be operated in a sequence rather than addressed in parallel. The cadence below is the practical ordering most programmes follow when the CPGs are treated as the operating baseline rather than a checklist. The cycle compounds: each function inherits evidence from the prior function, so the audit pack at the end of the cycle is the residue of the operating work rather than a separate compilation.

1. 1Establish the GOVERN baseline. Document the executive accountability, the cybersecurity leadership name, the cyber risk appetite, the supplier and supply chain expectations, the security awareness cadence, and the documented incident response plan. The GOVERN goals are the cheapest and the most evidence-dense; programmes that defer GOVERN end up reconstructing the documentation later under audit pressure.
2. 2Build the IDENTIFY layer on the operating record. The asset inventory, the vulnerability detection cadence, and the KEV mitigation discipline all read off the workspace rather than off a survey. External scanning, authenticated DAST, code scanning, and continuous monitoring feed the identification record on a recurring schedule, with the activity log carrying the timestamps the audit pack reads against.
3. 3Implement the PROTECT controls in cost-impact order. The CPGs publication includes a cost, complexity, and impact rating per goal so the prioritisation is published rather than improvised. MFA on internet-exposed services, change of default passwords, separation of user and privileged accounts, and unique credentials are the highest-impact-per-cost goals; segmentation, encryption, and configuration hardening follow.
4. 4Stand up the DETECT capability against the asset coverage from IDENTIFY. Log collection sufficient to detect malicious activity, suspicious-behaviour detection against known TTPs, and the integration into the response process are the three goals; coverage proportional to asset and access scope is the audit expectation.
5. 5Operate the RESPOND reporting discipline against the documented IR plan. Each incident from this point forward leaves a structured report record on the workspace, paired with the evidence the response produced (engagement record, finding, remediation, retest). The reporting log is the durable evidence the audit reads.
6. 6Run the RECOVER exercise and restoration cadence. Tabletop exercises against the documented IR plan and backup restoration tests produce the recovery evidence the audit expects. The exercise improvement record is what feeds the next cycle, so the exercises stop being a one-off and become an operating discipline.
7. 7Layer the sector-specific goals on top. Programmes operating in multiple sectors adopt the cross-sector goals as the floor and add the sector-specific goals (Water and Wastewater, Healthcare and Public Health, and the others CISA publishes per sector) per business unit, reading off the same evidence pack.

Failure modes the CPGs are designed to surface

The CPGs are forgiving on the choice of tooling, the operating cadence, and the prioritisation order within a function. They are unforgiving about a small number of patterns that turn the framework cosmetic rather than operational. The patterns below recur across CPG adoptions and are the ones that erode the year-over-year continuity the audit read expects.

Evidence the framework expects to see

The CPG evidence pack reads well when it is built as a side effect of the operating work rather than reconstructed at audit time. The minimum set below maps to the goals examiners, sector regulators, and audit committees most often read against, and the same artefacts feed parallel reads under NIST CSF 2.0, CIS Controls, the sector-specific CPG list, and the SEC cybersecurity disclosure rules when the underlying record is structured.

How the CPGs relate to adjacent frameworks

The CPGs sit in a busy frameworks neighbourhood. The relationships below are the ones programmes encounter most often when they read the CPGs against the rest of the cybersecurity baseline regime. The relationships matter because programmes that try to operate each framework in isolation rebuild the same evidence multiple times.

Where SecPortal fits in a CPG programme

SecPortal is the operating layer for the CPG cycle, not a replacement for the CISA publication or for the sector-specific guidance the relevant agency maintains. The platform handles the CPG-side workstreams (engagement structure, finding intake, severity scoring, treatment dispositions, retest evidence, leadership reporting) so the inputs IDENTIFY, PROTECT, DETECT, and RESPOND expect are produced as structured records rather than reconstructed at audit time. The same workspace that hosts the engagement record hosts the external scanning, authenticated DAST, code scanning, and pentest evidence the IDENTIFY and PROTECT goals depend on, so the line from artefact to goal stays traceable.

The IDENTIFY goals (especially 2.A asset inventory, 2.O CISA KEV mitigation, and 2.W documented vulnerability management) read against operational workflows that already exist as named use cases. The vulnerability prioritisation workflow translates the CISA KEV signal and the CVSS-plus-EPSS severity into the per-finding queue the goal expects. The vulnerability SLA management workflow carries the timeline discipline the KEV mitigation goal reads against. The scanner result triage workflow is the place where the scanning output the IDENTIFY function expects becomes structured findings rather than CSV exports, and the asset criticality scoring workflow carries the asset-tier discipline the CPG asset-inventory goal expects.

For internal security teams running the CPG baseline, the internal security teams workspace bundles the platform with the engagement structure the audit cadence reads against. For vulnerability management functions feeding the IDENTIFY layer, the vulnerability management teams workspace covers the lifecycle work that produces the operational signal goals 2.B, 2.C, and 2.O read against. For CISOs and security leaders carrying the GOVERN function, the CISOs and security leaders workspace covers the program-level reporting model that sits on top of the CPG operating record.

For deeper reading on the disciplines this framework reads against, the CISA KEV catalog guide covers the operational discipline goal 2.O expects against the moving public KEV list. The vulnerability management program guide covers the IDENTIFY-and-PROTECT operating cycle the cross-sector goals expect. The incident response plan guide covers the GOVERN goal 1.G plan-document expectation and the RESPOND and RECOVER goals it reads against. The security program KPIs and metrics framework covers the metric structure the GOVERN reporting goals (1.A and 1.G) read against. For analytical context on how cyber programmes age across compliance cycles, the security control drift research covers the patterns that erode CPG evidence between annual reviews when the audit is run only at announcement time.