Security Assessment (CA)

Security Assessment (CA) is one of 14 security control families in NIST SP 800-171 Revision 2 that forms the foundation for CMMC Level 2 certification. The CA family contains 4 security requirements (3.12.1 through 3.12.4) that establish the assessment, documentation, and monitoring framework for your cybersecurity program.

The Security Assessment family is unique because it creates the foundation for demonstrating compliance with all other control families. Without proper implementation of CA requirements, organizations cannot effectively prove they’ve met any of the other 106 NIST 800-171 requirements.

All 4 Security Assessment requirements are Basic Security Requirements—there are no derived requirements in this family. This means every organization handling Controlled Unclassified Information (CUI) must implement all 4 CA controls to achieve CMMC Level 2 compliance.

Why Security Assessment Matters for CMMC

The CA control family serves three critical functions:

1. Creates the compliance foundation: The System Security Plan (SSP) documents how you implement all 110 NIST 800-171 requirements
2. Tracks remediation progress: Plans of Action and Milestones (POA&Ms) document gaps and your plan to close them
3. Validates ongoing effectiveness: Periodic assessments and continuous monitoring ensure controls remain effective over time

Without a complete SSP, CMMC assessments cannot proceed. According to the NIST SP 800-171 DoD Assessment Guidance, “The absence of a system security plan would result in a finding that an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.”

The 4 Security Assessment Requirements

3.12.1: Periodically Assess Security Controls

Requirement: Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.

What This Means

Organizations must conduct regular evaluations of implemented security controls to verify they’re functioning as intended and providing adequate protection. Assessments determine whether safeguards are:

• Implemented correctly
• Operating as intended
• Producing the desired outcome with respect to meeting security requirements

Implementation Approach

Assessment Types:

• Self-assessments: Internal evaluations conducted by your organization or hired consultants
• Third-party assessments: Independent evaluations conducted by C3PAO organizations
• Government assessments: DoD-conducted DIBCAC assessments (Level 3 or investigations)

Assessment Frequency: For CMMC Level 2, organizations must conduct assessments:

• Triennial assessment: Every 3 years (self-assessment OR C3PAO certification, depending on contract requirements)
• Annual affirmation: Each year between full assessments to affirm continued compliance
• POA&M closeout assessment: Within 180 days when remediating gaps under Conditional Status

What to Assess:

• All 110 NIST 800-171 security requirements applicable to your system
• Technical controls (firewalls, encryption, access controls)
• Administrative controls (policies, procedures, training)
• Physical controls (facility access, equipment protection)

Assessment Process:

1. Prepare assessment plan: Define scope, assessment methods, and assessment team
2. Gather evidence: Collect documentation, logs, screenshots, configurations
3. Conduct assessment: Interview personnel, examine systems, test controls
4. Analyze findings: Determine which requirements are MET or NOT MET
5. Document results: Create assessment report with findings and evidence
6. Report to SPRS: Submit results to Supplier Performance Risk System

Assessment Results: Each of the 110 requirements receives one of two determinations:

• MET: Control is implemented correctly and operating as intended
• NOT MET: Control has deficiencies or is not fully implemented

Scoring: Assessments use the DoD CMMC Scoring Methodology where each requirement is worth 1, 3, or 5 points. Organizations need:

• 110 out of 110 for Final Status (all requirements MET)
• Minimum 88 out of 110 (80%) for Conditional Status with eligible POA&Ms

Assessment Tips

For self-assessments:

• Use NIST SP 800-171A assessment procedures for guidance
• Document all evidence thoroughly—assessors will review your work
• Be honest about gaps—Conditional Status with POA&Ms is acceptable
• Engage consultants or Registered Practitioners (RPs) if needed

For C3PAO assessments:

• Prepare SSP and evidence packages before scheduling assessment
• Conduct pre-assessment readiness review to identify gaps
• Ensure personnel are available for interviews
• Have system administrators ready to demonstrate technical controls

Common evidence requested:

• System Security Plan with implementation descriptions
• Policies and procedures for each control family
• Screenshots of security configurations
• Audit logs and monitoring reports
• Training records and certificates
• Incident response documentation
• Asset inventories and network diagrams

