Risk Assessment and Security Planning for ITSP.10.171

The majority of ITSP.10.171 control families deal with operational security: how you configure systems, manage access, protect data. The Risk Assessment (RA) and Planning (PL) families sit a layer above that. They define how an organization understands its risk posture and documents the security architecture that addresses it.

This distinction matters because RA and PL controls shape everything else. A vulnerability scanning program without a risk register is just generating data. A collection of security controls without a system security plan is a set of disconnected activities that an assessor has no way to evaluate as a coherent program.

RA and PL are not among the six families expected at Level 1; they apply at Level 2, which requires compliance with the full ITSP.10.171 standard. For organizations preparing for CPCSC Level 2 certification, these two families represent the governance layer that ties the entire program together. They are not the most technically complex controls in ITSP.10.171, but they are among the most consequential when they are missing or incomplete.

Risk Assessment (RA): What ITSP.10.171 Requires

The RA family covers the process of identifying, evaluating, and responding to security risks across systems that handle controlled information. The controls fall into three operational areas.

Risk Assessment Process

Organizations must conduct and document periodic risk assessments that identify threats and vulnerabilities to their systems and data. The keyword here is documented. Running an informal assessment, discussing risks in a meeting, or relying on institutional knowledge does not satisfy the control. The assessment must produce a documented output that identifies specific risks, evaluates their likelihood and impact, and records the results.

For CPCSC purposes, this means a risk assessment that covers all systems within the certification boundary, conducted at a defined frequency, with results that feed directly into risk treatment decisions.

Vulnerability Monitoring and Scanning

ITSP.10.171 requires organizations to monitor and scan for vulnerabilities in their systems and applications. This is the most operationally visible RA control, and it is also the one where the gap between doing something and meeting the requirement is widest.

Running vulnerability scans is common. Organizations with any security maturity typically have a scanning tool in place. What distinguishes a compliant program from an informal one is the full lifecycle: scanning at defined intervals, triaging results against risk criteria, remediating within established timeframes, and documenting exceptions where vulnerabilities are accepted rather than remediated.

The scanning requirement aligns closely with NIST SP 800-171 Rev 3, which treats vulnerability scanning as an ongoing operational activity rather than a periodic event. ITSP.10.171 follows the same logic. The expectation is continuous or near-continuous monitoring of the threat landscape, not quarterly scan-and-forget cycles.

Risk Response

After risks are identified and vulnerabilities are catalogued, the organization must document its response. For each identified risk, there must be a recorded decision: mitigate, accept, transfer, or avoid. Each decision requires a documented rationale.

This is where many organizations fall short. The scan runs, the report generates, and the high-severity items get patched. But the medium-severity items sit in a queue, the accepted risks have no formal documentation, and six months later nobody can explain why a particular vulnerability was left unpatched on a specific system.

A compliant risk response process produces a clear trail from identification through to resolution or documented acceptance, with rationale that would hold up under assessor scrutiny.

Planning (PL): The System Security Plan and Rules of Behavior

The PL family addresses the documentation that describes how an organization's security program is structured and how personnel are expected to behave within it.

The System Security Plan

The system security plan (SSP) is the single most important document in a CPCSC certification effort. It describes the system boundary, the security controls in place, how those controls are implemented, and who is responsible for maintaining them. For Level 2 assessments, the SSP is the primary artifact that assessors use to understand the organization's security posture before they begin testing.

An incomplete SSP creates problems that cascade across every other control family. If the SSP does not accurately describe the system boundary, the assessor cannot determine whether access controls are applied to the right systems. If the SSP omits a control implementation, the assessor has no basis to verify it. If the SSP describes a control that does not match the actual implementation, that creates a finding regardless of whether the implementation itself is adequate.

What the SSP Must Cover

• System boundary definition: which systems, networks, and data stores are in scope
• Control implementation descriptions: how each applicable ITSP.10.171 control is satisfied
• Roles and responsibilities: who owns each control area
• Interconnections: how the system connects to external systems and networks
• Authorization status: the current security posture and any known gaps under remediation

Rules of Behavior

