Nobody loves a physical. The waiting room, the blood draw, the doctor frowning at a number on a chart. But skipping it doesn’t mean nothing’s wrong, it just means you find out later, at a worse time, in a worse way. Vulnerability management is your network’s version of the annual checkup: scan regularly, take the results seriously, and treat what needs treating before it becomes an emergency.
This nugget covers the Risk Assessment (RA) controls that structure the exam and the System and Information Integrity (SI) controls that keep your systems’ immune response running day to day.
The Exam Itself (Risk Assessment)
RA.L2-3.11.1: Periodically assess the risk to organizational operations, assets, and individuals
This is the physical exam that everything else in this nugget depends on, and it deserves to be named up front. Before you can scan intelligently or prioritize remediation, you need a documented, periodic risk assessment establishing what you’re protecting and what threatens it. Frameworks like NIST SP 800-30 provide the methodology, and a Business Impact Analysis can round out the picture by identifying which systems and data would hurt the most if compromised. This isn’t a one-time exercise; treat it like the checkup itself, done on a defined schedule and retained as evidence.
RA.L2-3.11.2: Scan for vulnerabilities periodically and when new vulnerabilities are identified
Regular bloodwork, plus an urgent test the moment something concerning shows up.
- Automated scanning tools running on a defined schedule (weekly, monthly, whatever your risk assessment supports), plus on-demand scans when new vulnerabilities are disclosed
- Patch management integration so findings translate into action
- Threat intelligence feeds keeping you aware of newly disclosed vulnerabilities relevant to your environment
One distinction worth making explicit: it’s strongly recommended to perform authenticated scans whenever possible. An unauthenticated scan looks at your systems from the outside, the way a stranger would; an authenticated scan logs in and looks from the inside, surfacing far more than an external view ever could. If your scanning program has only ever run unauthenticated, you’re getting a fraction of the real picture.
RA.L2-3.11.3: Remediate vulnerabilities in accordance with risk assessments
Diagnosis without treatment doesn’t help anyone. This control requires vulnerabilities to actually get fixed, and fixed on a timeline that reflects severity, not “whenever it comes up.”
- A structured patch management process prioritizing critical vulnerabilities first
- Change management (ITIL-based or equivalent) so remediation doesn’t introduce new problems while solving old ones
- A documented vulnerability management policy defining roles, responsibilities, and specific remediation timelines tied to risk tier, critical findings addressed in days, not whenever the next maintenance window happens to fall
Here’s the connection that’s easy to miss: vulnerabilities you can’t remediate immediately don’t just disappear from your obligations. They belong in your POA&M (covered in depth in Nugget #23), your organization’s documented plan for tracking and eventually closing exactly this kind of gap. A risk assessment identifies the problem, a scan confirms it, remediation fixes it, and the POA&M is where anything not yet fixed gets tracked until it is. Skipping that last link is one of the more common ways organizations lose the thread on their own vulnerability program.
The Immune System (System and Information Integrity)
SI.L2-3.14.1: Identify, report, and correct system flaws in a timely manner
The detection-and-response loop for the flaws your exam turns up.
- Issue tracking to log, manage, and close out identified flaws
- Regular audits surfacing problems before they’re exploited
- An incident response plan ready to engage when something needs fast correction
SI.L2-3.14.2: Provide protection from malicious code at designated locations
Your baseline immune defenses
- Antivirus and antimalware deployed across endpoints and servers
- Network segmentation limiting how far an infection can spread if it gets in anyway
- Email and web filtering blocking malicious content before it reaches anyone
SI.L2-3.14.4: Update malicious code protection mechanisms when new releases are available
An immune system that doesn’t update its defenses against new threats isn’t much of one. Automatic updates, integrated into your broader patch management process, with regular reviews confirming everything is actually current rather than assumed current.
SI.L2-3.14.5: Perform periodic scans and real-time scans of files from external sources
Ongoing surveillance, not just a checkup once a year. Endpoint protection with real-time scanning as files are downloaded, opened, or executed, plus scheduled full-system scans and network-level detection (IDS/IPS) watching traffic for malicious activity.
One note on scope: File Integrity Monitoring doesn’t really belong under this control, it’s about scanning files for malicious code, not detecting unauthorized changes to files that are already trusted. FIM fits more naturally alongside the continuous monitoring covered under SI.L2-3.14.6 in Nugget #20, so that’s the better home for it if you’re building out that capability. Alternatively, it can also be mapped to CM.L2.3.4.1 (baseline integrity) or CM.L2.3.12.3 (continuous monitoring) if it fits better in your organization.
A few SI controls that round out this picture, SI.L2-3.14.3, 3.14.6, and 3.14.7, were already covered in Nugget #20 alongside the audit controls they work in tandem with. Between that nugget and this one, the full SI story for detecting and responding to threats is now complete!
Common Failures Across This Control Set
RA.L2-3.11.1 Risk assessment never formally documented or repeated on a defined schedule
RA.L2-3.11.2 Scanning is unauthenticated only, missing internal vulnerabilities an outside view can’t see
RA.L2-3.11.3 Remediation timelines undefined or not tied to severity; critical findings sit as long as minor ones
SI.L2-3.14.4 Antivirus signature updates enabled by default but never actually verified as current
SI.L2-3.14.5 Real-time scanning configured, but no periodic full-system scan scheduled alongside it
SSP Mapping Note
RA and SI are separate families and belong in separate SSP sections. A useful narrative thread to include regardless of section: risk assessment identifies exposure, scanning confirms specific vulnerabilities, SI controls provide the ongoing defensive layer, and remediation (backed by your POA&M for anything not yet closed) is where it all resolves.
For each control your SSP should document:
- The specific tools and technical implementation (scanning platform, EPP, patch management system)
- The policy governing scan frequency, remediation timelines by risk tier, and update cadence
- Who owns risk assessment, scanning, and remediation, they don’t have to be the same person
- How compliance is verified and how often
Skipping the checkup doesn’t make the problem go away, it just moves the discovery to a worse moment. If your scanning and remediation program could use a second opinion, DTC’s team is ready to take a look before an assessor does.