---

3.12.2: Develop and Implement Plans of Action

Requirement: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.

What This Means

A Plan of Action and Milestones (POA&M) is a formal document that identifies security deficiencies discovered during assessments and outlines the corrective actions needed to address them. POA&Ms serve as roadmaps for achieving full compliance with NIST 800-171 requirements.

Understanding POA&Ms

Purpose:

• Document security control deficiencies identified during assessments
• Specify corrective actions required to address gaps
• Assign responsibilities for remediation efforts
• Establish milestones and completion dates
• Track progress toward full compliance

When POA&Ms Are Required:

• After completing gap analysis or security assessment that identifies deficiencies
• When achieving Conditional CMMC Status (88/110 minimum score with eligible gaps)
• Following vulnerability scans that discover exploitable weaknesses
• After incident response activities that reveal control failures
• During continuous monitoring when controls are found ineffective

POA&M vs. System Security Plan:

• SSP: Documents HOW controls are currently implemented (or planned to be implemented)
• POA&M: Documents WHAT gaps exist and HOW you’ll fix them

Federal agencies may consider submitted SSPs and POA&Ms as “critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization.”

CMMC POA&M Rules and Restrictions

For organizations pursuing CMMC Level 2 Conditional Status, strict limitations apply to which requirements can be placed on POA&Ms.

POA&M Eligibility Requirements (32 CFR 170.21):

To achieve Conditional Status, ALL of the following must be met:

1. Minimum score: Assessment score ≥ 88 out of 110 (80%)
2. Only 1-point requirements: NO requirements with point values of 3 or 5 can be on POA&Ms—with ONE exception: SC.L2-3.13.11 (CUI Encryption) can be on POA&M if encryption is employed but not yet FIPS-validated
3. Critical requirements excluded: Certain 1-point requirements CANNOT be on POA&Ms under any circumstances

Requirements That CANNOT Be on POA&Ms (even though they’re worth 1 point):

The following requirements must be fully MET—they cannot be on POA&Ms for Conditional Status:

Access Control (AC):

• AC.L2-3.1.1 – Limit system access to authorized users
• AC.L2-3.1.2 – Limit system access to types of transactions and functions
• AC.L2-3.1.20 – Verify and control/limit connections to external systems
• AC.L2-3.1.22 – Control CUI posted or processed on publicly accessible systems

Identification and Authentication (IA):

• IA.L2-3.5.1 – Identify system users, processes acting on behalf of users, and devices
• IA.L2-3.5.2 – Authenticate (or verify) identities of users, processes, or devices
• IA.L2-3.5.3 – Use multifactor authentication for local and network access

Media Protection (MP):

• MP.L2-3.8.3 – Sanitize or destroy system media before disposal or reuse

Physical Protection (PE):

• PE.L2-3.10.1 – Limit physical access to organizational systems and facilities
• PE.L2-3.10.3 – Escort visitors and monitor visitor activity
• PE.L2-3.10.4 – Maintain audit logs of physical access
• PE.L2-3.10.5 – Control and manage physical access devices

System and Communications Protection (SC):

• SC.L2-3.13.1 – Monitor, control, and protect communications at system boundaries
• SC.L2-3.13.8 – Implement cryptographic mechanisms to prevent unauthorized disclosure during transmission
• SC.L2-3.13.16 – Protect the confidentiality of CUI at rest

System and Information Integrity (SI):

• SI.L2-3.14.1 – Identify, report, and correct system flaws in a timely manner
• SI.L2-3.14.2 – Provide protection from malicious code at designated locations
• SI.L2-3.14.4 – Update malicious code protection mechanisms when new releases available
• SI.L2-3.14.5 – Perform periodic scans and real-time scans of files from external sources
• SI.L2-3.14.6 – Monitor systems and communications to detect attacks and indicators of potential attacks
• SI.L2-3.14.7 – Identify unauthorized use of organizational systems

These critical requirements protect fundamental security capabilities—access control, authentication, encryption, malware protection, and monitoring—that must be in place immediately to protect CUI.

