CISA CPG 2.0: A Practical SMB Security Baseline

A PTG security and compliance guide

CISA CPG 2.0: A Practical SMB Security Baseline

Cybersecurity programs often stall because the standard is too large to start. A small or midsize business may have a risk register, a vulnerability queue, a cyber-insurance questionnaire, and several vendor checklists, but still lack a short list of actions that leadership can fund and verify.

CISA's Cross-Sector Cybersecurity Performance Goals 2.0, or CPG 2.0, are designed to close that gap. CISA describes the CPGs as a voluntary baseline of practices selected for their ability to reduce known risks across critical infrastructure. They are not a certification and they do not replace a risk assessment. They are a practical way to decide what should be in place first, who owns it, and what evidence proves the control works.

The 2.0 update aligns the goals with NIST CSF 2.0, adds a stronger governance emphasis, and brings information technology and operational technology into a more unified structure. For an SMB, the opportunity is straightforward: turn the goals into a focused 90-day security backlog instead of treating compliance as a document exercise.

What CPG 2.0 changes for business leaders

The biggest change is the addition of the Govern function. Security is not only a technical configuration problem; it is also a leadership decision about risk, policy, accountability, and investment. The updated goals make that visible by emphasizing cybersecurity oversight, a risk-management strategy, and documented direction from the organization.

CPG 2.0 also consolidates IT and operational technology goals into shared outcomes. A business does not need separate language for every device category to answer basic questions: which systems matter, who can access them, how they are protected, and how the organization will respond when something fails. That unified view is especially useful when an SMB relies on cloud services, managed providers, connected equipment, and remote administration.

The update also calls attention to areas that frequently fall between teams: third-party risk, least privilege, zero-trust practices, and incident communication. These are not extra projects to postpone until the security program is mature. They are reminders that a business can be exposed through a vendor, an overprivileged account, or a confusing response even when endpoint tools are installed.

Start with a six-part baseline

Use CPG 2.0 as a prioritization tool. Begin with a short working session that maps the goals to six business capabilities. The objective is not to claim perfect compliance; it is to identify the minimum actions that reduce the most consequential exposure.

  • Know what you operate. Maintain an inventory of endpoints, servers, cloud services, identities, network devices, public-facing applications, backup systems, and critical vendors. Include the owner and business purpose for each important asset.
  • Control identity. Require multifactor authentication for email, remote access, administrator accounts, and other high-impact systems. Remove stale accounts, review privileged access, and make joiner, mover, and leaver changes part of a repeatable process.
  • Protect and recover data. Identify the information the business cannot afford to lose, limit who can reach it, and maintain backups that are protected from ordinary administrator compromise. Test restoration rather than treating a successful backup job as proof of recovery.
  • Manage vulnerabilities. Establish a routine for finding missing patches, exposed services, unsupported software, and misconfigurations. Use exploitation evidence and business impact to prioritize the queue, then verify the fix on the affected asset.
  • Manage suppliers. Keep a record of critical providers, the data or access they receive, and the security responsibilities written into the relationship. Ask how they protect accounts, notify customers, handle incidents, and return or delete data when the contract ends.
  • Prepare to communicate. Define who can declare an incident, who makes technical decisions, who contacts leadership, and how customers, insurers, regulators, law enforcement, and vendors will be coordinated when needed.

These capabilities are intentionally plain. A baseline works only when a business can explain it to a manager, assign it to an owner, and test it without needing a new framework for every department.

Turn the baseline into a 90-day plan

Once the baseline is mapped, score each action as implemented, partially implemented, or not in place. Do not use a vague green, yellow, or red status without a definition. “Implemented” should mean that the control is operating and evidence exists. “Partial” should identify the missing scope, owner, or verification step. “Not in place” should include the risk created by the gap.

In the first 30 days, address visibility and immediate exposure. Confirm the asset and account inventory, identify internet-facing systems, protect administrator accounts with strong authentication, remove unused access, and verify that backups cover the systems the business actually depends on. Create an exception record for anything that cannot be fixed immediately.

In days 31 through 60, strengthen repeatability. Set a patch and vulnerability cadence, formalize onboarding and offboarding, document vendor access, and run a short incident-response discussion with business and technical owners. The goal is to remove decisions that otherwise happen for the first time during a crisis.

In days 61 through 90, test and measure. Restore a representative backup, review privileged access, sample endpoint and cloud logs, confirm a vendor contact path, and run a tabletop scenario. Report open risks and overdue actions to leadership with a decision request, not just a technical status update.

A plan should have no more than a handful of active priorities at once. If every gap is marked urgent, the list is not helping leadership allocate resources. CPG 2.0 is most useful when it creates a sequence that the business can sustain.

Build evidence that stands up to review

Compliance evidence should make the operating truth easier to see. For asset management, keep an export or system record that shows the inventory was reviewed and includes an owner. For identity, retain access-review results, MFA coverage, and tickets showing stale accounts were removed. For backups, keep restoration test results with the date, systems tested, outcome, and corrective action.

For vulnerability management, retain the findings, prioritization logic, change records, and validation evidence. A screenshot that shows a patch was approved is weaker than a version check or authenticated scan that shows the vulnerable component is no longer present. For suppliers, store the security addendum, review date, critical contacts, and any accepted exceptions in the same place as the relationship record.

Use a simple evidence register with five fields: control or goal, owner, evidence location, last test date, and next review date. This prevents the common failure mode in which a business has performed the work but cannot find the proof when an auditor, insurer, customer, or executive asks for it.

Use CPG 2.0 without creating checkbox security

The CPGs are a baseline, not a substitute for judgment. A business that handles regulated health data, payment information, industrial systems, or sensitive intellectual property may need additional requirements. Contractual commitments, state privacy laws, insurance terms, and sector-specific guidance can change the priority of a control.

Do not treat a completed checklist as the same thing as reduced risk. An MFA policy that excludes administrators, a backup that has never been restored, or an incident plan that omits business communications may look complete while failing under pressure. Pair every high-impact control with a test, an owner, and a date for the next review.

Leadership should also ask what remains outside the baseline. Which critical vendor cannot yet meet the required terms? Which legacy system cannot receive updates? Which account has more access than its role requires? Those answers belong in a risk register with a decision, a deadline, and a compensating measure—not hidden in a spreadsheet that nobody revisits.

CPG 2.0 gives growing businesses a credible starting point for security governance: know the environment, protect identity and data, manage exposure, control supplier risk, and practice the response. PTG helps organizations turn these principles into operating routines, measurable remediation plans, and evidence that supports both resilience and compliance. If your team cannot name the three security actions that would reduce the most risk this quarter, begin there.

Carlos Perez
Carlos Perez CEO & Founder, Perez Technology Group | Founder, CyberFence | Microsoft Certified

Ready to take the next step?

PTG helps growing businesses build secure, resilient, and modern IT foundations. Let's talk.

Contact Us