This chapter covers Remediation SLAs and Risk Acceptance, two critical components of vulnerability management in the CS0-003 exam. You'll learn how to define, measure, and enforce remediation timelines based on severity, and when and how to formally accept vulnerabilities rather than fix them. Expect 5-8% of exam questions to touch on these topics, often in scenario-based questions asking you to select the appropriate SLA or risk acceptance action. Mastery of these concepts ensures you can design effective vulnerability management programs and justify business decisions.
Jump to a section
Imagine a company that issues credit and has a collections department. When a customer misses a payment, the severity of the delinquency determines the response. A 30-day late payment triggers an automated reminder (low severity). A 60-day late triggers a phone call (medium severity). A 90-day late triggers a demand letter and credit report flag (high severity). The company has Service Level Agreements (SLAs) for each tier: respond to 30-day late within 2 days, 60-day within 1 day, 90-day within 4 hours. The collections manager tracks these SLAs and escalates if missed. However, some customers are strategic partners—the company may accept the risk of non-payment because the relationship is more valuable. This is risk acceptance: a formal decision to not pursue the debt, documented with justification. Just as a vulnerability might be accepted because compensating controls or business need outweigh the risk, the company waives collection. The SLA ensures that critical debts are handled quickly, while risk acceptance prevents wasted effort on low-priority or unavoidable losses. The collections system logs all actions, and auditors review both SLA adherence and risk acceptance decisions. This mirrors vulnerability management: SLAs drive remediation speed, and risk acceptance provides an exception path for justified non-remediation.
What Are Remediation SLAs?
A Remediation Service Level Agreement (SLA) is a contractual or policy-driven commitment to fix a vulnerability within a specified time frame after discovery. SLAs are tiered by severity: Critical, High, Medium, and Low. Typical SLA targets from industry benchmarks (e.g., NIST, CIS, or internal policies) are:
Critical: 24-48 hours
High: 7-14 days
Medium: 30-45 days
Low: 60-90 days
These are not arbitrary; they reflect the risk of exploitation. A critical vulnerability with a CVSS score of 9.0-10.0 (e.g., Remote Code Execution) must be remediated urgently because exploit code often appears within hours. SLAs are measured from the time of discovery (e.g., when a vulnerability scanner reports the finding) to the time the fix is verified (e.g., a rescan shows the vulnerability is gone).
Why SLAs Exist
SLAs provide accountability and measurable performance. Without SLAs, remediation may be delayed indefinitely, increasing the window of exposure. They also enable prioritization: security teams can focus on critical SLAs first. In regulated industries (PCI DSS, HIPAA), SLAs may be mandatory. For example, PCI DSS Requirement 6.2 mandates that critical vulnerabilities be remediated within 30 days, but many organizations set stricter internal SLAs.
How SLAs Are Defined
SLAs are defined in the organization's vulnerability management policy. Key parameters include: - Severity classification: Usually based on CVSS v3 base score, but can be modified by environmental or temporal metrics. - Remediation time: The maximum allowed time from discovery to fix. - Grace period: Some policies allow a short extension (e.g., 24 hours) for critical vulnerabilities if a patch is unavailable and a workaround is applied. - Escalation path: If an SLA is missed, the issue is escalated to higher management. - Verification method: Typically a rescan, but can include manual testing.
Tracking and Reporting
SLAs are tracked in a vulnerability management platform (e.g., Tenable, Qualys, Rapid7). Dashboards show open vulnerabilities by severity and days since discovery. Alerts trigger when SLAs are at risk (e.g., 80% of time elapsed). Reports are generated for weekly or monthly reviews. Common metrics: - Mean Time to Remediate (MTTR) : Average time to fix vulnerabilities, broken down by severity. - SLA Attainment: Percentage of vulnerabilities fixed within SLA. - SLA Breaches: Count of vulnerabilities that exceeded SLA.
Risk Acceptance Defined
Risk acceptance is a formal decision to not remediate a vulnerability, documented with justification and approval. It is not a default action; it must be intentional. Reasons for risk acceptance include: - Compensating controls: A firewall rule or IPS signature already mitigates the risk. - Low probability of exploitation: The vulnerability requires physical access and the asset is in a secure facility. - Business impact: Patching would cause downtime that outweighs the risk. - False positive: The scanner reported a vulnerability that doesn't actually exist (after verification). - Legacy system: The system is end-of-life and cannot be patched; it is scheduled for retirement.
Risk Acceptance Process
Identification: A vulnerability is identified and assessed.
Justification: The asset owner or risk owner provides a written justification.
Review: The security team reviews the justification against policy.
Approval: The risk is accepted by an authorized individual (e.g., CISO, risk manager).
Documentation: The acceptance is recorded in the vulnerability management system with a timestamp and expiry date.
Periodic review: Accepted risks are reviewed at intervals (e.g., quarterly) to ensure the justification still holds.
Risk Acceptance vs. Remediation vs. Mitigation
Remediation: Fixing the vulnerability (e.g., applying a patch).
Mitigation: Reducing the risk without fully fixing it (e.g., applying a workaround, adding a firewall rule).
Risk Acceptance: Formally accepting the residual risk.
Mitigation is often used when a patch is not yet available; risk acceptance is used when no further action will be taken.
Interaction with Vulnerability Management Lifecycle
SLAs and risk acceptance are integral to the vulnerability management lifecycle: 1. Discover: Scan for vulnerabilities. 2. Assess: Prioritize based on severity and asset criticality. 3. Report: Assign to asset owners with SLA. 4. Remediate: Apply patches or workarounds. 5. Verify: Rescan to confirm fix. 6. Accept: For vulnerabilities not remediated, initiate risk acceptance.
Common Pitfalls
Setting unrealistic SLAs: 24 hours for critical may be impossible if the patch is not tested.
Ignoring compensating controls: A vulnerability may be acceptable if mitigated, but the process must be documented.
Expired risk acceptances: Often forgotten; periodic reviews are essential.
No escalation: Without escalation, SLAs are meaningless.
Exam Relevance
CS0-003 Objective 2.3: "Given a scenario, analyze the output from a vulnerability scan and recommend appropriate remediation or risk acceptance." You must be able to:
Determine the correct SLA based on severity.
Identify when risk acceptance is appropriate.
Interpret scan results and decide whether to patch, mitigate, or accept.
Recognize the need for documentation and approval.
Specific Values on the Exam
Critical: 24 hours (some questions use 48 hours)
High: 7 days
Medium: 30 days
Low: 90 days
These are not absolute; the exam may provide a policy and ask you to apply it. Always read the scenario's SLA definition.
Command and Configuration Examples
While SLAs are policy-based, vulnerability management tools allow configuration. Example in Qualys (using API to set SLA):
{
"sla": {
"critical": 24,
"high": 168,
"medium": 720,
"low": 2160
}
}In Tenable.sc, you can define SLA thresholds in the policy settings.
Summary
Remediation SLAs ensure timely fixing of vulnerabilities; risk acceptance provides a formal exception path. Both require documentation and approval. The exam tests your ability to apply these concepts in real-world scenarios.
Discover Vulnerabilities via Scan
The process begins with a vulnerability scan using a tool like Nessus, Qualys, or OpenVAS. The scan identifies vulnerabilities on target assets, assigning a CVSS score and severity (Critical, High, Medium, Low). The scan output includes details such as the vulnerability name, affected software, and potential impact. This discovery triggers the SLA clock. The scan is typically scheduled (e.g., weekly) or event-driven (e.g., after a patch release). The timestamp of discovery is recorded in the vulnerability management database.
Assess and Prioritize Vulnerabilities
Each vulnerability is assessed based on severity (CVSS score) and asset criticality. For example, a Critical vulnerability on a domain controller is higher priority than a Medium vulnerability on a test server. The security team assigns a remediation priority, often using a risk matrix. This step determines which SLA applies. The SLA clock is already running from discovery; prioritization does not stop the clock. The assessment may also consider compensating controls that could reduce the urgency.
Assign to Asset Owner with SLA
The vulnerability is assigned to the asset owner (e.g., system administrator) with a clear SLA deadline. The assignment is usually automated via ticketing system integration (e.g., ServiceNow). The ticket includes the vulnerability details, severity, and required remediation date. The asset owner is responsible for applying the fix or initiating mitigation. The SLA deadline is calculated from the discovery timestamp. For example, if discovered on June 1 at 10:00 AM and the SLA for Critical is 24 hours, the deadline is June 2 at 10:00 AM.
Remediate or Mitigate the Vulnerability
The asset owner applies a patch, configuration change, or workaround. For example, applying a security update for a Critical RCE vulnerability. If a patch is unavailable, a mitigation may be applied, such as disabling the service or adding a firewall rule. The remediation must be verified later. The asset owner documents the action taken. If the vulnerability cannot be fixed within the SLA, the asset owner may request an extension or initiate risk acceptance.
Verify Remediation via Rescan
After remediation, a rescan is performed to confirm the vulnerability is no longer present. The rescan can be targeted (only the affected asset) or part of the next scheduled scan. The vulnerability management system compares the new scan results with the previous findings. If the vulnerability is gone, the SLA is marked as met. If not, the issue remains open and may escalate. Verification is critical; a false sense of security can occur if remediation is not confirmed.
Document and Approve Risk Acceptance if Needed
If the vulnerability cannot be remediated or mitigated, the asset owner submits a risk acceptance request. The request includes justification, such as business criticality or compensating controls. The security team reviews and either approves or rejects. Approved acceptances are documented with an expiry date (e.g., 90 days). The vulnerability remains open but is flagged as accepted. Periodic reviews ensure the acceptance is still valid. If conditions change (e.g., a patch becomes available), the acceptance may be revoked.
Report and Review SLA Performance
Regular reports are generated to track SLA attainment and risk acceptance trends. Reports are reviewed in security meetings with stakeholders. Metrics include number of open vulnerabilities, MTTR, and SLA breach count. Trends help adjust policies. For example, if critical SLAs are frequently missed, the team may investigate root causes (e.g., patch deployment delays). Risk acceptance reports show the number of accepted vulnerabilities and upcoming expirations. This step closes the loop and drives continuous improvement.
In a large financial institution, the vulnerability management team uses Qualys to scan 10,000 assets weekly. Critical vulnerabilities have an SLA of 48 hours, High 7 days, Medium 30 days, Low 90 days. The team integrates with ServiceNow; when a critical vulnerability is found, a ticket is automatically created and assigned to the system owner with a due date 48 hours from discovery. The owner must apply the patch and then request a rescan. If the SLA is missed, the ticket escalates to the CISO. For a recent RCE vulnerability in Apache Struts, the team had to patch over 500 servers within 48 hours. They used automated patch management tools but still faced challenges with legacy systems that couldn't be patched. Those were mitigated by blocking the vulnerable endpoint at the firewall and the risk was accepted with a 30-day expiry, during which the systems were upgraded.
In a healthcare organization, HIPAA compliance requires that critical vulnerabilities be remediated within 30 days, but the organization set a stricter internal SLA of 7 days. They use Tenable.sc and have defined SLAs in the policy. A common issue is false positives; for example, a scanner reported a missing patch that was actually applied via a different method. The team must verify before marking as fixed. They also have a risk acceptance process for medical devices that cannot be patched because they are FDA-approved and patching would void certification. The risk acceptance is documented and reviewed quarterly.
In a cloud-native company, vulnerabilities are often in container images. They use a CI/CD pipeline with integrated scanning. If a critical vulnerability is found in a production image, the SLA is 24 hours. The team can roll back to a previous image or rebuild with a patched base image. Risk acceptance is rare because containers are ephemeral; if a fix is not possible, the container is replaced. However, for some proprietary images, they may accept the risk temporarily. The key challenge is keeping the SLA clock accurate across multiple environments and automated deployments. Misconfiguration can lead to missed SLAs due to scan timing discrepancies.
The CS0-003 exam tests Objective 2.3 through scenario-based questions. You will be given a vulnerability scan output and asked to recommend an action: remediate, mitigate, or accept risk. The key is to read the scenario carefully for clues about compensating controls, business impact, and policy.
Common wrong answers: 1. Choosing 'remediate' when the scenario indicates a false positive or when a compensating control already exists. Candidates often assume all vulnerabilities must be patched. 2. Choosing 'risk acceptance' without proper justification. The exam expects that risk acceptance requires documented approval and periodic review. Simply ignoring a vulnerability is not acceptance. 3. Misapplying SLAs: e.g., applying a 7-day SLA to a critical vulnerability because the scenario mentions 'high' but the CVSS score is 9.8 (critical). Always check the severity. 4. Confusing mitigation with remediation: Mitigation reduces risk but does not fix the vulnerability. The exam may ask for the best action; if a patch is available, remediation is preferred over mitigation.
Specific terms that appear on the exam: - 'Compensating control' – a control that reduces risk. - 'Risk register' – where accepted risks are documented. - 'SLA breach' – when remediation exceeds the allowed time. - 'Rescan' – verification step.
Edge cases:
A vulnerability on a system that is scheduled for decommissioning in 60 days. The best action is risk acceptance with a short expiry.
A vulnerability that has no patch but a workaround exists. The best action is mitigation, not acceptance.
A vulnerability that was previously accepted but conditions changed (exploit released). The acceptance should be revoked and remediation performed.
To eliminate wrong answers, ask: Does the scenario mention a patch? If yes, remediate. If no, is there a workaround? If yes, mitigate. If no, is there a business reason to accept? If yes, accept with documentation. Always look for approval language.
Remediation SLAs are tiered by severity: Critical 24-48h, High 7d, Medium 30d, Low 90d (varies by policy).
Risk acceptance requires formal documentation, justification, approval, and periodic review.
Mitigation reduces risk but does not fix the vulnerability; remediation fixes it.
SLAs are measured from discovery to verified fix; rescan is essential.
Compensating controls can justify risk acceptance or mitigation.
Accepted risks must have an expiry date and be reviewed quarterly.
The exam expects you to apply the scenario's specific policy, not generic industry values.
These come up on the exam all the time. Here's how to tell them apart.
Remediation
Fixes the vulnerability completely
Requires patch or configuration change
Eliminates the risk
Must be verified by rescan
Preferred when patch is available
Risk Acceptance
Does not fix the vulnerability
Requires documented justification and approval
Accepts residual risk
Must be reviewed periodically
Used when remediation is not feasible
Mistake
Risk acceptance means ignoring the vulnerability.
Correct
Risk acceptance is a formal, documented decision with approval and periodic review. It is not neglect.
Mistake
All critical vulnerabilities must be patched within 24 hours.
Correct
SLAs vary by organization policy. The exam will provide the policy; you must apply it.
Mistake
Mitigation is the same as remediation.
Correct
Remediation fixes the vulnerability (e.g., patch). Mitigation reduces risk without fixing (e.g., firewall rule).
Mistake
Once risk is accepted, it never needs review.
Correct
Accepted risks must be periodically reviewed (e.g., quarterly) and revoked if conditions change.
Mistake
SLAs only apply to critical vulnerabilities.
Correct
SLAs apply to all severity levels, with different time frames.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Remediation is the complete fixing of a vulnerability, typically by applying a patch or configuration change. Mitigation reduces the risk of exploitation without fully eliminating the vulnerability, such as by adding a firewall rule or disabling a service. Mitigation is used when a patch is not yet available or cannot be applied, but it is not a permanent solution. Risk acceptance is a separate decision to not take any action.
Risk acceptance should be chosen when remediation is not feasible (e.g., no patch available, system end-of-life) or when the risk is justified by business need (e.g., patching would cause unacceptable downtime). It must be documented with a justification and approved by an authorized individual. The accepted risk must be reviewed periodically to ensure conditions haven't changed.
Typical SLA for critical vulnerabilities is 24 to 48 hours, depending on organization policy. Industry standards like PCI DSS require 30 days, but many organizations set stricter internal SLAs. The exam will provide the policy in the scenario; always use that value.
Verification is done by performing a rescan of the asset after the remediation action. The vulnerability management system compares the new scan results with the previous findings. If the vulnerability no longer appears, it is considered fixed. Manual verification may also be used for complex cases. The rescan timestamp marks the end of the SLA clock.
A compensating control is an alternative security measure that reduces the risk of a vulnerability. For example, if a web server has a vulnerability but a WAF blocks exploit attempts, the WAF is a compensating control. This can justify risk acceptance or mitigation. The control must be documented and its effectiveness verified.
Yes, if conditions change (e.g., a patch becomes available, an exploit is released in the wild), the risk acceptance should be reviewed and potentially revoked. The vulnerability must then be remediated or mitigated. This is why periodic reviews are essential.
If an SLA is missed, the issue is typically escalated to higher management. The vulnerability remains open and may be re-prioritized. Escalation ensures accountability. Some organizations have penalty clauses for repeated SLA breaches.
You've just covered Remediation SLAs and Risk Acceptance — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?