POA&M Closeout Requirements

180-Day Deadline: Organizations with Conditional Status must close ALL POA&M items within 180 days of the Conditional CMMC Status Date. This is a firm deadline with significant consequences.

Closeout Process:

1. Remediate gaps: Implement all corrective actions identified in POA&M
2. Gather evidence: Document that controls are now fully implemented and operating
3. Conduct closeout assessment:
   • For Level 2 (Self): OSA performs POA&M closeout self-assessment
   • For Level 2 (C3PAO): Same C3PAO conducts POA&M closeout certification assessment
4. Submit results: Report closeout assessment results to SPRS or eMASS
5. Achieve Final Status: If all POA&M items pass, status transitions from Conditional to Final

Consequences of Missing Deadline:

• Conditional CMMC Status expires after 180 days if POA&M not closed
• Organization becomes ineligible for new contract awards requiring that CMMC level
• If status expires during contract performance, standard contractual remedies apply (potential contract termination)
• Must complete entirely new assessment to regain CMMC Status

POA&M Structure and Content

Required POA&M Elements:

1. Control Identifier: NIST 800-171 requirement number (e.g., AC.L2-3.1.5)
2. Control Description: Full text of requirement from NIST 800-171
3. Description of Deficiency: Detailed explanation of the gap or weakness
4. Vulnerability Severity: Risk classification (High, Moderate, Low) based on impact
5. Source of Discovery: How deficiency was identified (assessment, vulnerability scan, audit, monitoring)
6. Corrective Action: Specific steps required to remediate the deficiency
7. Resources Required: Personnel, budget, technologies, or external support needed
8. Responsible Party: Individual or team accountable for implementing corrective action
9. Milestone Target Date: Deadline for completing remediation
10. Current Status: Progress tracking (Not Started, In Progress, Completed)
11. Completion Date: Actual date when deficiency was remediated (when completed)

POA&M Best Practices:

• Keep POA&M as a living document—update regularly as progress is made
• Break complex remediation into phases with intermediate milestones
• Assign realistic target dates considering resource constraints
• Track POA&M items in your ticketing or project management system
• Review POA&M status in regular security meetings
• Document evidence as you close each item—you’ll need it for closeout assessment

POA&M Format: There is no prescribed format. Organizations commonly use:

• Spreadsheet (Excel format most common)
• Security automation tools or GRC platforms
• Project management systems
• NIST-provided POA&M template

Ongoing POA&M Management

POA&Ms aren’t just for CMMC assessments. Organizations should maintain POA&Ms as part of their ongoing security program to track:

• Vulnerabilities discovered during periodic vulnerability scans
• Deficiencies found during internal security reviews
• Gaps identified through continuous monitoring activities
• Issues discovered during incident response
• New requirements from updated regulations or standards

---

3.12.3: Monitor Security Controls on an Ongoing Basis

Requirement: Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.

What This Means

Continuous monitoring provides organizations with ongoing awareness of their security posture, enabling timely detection of emerging threats, vulnerabilities, and control failures. The goal is to assess and analyze security controls at a frequency sufficient to support risk-based decisions.

Understanding Continuous Monitoring

Why Continuous Monitoring Matters: Security is not a static state. New threats emerge daily, systems change constantly, and configurations drift over time. What worked yesterday may not work tomorrow. Continuous monitoring ensures:

• Security controls remain effective over time
• New vulnerabilities are detected and addressed promptly
• Control drift or misconfigurations are caught early
• Evidence of sustained compliance is available for audits and assessments

Continuous vs. Periodic:

• Periodic assessments (3.12.1): Comprehensive evaluations every 3 years
• Continuous monitoring (3.12.3): Ongoing automated and manual checks to maintain visibility between assessments

Both are required—continuous monitoring doesn’t replace periodic assessments; it supplements them by providing real-time insights into security posture.

Implementation Approach

Monitoring Frequency: The terms “continuous” and “ongoing” mean organizations must assess and analyze security controls at a frequency sufficient to support risk-based decisions. This typically means:

• Automated monitoring: Real-time or near-real-time (within minutes or hours)
• Manual reviews: Daily, weekly, or monthly depending on control and risk level
• Management reporting: Monthly or quarterly security posture dashboards

What to Monitor:

1. Technical Security Controls:

• Firewall rules and policies
• Intrusion detection/prevention system (IDS/IPS) alerts
• Antivirus/anti-malware status and detections
• Encryption status for data at rest and in transit
• Patch management status
• Configuration compliance
• Access control effectiveness
• Authentication mechanisms (including MFA usage)
• Account status (disabled, locked, privileged accounts)

2. System Activity:

• Security information and event management (SIEM) alerts
• Audit log reviews for suspicious activity
• Failed login attempts and patterns
• Privileged account usage
• File integrity monitoring alerts
• Network traffic anomalies
• System performance and availability

3. Vulnerability Status:

• Vulnerability scan results
• Newly discovered CVEs affecting your systems
• Patch compliance status
• Security configuration compliance

4. Compliance Status:

• Control effectiveness indicators
• POA&M progress and milestone achievement
• Policy and procedure update status
• Training completion rates
• Incident response exercise results

5. Threat Intelligence:

• Security advisories from US-CERT/CISA
• Vendor security bulletins
• Threat intelligence feeds
• Industry-specific threat information

Monitoring Outputs and Reporting

Effective Monitoring Characteristics: NIST SP 800-171 specifies that monitoring outputs should be:

• Specific: Clearly identify what’s being measured
• Measurable: Provide quantifiable data
• Actionable: Enable decision-making
• Relevant: Relate to actual security risks
• Timely: Provide information when needed

Security Dashboards: Provide organizational officials with ongoing visibility through:

• Real-time security posture metrics
• Control effectiveness indicators
• Vulnerability trends
• Incident metrics
• Compliance status summaries

Regular Reports:

• Daily: Critical alerts requiring immediate response
• Weekly: Security event summaries, high-priority vulnerability reports
• Monthly: Security posture dashboards, control effectiveness metrics, POA&M status
• Quarterly: Management briefings on overall security program health

Monitoring Tools and Technologies

Core Technologies:

1. Security Information and Event Management (SIEM): Aggregates and correlates security events from multiple sources
   • Examples: Splunk, Microsoft Sentinel, LogRhythm, QRadar
2. Vulnerability Scanners: Identify system weaknesses and missing patches
   • Examples: Nessus, Qualys, Rapid7 InsightVM, OpenVAS
3. Endpoint Detection and Response (EDR): Monitor endpoint activity for threats
   • Examples: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne
4. Network Monitoring: Analyze network traffic for anomalies and threats
   • Examples: Zeek (Bro), Suricata, Darktrace, Cisco Stealthwatch
5. Configuration Management Tools: Track and enforce security configurations
   • Examples: Microsoft Endpoint Configuration Manager, Ansible, Puppet, Chef
6. GRC Platforms: Manage compliance, risk, and security program activities
   • Examples: ServiceNow GRC, RSA Archer, MetricStream, Totem

Automation Benefits:

• Supports more frequent updates to hardware/software/firmware inventories
• Enables real-time or near-real-time monitoring
• Reduces manual effort and human error
• Provides consistent monitoring coverage
• Generates alerts for immediate response

Response to Monitoring Results

Continuous monitoring isn’t just about collecting data—it’s about taking action. Organizations must:

1. Establish thresholds: Define what constitutes normal vs. concerning activity
2. Set alerting rules: Configure notifications for security events requiring response
3. Define escalation procedures: Determine who responds to different alert types
4. Integrate with incident response: Monitoring findings should trigger IR procedures when appropriate
5. Update POA&Ms: Document newly discovered deficiencies in POA&Ms
6. Adjust controls: Tune monitoring rules and controls based on findings

Assessment Evidence

To demonstrate compliance with 3.12.3, assessors will look for:

• Continuous monitoring program documentation: Policies and procedures describing monitoring approach
• Monitoring tool configurations: Evidence that tools are deployed and configured properly
• Security dashboards: Screenshots or access to real-time security posture visibility
• Regular reports: Examples of security reports generated for management
• Alert logs: Evidence that security events are being detected and logged
• Response documentation: Records showing that monitoring findings result in action

