Requirement ID: VDR-CSO-RES
The requirement
Providers MUST systematically, persistently, and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities within their cloud service offering; this process is called vulnerability response. (force: MUST)
This single statement applies to all providers for the subset of a cloud service offering (CSO) described in the source.
What does this mean?
Once a vulnerability is found in your cloud service offering, you cannot just log it and forget it. This requirement asks providers to run a complete, ongoing lifecycle around every detected vulnerability.
That lifecycle covers a full set of activities: tracking each finding, evaluating its severity, monitoring it over time, mitigating it, remediating it, assessing whether it has been exploited, and reporting on it. The words “systematically, persistently, and promptly” describe how this work should happen. Systematic means it follows a repeatable process. Persistent means it continues steadily over time, with any pauses being intentional and documented. Prompt means you act without unnecessary delay.
In short, vulnerability response is the disciplined, continuous handling of everything you find, from first detection until it is remediated or the residual risk is understood and accepted.
This article is also a LinkedIn newsletter. If you would like to receive it straight to your inbox, subscribe here.
Why does this matter?
A vulnerability that is detected but never managed is still an open door. Attackers actively look for known weaknesses, misconfigurations, weak credentials, and unpatched software. The gap between finding a problem and closing it is often where breaches happen.
If vulnerabilities are tracked inconsistently, some will slip through. If response is not persistent, findings pile up and age past the point where anyone remembers the context. If it is not prompt, a known and exploitable weakness may sit exposed while an attacker is already probing it. Assessing exploitation matters because a vulnerability that has been used against you calls for a very different response than one that is only theoretical.
A well-run response process reduces the window of exposure and gives customers and agencies confidence that findings are actually resolved, not just recorded.
What could implementation look like?
The requirement names the activities but does not mandate a specific tool or workflow, so providers have flexibility in how they meet it. One approach could include:
- A central system of record where every detected vulnerability is entered and tracked to closure.
- A consistent evaluation step that assigns severity and potential impact, feeding prioritization.
- Ongoing monitoring so the status of each finding is always known, including partially mitigated and fully mitigated items that are still detected.
- Defined paths to mitigation and remediation, with owners and expected timelines.
- A method to check whether a vulnerability has shown signs of exploitation.
- Reporting that surfaces open findings, aging, and trends to the right stakeholders.
The key idea is that these steps connect into one repeatable process rather than living as scattered, one-off efforts.
Example scenario
A mid-sized provider runs a container-based analytics platform. Their scanning tools flag a misconfigured storage permission that could expose data. The finding is automatically opened as a ticket in their tracking system, tagged with a severity rating after evaluation.
An engineer applies a temporary access restriction as a mitigation, which lowers the likelihood of exploitation but leaves the finding still detected, so it stays open as a partially mitigated item. The team checks logs to assess whether the exposure was ever accessed and finds no evidence of exploitation. A permanent fix is scheduled, applied, and confirmed, at which point the vulnerability is no longer detected and the ticket is closed as remediated. Throughout, the finding appears in the weekly vulnerability report so its status is always visible.
What evidence could demonstrate implementation?
Examples may include:
- Tickets or records tracking individual vulnerabilities from detection to closure.
- A documented vulnerability response procedure describing each lifecycle activity.
- Severity evaluation and prioritization records.
- Status dashboards or reports showing open, mitigated, and remediated findings.
- Records of exploitation assessment for relevant findings.
- Documentation of any intentional pauses or cycles in persistent activities.
Common pitfall
Treating remediation as the only outcome that counts. Some teams close or ignore findings they cannot fully fix, losing sight of partially mitigated vulnerabilities that are still detected and still carry risk. Under this requirement, monitoring and managing those residual items is part of the process, not an optional extra.
Question for your team
For a vulnerability we mitigate but cannot immediately remediate, how do we keep it visible and under active monitoring so its status is always known rather than quietly aging out?
Key takeaway
Every detected vulnerability should move through a steady, repeatable lifecycle from evaluation to resolution, with its status known at all times and residual risk never left unmanaged.
Related requirements
None listed in the source data.
Have a question about putting this requirement into practice?
38North Security can help you turn the requirements into an operating model that works in practice. Talk to us →
The quoted requirement above is from the provided FedRAMP CR-26 JSON for VDR-CSO-RES. The implementation ideas, example scenario, and evidence examples are general guidance and should be validated against official FedRAMP guidance.