ITSP.10.171 requires documented rules of behavior that describe the responsibilities and expected conduct of personnel who access systems containing controlled information. This is the formal agreement that personnel acknowledge before being granted access.

Rules of behavior typically cover acceptable use, data handling expectations, incident reporting obligations, and consequences for non-compliance. The control requires that these rules are documented, distributed to relevant personnel, and acknowledged before access is provisioned.

For organizations that already maintain an acceptable use policy, this control often requires minimal additional effort. The key requirement is that the rules specifically address the handling of controlled information, not just general IT usage, and that there is documented evidence of personnel acknowledgment.

Where SOC 2 and ISO 27001 Overlap

Organizations with existing SOC 2 or ISO 27001 certifications will find meaningful overlap in these two families, though the mapping is not one-to-one.

Risk Assessment Overlap

SOC 2 CC3.1 through CC3.4 (Risk Assessment criteria) require an annual risk assessment process that identifies and evaluates risks. ISO 27001 Clause 6.1 requires risk assessment processes that identify information security risks and evaluate their likelihood and consequences. Both frameworks expect a documented risk register and defined risk treatment plans. The operational mechanics are similar enough that an organization with a mature risk assessment process under either framework has the foundation in place for RA compliance under ITSP.10.171.

The primary gap tends to be scope. SOC 2 and ISO 27001 risk assessments cover the systems and data within their own audit boundaries. ITSP.10.171 requires the risk assessment to cover all systems that handle controlled government information, which may include systems outside the existing certification scope.

Planning Overlap

SOC 2 does not require a formal system security plan in the way ITSP.10.171 defines it. The SOC 2 system description serves a related purpose, describing the system boundaries and controls, but it is structured for auditor consumption during the SOC 2 examination rather than as an ongoing operational document.

ISO 27001 comes closer through its Statement of Applicability (SoA) and the ISMS documentation requirements, which collectively describe which controls are implemented and how. But the SoA is not a system security plan. An organization with ISO 27001 certification will need to create a dedicated SSP for ITSP.10.171 compliance, though much of the content can be drawn from existing ISMS documentation.

Common Gaps That Create Problems

Across organizations preparing for CPCSC certification, several patterns appear consistently in the RA and PL control families.

Scattered Risk Registers

Risk tracking spread across multiple tools, spreadsheets, ticketing systems, and email threads is a common failure. An assessor expects a single, authoritative source that shows all identified risks, their current status, and the documented treatment decision for each. When risks are tracked in a vulnerability scanner, a project management tool, and a shared spreadsheet simultaneously, the organization cannot demonstrate a coherent risk management process.

The fix is not necessarily a dedicated GRC platform, though that helps at scale. The fix is a single location, whatever the format, where every identified risk is tracked from identification through treatment with a clear rationale for each decision.

No Documented Risk Response

Remediation happens. Vulnerabilities get patched, configurations get tightened, exceptions get made. But the decision trail is missing. There is no record of who decided to accept a particular risk, what the rationale was, or when the acceptance will be reviewed.

For RA compliance, the documented rationale matters as much as the action itself. An assessor reviewing a risk register will look for mitigation evidence on mitigated risks and acceptance rationale on accepted risks. A decision to accept risk without a documented business justification is a finding.

Outdated or Incomplete SSP

The most problematic gap in the PL family is an SSP that does not reflect the current state of the environment. This happens frequently when the SSP is written once during initial certification preparation and then not updated as systems change. New applications are deployed, network architecture evolves, personnel change roles, and the SSP quietly drifts from reality.

When the SSP describes a different environment than the one the assessor evaluates, every control verification becomes complicated. The assessor must reconcile what the documentation says with what they observe, and discrepancies create findings even if the underlying security posture is sound.

Missing Vulnerability Management Lifecycle

Running scans is step one. Many organizations stop there, or stop after remediating critical findings. A complete vulnerability management lifecycle under ITSP.10.171 requires scanning, triaging, remediating or accepting with rationale, verifying remediation, and reporting, all at defined intervals appropriate to the risk level of each system.

Implementation: Building It Right

Centralize the Risk Register

Consolidate all risk tracking into a single authoritative source. This register should capture, at minimum:

• Risk identifier and description
• Date identified and source (risk assessment, vulnerability scan, incident, audit finding)
• Risk owner
• Likelihood and impact rating
• Treatment decision: mitigate, accept, transfer, or avoid
• Treatment rationale
• Target remediation date for mitigated risks
• Review date for accepted risks
• Current status

The format matters less than the discipline. A well-maintained spreadsheet outperforms a poorly maintained GRC platform. What matters is that every identified risk has a single, traceable record from identification through disposition.

Implement Tiered Vulnerability Scanning

Not every system warrants the same scanning cadence. A tiered approach aligns scanning frequency with risk:

Each tier should have defined triage and remediation timeframes. Critical vulnerabilities on internet-facing systems might carry a 48-hour remediation window. The same vulnerability on an isolated internal system might allow 30 days. The timeframes should reflect actual risk, documented in the vulnerability management policy, and tracked in the risk register.

Structure the System Security Plan

The SSP does not need to be a 200-page document, but it must be complete and accurate. A practical structure:

1. System identification: Name, purpose, categorization, and authorization status
2. System boundary: Network diagrams, data flow diagrams, and a clear description of what is in scope
3. System environment: Physical and logical architecture, hosting, and interconnections
4. Control implementation: For each applicable ITSP.10.171 control, a description of how the organization satisfies it, including tools, processes, and responsible personnel
5. Roles and responsibilities: A responsibility matrix mapping control families to specific roles
6. Continuous monitoring strategy: How the organization tracks control effectiveness over time
7. Plan of action and milestones (POA&M): Known gaps, remediation plans, and target dates

The control implementation section is the core of the document and typically the most time-intensive to develop. Each control description should be specific enough that an assessor could verify it. Stating that MFA is used is insufficient. Describing that MFA is enforced for all user accounts accessing the production environment via a specific identity provider, configured to require a hardware token or authenticator application as a second factor, gives the assessor something to test.

Maintain the SSP as a Living Document

The SSP loses its value the moment it stops reflecting reality. Build SSP updates into existing change management processes. When a system component changes, when a new application enters the boundary, when a control implementation changes, the SSP should be updated as part of the change, not retroactively before the next assessment.

Assign SSP ownership to a specific role and define a review cadence, quarterly at minimum, to catch any drift between documentation and implementation.

Frequently Asked Questions

How often should risk assessments be conducted under ITSP.10.171?

ITSP.10.171 requires risk assessments at an organization-defined frequency and whenever significant changes occur to systems or the operating environment. Annual assessments are the typical baseline, supplemented by event-driven assessments when new systems are deployed, significant vulnerabilities are discovered, or the threat landscape shifts materially. The defined frequency and triggering events should be documented in organizational policy.

What is the difference between the SSP and the POA&M?

The system security plan describes the security controls that are implemented and how they satisfy ITSP.10.171 requirements. The plan of action and milestones (POA&M) documents known gaps where controls are not yet fully implemented, along with specific remediation plans and target dates. Together, the SSP shows what is in place and the POA&M shows what still needs to be done. Both are expected artifacts in a Level 2 assessment.

Can we reuse our SOC 2 risk assessment for CPCSC compliance?

The process and methodology can often be reused. If the organization has a mature risk assessment framework under SOC 2, the same approach, likelihood and impact criteria, risk register structure, and treatment process, can serve as the foundation for the ITSP.10.171 risk assessment. The scope must be adjusted to ensure it covers all systems handling controlled government information, which may extend beyond the existing SOC 2 boundary. The risk assessment output should also map identified risks to ITSP.10.171 controls rather than SOC 2 Trust Services Criteria.

What level of detail does the SSP require for each control?

Each control description should be specific enough that a third-party assessor could verify the implementation without additional explanation. This means naming the tools, processes, frequencies, and responsible roles involved. Vague descriptions will prompt the assessor to request clarification or issue findings. The standard does not prescribe a specific format or length, but practical experience suggests that each control requires a paragraph-level description covering the implementation mechanism, cadence, ownership, and any relevant configuration details.

This post is part of our CPCSC series. For guidance on building an effective security program that satisfies ITSP.10.171 requirements, reach out to our team.