---

3.12.4: Develop, Document, and Periodically Update System Security Plans

Requirement: Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.

What This Means

The System Security Plan (SSP) is the cornerstone document of your CMMC compliance program. It’s a comprehensive description of your information systems, the CUI they handle, and how you’ve implemented each of the 110 NIST 800-171 security requirements.

The SSP is not optional. CMMC assessments cannot proceed without a complete, accurate SSP. C3PAOs will review the SSP before scheduling assessments, and inadequate SSPs will result in assessment delays or deferrals.

System Security Plan Purpose and Importance

What the SSP Does:

• Provides a formal overview of your security requirements and how you meet them
• Documents system boundaries, environment, and interconnections
• Describes the implementation of all 110 NIST 800-171 requirements
• Identifies which requirements are applicable vs. non-applicable
• Serves as the primary evidence document for CMMC assessments
• Communicates your security posture to DoD and federal agencies

Who Reviews Your SSP:

• C3PAO assessors before and during CMMC assessments
• DoD contracting officers when making contract award decisions
• DIBCAC assessors if government investigations occur
• Internal auditors during compliance reviews
• External auditors during financial or quality audits

Impact on Contract Awards: Federal agencies may consider submitted SSPs “as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization.”

A strong SSP demonstrates cybersecurity maturity and may influence contract award decisions beyond just CMMC compliance.

Required SSP Content

Eight Core Assessment Objectives (per NIST SP 800-171A and CMMC Assessment Guide):

1. System security plan is developed
   • SSP document exists and is version-controlled
   • SSP follows a logical structure and format
2. System boundary is described and documented
   • Authorization boundary clearly defined (what’s in scope for CUI)
   • Boundary diagrams showing systems, networks, and connections
   • Systems that process, store, or transmit CUI identified
   • Security protection assets identified
3. System environment of operation is described and documented
   • Physical locations where systems operate
   • Network architecture and topology
   • Cloud service providers used (if any)
   • Types of users and their functions
4. Security requirements identified as non-applicable are identified
   • Controls deemed not applicable with justifications
   • Documentation of why certain requirements don’t apply to your environment
   • Examples: No wireless networks = wireless controls non-applicable
5. Method of security requirement implementation is described and documented
   • Detailed description of HOW each of the 110 requirements is implemented
   • Specific technologies, processes, and procedures used
   • Configuration details for security controls
   • This is the largest section of the SSP
6. Relationship with or connection to other systems is described and documented
   • External connections to cloud services, vendors, partners, government systems
   • Data flows between systems
   • Security controls protecting interconnections
7. Frequency to update the system security plan is defined
   • SSP review and update schedule documented in policy
   • Typically: at least annually, or when significant changes occur
8. System security plan is updated with the defined frequency
   • SSP review dates documented
   • Version history tracked
   • Changes documented in revision notes

SSP Structure and Sections

Recommended SSP Sections:

1. System Overview

• Organization information and mission
• System name and description
• General purpose and functionality
• Types of CUI processed, stored, or transmitted
• CUI categories from CUI Registry

2. System Ownership and Contacts

• Authorizing Official who approves the SSP
• System Owner responsible for the system
• Information System Security Manager (ISSM)
• Points of contact for security matters

3. System Boundaries and Authorization Boundary

• Narrative description of what’s in scope for CMMC assessment
• Authorization boundary diagram showing:
  • Systems processing/storing/transmitting CUI
  • Security protection assets
  • Contractor Risk Managed Assets
  • Specialized Assets
  • External connections

4. System Environment of Operation

• Physical locations and facilities
• Network architecture diagrams
• Hardware inventory (servers, workstations, network devices)
• Software inventory (operating systems, applications, databases)
• Cloud services used (CSPs must be FedRAMP Moderate or higher)

5. Data Flows and System Interconnections

• Data flow diagrams showing how CUI moves through systems
• External connections to other organizations, cloud services, partners
• Interface types and security controls on connections
• Network segmentation approach

6. Users and Roles

