Skip to main content
NetStable
Level 2 RA.L2-3.11.2

Scan for vulnerabilities in organizational systems and applications

📖 What This Means

This practice requires organizations to actively scan their systems and applications for vulnerabilities—weaknesses that could be exploited by attackers. It involves using automated tools to identify issues like outdated software, misconfigurations, or missing patches. The goal is to detect and fix these vulnerabilities before they can be used to compromise sensitive data or disrupt operations. For example, a company might scan its servers and find that an old version of a web server software is being used, which has known security flaws. By updating the software, they reduce the risk of a cyberattack. Another example could be scanning employee laptops to ensure they have the latest antivirus updates installed. This practice is critical because it helps prevent breaches and ensures compliance with DoD cybersecurity requirements.

🎯 Why It Matters

Unpatched vulnerabilities are a leading cause of data breaches. For instance, the Equifax breach in 2017 occurred due to an unpatched vulnerability in Apache Struts, exposing the personal data of 147 million people. Such incidents can cost millions in fines, lawsuits, and reputational damage. For defense contractors, failing to scan for vulnerabilities could lead to the compromise of Controlled Unclassified Information (CUI) or other sensitive DoD data. The DoD emphasizes this control to ensure contractors proactively identify and mitigate risks to their systems. By regularly scanning for vulnerabilities, organizations can reduce the likelihood of successful cyberattacks and demonstrate their commitment to cybersecurity.

How to Implement

  1. 1. Enable cloud-native vulnerability scanning tools (e.g., AWS Inspector, Azure Security Center, GCP Security Command Center).
  2. 2. Configure scanning schedules to run weekly or monthly, depending on your risk profile.
  3. 3. Ensure all cloud assets (e.g., EC2 instances, S3 buckets) are included in the scan scope.
  4. 4. Integrate scan results with a Security Information and Event Management (SIEM) tool for centralized monitoring.
  5. 5. Automate patch management workflows to remediate critical vulnerabilities promptly.
  6. 6. Review and update cloud security policies to align with CMMC requirements.
  7. 7. Document scan results and remediation actions in a vulnerability management report.
⏱️
Estimated Effort
Initial setup: 8-16 hours (intermediate skill level). Ongoing: 4-8 hours per scan cycle (basic skill level).

📋 Evidence Examples

Vulnerability Scan Report

Format: PDF
Frequency: Weekly/Monthly
Contents: Scan results, identified vulnerabilities, severity levels, remediation status
Collection: Export from scanning tool

Remediation Plan

Format: Excel
Frequency: Updated after each scan
Contents: List of vulnerabilities, assigned tasks, due dates, completion status
Collection: Manual or automated tracking

Scan Configuration Screenshots

Format: PNG
Frequency: After initial setup and major changes
Contents: Scan scope, schedules, asset lists
Collection: Capture from scanning tool UI

IT Staff Training Records

Format: PDF
Frequency: Annually
Contents: Training dates, attendees, topics covered
Collection: HR or training system export

Vulnerability Management Policy

Format: PDF
Frequency: Reviewed annually
Contents: Scan schedules, roles/responsibilities, remediation timelines
Collection: Document repository

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For RA.L2-3.11.2 ("Scan for vulnerabilities in organizational systems and applications"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your risk assessment program, including methodology, frequency, vulnerability scanning tools and schedule, insider threat monitoring, and how risk decisions are documented. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"RA.L2-3.11.2 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to scan for vulnerabilities in organizational systems and applications. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."

On-Premise

"RA.L2-3.11.2 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to scan for vulnerabilities in organizational systems and applications. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"RA.L2-3.11.2 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."

System Boundary Considerations

  • Define the risk assessment scope (CUI systems and supporting infrastructure)
  • Document vulnerability scanning coverage
  • Specify risk register maintenance process
  • Ensure this control covers all systems within your defined CUI boundary where scan for vulnerabilities in organizational systems and applications applies
  • Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

  • 📄 Risk Assessment Policy
  • 📄 Risk assessment report
  • 📄 Risk register
  • 📄 Vulnerability scan reports
  • 📄 Evidence artifacts specific to RA.L2-3.11.2
  • 📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will review your risk assessment methodology, verify vulnerability scanning frequency and coverage, check that identified risks are tracked in a risk register, and confirm executive risk acceptance decisions are documented.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Do you have a vulnerability scanning tool deployed?

✅ YES → Proceed to Q2
❌ NO → GAP: Purchase and deploy a scanning tool (e.g., Nessus, OpenVAS). Timeline: 1 week.

Question 2: Are all systems and applications included in the scan scope?

✅ YES → Proceed to Q3
❌ NO → GAP: Update scan scope to include all assets. Timeline: 1 day.

Question 3: Are scans performed at least monthly?

✅ YES → Proceed to Q4
❌ NO → GAP: Configure scanning schedules to run monthly. Timeline: 1 day.

Question 4: Are critical vulnerabilities remediated within 30 days?

✅ YES → Proceed to Q5
❌ NO → GAP: Develop a remediation plan with clear deadlines. Timeline: 1 week.

Question 5: Are scan results and remediation actions documented?

✅ YES → Compliance confirmed
❌ NO → GAP: Create vulnerability management reports. Timeline: 1 day.

⚠️ Common Mistakes (What Auditors Flag)

1. Scanning only parts of the network

Why this happens: Incomplete asset inventories or misconfigured scan scopes
How to avoid: Maintain an updated asset inventory and verify scan scope regularly.

2. Not remediating critical vulnerabilities promptly

Why this happens: Lack of prioritization or resources
How to avoid: Establish a remediation policy with clear timelines and assign responsibilities.

3. Failing to document scan results

Why this happens: Focusing on remediation without proper documentation
How to avoid: Automate report generation and store reports in a centralized repository.

4. Using outdated scanning tools

Why this happens: Neglecting updates or license renewals
How to avoid: Regularly update scanning tools and ensure licenses are active.

5. Ignoring cloud assets in scans

Why this happens: Lack of familiarity with cloud environments
How to avoid: Include cloud assets in scan scope and use cloud-native tools.

📚 Parent Policy

This practice is governed by the Risk Assessment Policy

View RA Policy →

📚 Related Controls