• Number and types of users (standard, privileged, administrators)
• User roles and responsibilities
• Access approval processes

7. Security Control Implementation

• Implementation description for each of the 110 NIST 800-171 requirements
• For each requirement, describe:
  • WHO: Person or team responsible
  • WHAT: Specific control implementation
  • HOW: Technologies, processes, procedures used
  • WHERE: Systems or locations where implemented
  • WHEN: Frequency or timing of control activities
  • WHY (optional): Rationale for implementation approach

8. Non-Applicable Requirements

• List of requirements deemed non-applicable
• Justification for why each doesn’t apply to your environment

9. Hardware and Software Maintenance

• Internal vs. external IT service providers
• Maintenance responsibilities and processes
• Vendor support arrangements

10. Document Information

• Version number and date
• Review and approval signatures
• Revision history
• Next review date

Writing Effective Implementation Descriptions

Bad Implementation Description: “User access is controlled based on policy.”

Why It’s Bad:

• Vague and generic
• No details on HOW it’s implemented
• Doesn’t identify responsible parties
• Can’t be verified by assessors

Good Implementation Description: “The system administrator provisions user accounts through Active Directory after receiving written approval from department managers via email. Access requests are documented in ServiceNow tickets. Account creation follows the documented User Access Provisioning Procedure (v2.1, 10/2024), which implements role-based access control (RBAC) with pre-defined groups for each job function. Managers approve access within 1 business day, and accounts are provisioned within 2 business days. All access provisioning activities are logged in Active Directory audit logs, reviewed monthly by the ISSM.”

Why It’s Good:

• Specific about WHO does what (system admin, managers, ISSM)
• Describes HOW it’s done (Active Directory, ServiceNow, email approvals)
• References procedures by name and version
• Explains timing (within X business days)
• Identifies evidence (audit logs, monthly reviews)
• Testable and verifiable by assessors

SSP Format and Length

No Prescribed Format: NIST SP 800-171 explicitly states: “There is no prescribed format or specified level of detail for system security plans. However, organizations ensure that the required information in 3.12.4 is conveyed in those plans.”

Typical SSP Length:

• Main SSP document: 80-150 pages
• Supporting documentation (policies, procedures, diagrams): 50-200+ pages
• Total documentation package: 130-350+ pages

Length varies significantly based on:

• Organization size and complexity
• Number of systems in scope
• Level of detail provided
• Use of appendices vs. inline content

Common Formats:

• Microsoft Word document (most common)
• PDF document
• Combination of Word/PDF with embedded diagrams
• GRC platform-generated reports

Best Practice: Use NIST-provided SSP template as starting point, then customize to your organization. NIST offers CUI SSP templates at https://csrc.nist.gov/Projects/protecting-cui

SSP Development Process

Step 1: Conduct Gap Analysis

• Assess current state against all 110 NIST 800-171 requirements
• Identify which requirements are MET, NOT MET, or not applicable
• Document evidence for each requirement

Step 2: Define System Boundaries

• Identify all systems processing, storing, or transmitting CUI
• Map security protection assets
• Create authorization boundary diagram
• Document external connections

Step 3: Gather Documentation

• Collect existing policies, procedures, and configurations
• Create network and data flow diagrams
• Compile hardware and software inventories
• Gather user lists and role descriptions

Step 4: Write Implementation Descriptions

• For each of the 110 requirements, write detailed implementation description
• Use “Who, What, How, Where, When” framework
• Reference specific technologies, tools, and procedures
• Identify evidence sources

Step 5: Review and Validate

• Technical review by system administrators and security team
• Management review by Authorizing Official
• Legal review if handling sensitive contract requirements
• External review by consultant or RP (optional but recommended)

Step 6: Finalize and Approve

• Incorporate review feedback
• Obtain Authorizing Official signature
• Version and date the document
• Establish review schedule for future updates

Updating the SSP

Update Frequency: SSPs must be reviewed and updated:

• At least annually (minimum requirement)
• When significant changes occur:
  • New systems added to assessment scope
  • Major technology or architecture changes
  • New cloud service providers
  • Changes to security controls or implementation
  • Personnel changes in key security roles
  • After CMMC assessments reveal gaps
  • When closing POA&M items

Update Process:

1. Review all sections of SSP for accuracy
2. Update changed sections with new information
3. Verify implementation descriptions still reflect current state
4. Update version number and date
5. Document changes in revision history
6. Re-approve by Authorizing Official
7. Communicate changes to assessment team and C3PAO (if applicable)

Version Control: Maintain clear version history tracking:

• Version number (e.g., v1.0, v1.1, v2.0)
• Date of version
• Author/reviewer
• Summary of changes
• Next scheduled review date

SSP Integration with CMMC Process

Pre-Assessment:

• C3PAO reviews SSP to determine if organization is assessment-ready
• Inadequate SSP = assessment won’t be scheduled
• Well-documented SSP = faster, smoother assessment process

During Assessment:

• Assessors use SSP as roadmap for testing each requirement
• SSP implementation descriptions are validated through evidence review, interviews, and technical testing
• Discrepancies between SSP and actual implementation = finding

Post-Assessment:

• Update SSP to reflect any changes made during remediation
• Close POA&M items by updating SSP implementation descriptions
• Maintain SSP current for annual affirmations

Annual Affirmations: Each year between triennial assessments, the Affirming Official must affirm continued compliance. Before making this affirmation, the official should:

• Review SSP to ensure it’s still accurate
• Verify controls described in SSP are still operating
• Update SSP if any changes occurred
• Document the review process

Assessment Evidence

To demonstrate compliance with 3.12.4, assessors will review:

• Complete SSP document: All required sections present and detailed
• System boundary diagrams: Clear visual representation of assessment scope
• Data flow diagrams: Showing CUI movement through systems
• Network architecture diagrams: Detailed network topology
• Implementation descriptions: Detailed for all 110 requirements
• Version control: Evidence of regular reviews and updates
• Approval signatures: Authorizing Official has reviewed and approved SSP
• Supporting documentation: Policies, procedures, and configurations referenced in SSP

---

Integration with Other Control Families

Security Assessment requirements don’t operate in isolation. They integrate with and support all other control families:

Audit and Accountability (AU):

• AU provides the audit logs that are reviewed during assessments (3.12.1)
• AU logs provide evidence for continuous monitoring (3.12.3)
• SSP documents how audit requirements are implemented (3.12.4)

Risk Assessment (RA):

• RA.L2-3.11.2 requires security assessments as part of risk assessment process
• Assessment findings inform risk assessments
• POA&Ms document planned risk mitigations

Incident Response (IR):

• Continuous monitoring (3.12.3) detects incidents that trigger IR processes
• Post-incident reviews may identify control deficiencies for POA&Ms (3.12.2)
• SSP documents incident response procedures (3.12.4)

Configuration Management (CM):

• CM provides baseline configurations that are assessed (3.12.1)
• Configuration monitoring is part of continuous monitoring (3.12.3)
• SSP documents configuration management approach (3.12.4)

All Other Control Families:

• SSP documents implementation of requirements from all 14 families (3.12.4)
• Assessments validate effectiveness of controls from all families (3.12.1)
• POA&Ms track deficiencies from any control family (3.12.2)
• Continuous monitoring covers controls from all families (3.12.3)

Common Implementation Challenges

Challenge 1: SSP Development Overwhelm

• Issue: SSP seems like an impossibly large document to create
• Solution: Break it into smaller tasks—complete one control family at a time, use templates, engage consultants or RPs for guidance

Challenge 2: Lack of Documentation

• Issue: Security controls are implemented but not documented
• Solution: Start with “documentation sprints” to capture tribal knowledge, interview technical staff, screenshot configurations, create policies and procedures

Challenge 3: Insufficient Assessment Resources

• Issue: Small organizations lack security expertise for thorough self-assessments
• Solution: Engage consultants, Registered Practitioners, or Managed Security Service Providers (MSSPs) who specialize in NIST 800-171 assessments

Challenge 4: POA&M Closeout Timing

• Issue: 180-day POA&M closeout deadline is tight for complex remediations
• Solution: Before accepting Conditional Status, ensure you have resources, budget, and commitment to close POA&Ms within 180 days—if uncertain, delay assessment until closer to full readiness

Challenge 5: Continuous Monitoring Tool Costs

• Issue: SIEM, vulnerability scanning, and EDR tools are expensive
• Solution: Consider cloud-native solutions (Microsoft Defender, AWS Security Hub), open-source tools (Wazuh, OpenVAS), or managed service providers who provide tooling as part of service

Challenge 6: Keeping SSP Current

• Issue: SSP quickly becomes outdated as systems and controls change
• Solution: Assign SSP ownership to specific role (ISSM), establish quarterly review process, update SSP whenever changes occur rather than waiting for annual review

Challenge 7: Assessment Fatigue

• Issue: Triennial assessments are resource-intensive and disruptive
• Solution: Maintain continuous compliance rather than “cramming” before assessments, leverage managed services for ongoing monitoring and evidence collection, prepare evidence packages throughout the year

Assessment Tips for CA Requirements

For 3.12.1 (Periodic Assessments):

• Document your assessment methodology and follow NIST SP 800-171A procedures
• Gather evidence continuously rather than scrambling before assessments
• Keep assessment results organized and readily available
• Be prepared to explain how you determined MET vs. NOT MET for each requirement

For 3.12.2 (Plans of Action):

• Maintain POA&M as living document—update regularly as progress is made
• Document realistic target dates and ensure resources are allocated
• Avoid putting critical requirements on POA&Ms—remediate them before assessment
• Track POA&M items in project management or ticketing systems

For 3.12.3 (Continuous Monitoring):

• Deploy monitoring tools across all systems processing, storing, or transmitting CUI
• Demonstrate regular review of monitoring outputs—provide sample reports and dashboards
• Show evidence of action taken based on monitoring findings
• Document monitoring procedures and frequency

For 3.12.4 (System Security Plan):

• Write detailed, specific implementation descriptions using “Who, What, How, Where, When” framework
• Ensure SSP accurately reflects your CURRENT implementation (not aspirational)
• Update SSP before assessments to reflect any recent changes
• Have supporting evidence readily available for everything claimed in SSP

Key Takeaways

Critical Points:

1. All 4 CA requirements are mandatory—they’re Basic Security Requirements with no exceptions
2. SSP is prerequisite for assessment—CMMC assessments cannot proceed without complete SSP
3. POA&M limitations are strict—many critical requirements cannot be on POA&Ms for Conditional Status
4. 180-day deadline is firm—POA&Ms must be closed within 180 days or Conditional Status expires
5. Continuous monitoring is separate from assessments—both ongoing monitoring AND triennial assessments are required
6. CA creates compliance foundation—all other control families are documented and validated through CA processes

Implementation Priorities:

1. Develop comprehensive System Security Plan (3.12.4) with detailed implementation descriptions
2. Establish continuous monitoring program (3.12.3) with automated tools and regular reporting
3. Conduct thorough gap analysis/self-assessment (3.12.1) to identify deficiencies
4. Create and maintain Plans of Action (3.12.2) for any gaps identified

Common Mistakes to Avoid:

• Starting CMMC journey without SSP—the SSP is the foundation, not an afterthought
• Putting critical requirements on POA&Ms—these must be MET at time of assessment
• Creating generic, vague SSP—implementation descriptions must be specific and detailed
• Treating assessments as one-time events—continuous monitoring and annual affirmations are ongoing obligations
• Underestimating POA&M closeout effort—180 days passes quickly for complex remediations

Success Factors:

• Start SSP development early—it’s the largest and most important deliverable
• Engage consultants or RPs if lacking internal security expertise
• Maintain continuous compliance rather than cramming before assessments
• Treat POA&Ms as serious project plans with assigned resources and realistic timelines
• Deploy monitoring tools that provide actionable security intelligence
• Keep all documentation current and accurate

---

Last Updated: November 2025

This article provides guidance on Security Assessment (CA) requirements for CMMC Level 2 compliance based on NIST SP 800-171 Revision 2, 32 CFR Part 170, and official DoD CMMC program documentation.