Remediation, Compensating Controls, and Risk-Based Decisions
Key Takeaways
- Remediation removes or fixes the weakness; mitigation reduces likelihood or impact; a compensating control substitutes when the preferred control is not feasible.
- Risk-based decisions weigh asset value, exposure, exploitability, operational impact, available controls, and business deadlines.
- Exceptions must be documented, approved by the risk owner, time-bound, and reviewed before expiration.
- Compensating controls such as segmentation, monitoring, WAF rules, or access restrictions must be specific and matched to the risk.
- Verification is mandatory: a ticket marked complete is not the same as a validated, rescanned fix.
Pick the Best Action When the Ideal Fix Is Not Available
SY0-701 frequently asks for the best response when the perfect patch cannot ship today. Separate the vocabulary precisely, because CompTIA writes distractors that swap these terms.
| Term | Meaning | Example |
|---|---|---|
| Remediation | Fix or remove the weakness | Install the patch, remove public access |
| Mitigation | Reduce likelihood or impact | Add rate limiting, restrict source IPs |
| Compensating control | Alternative when the primary control is infeasible | Segment an unsupported system until replacement |
| Risk acceptance | Owner formally approves residual risk | Time-bound exception for a legacy app |
| Risk avoidance | Stop the risky activity entirely | Shut down an unused exposed service |
| Risk transfer | Shift financial/contractual impact | Cyber insurance or vendor indemnity |
A compensating control is not a second-rate guess; it is a deliberate substitute that achieves comparable risk reduction when you cannot apply the intended control, and it is typically temporary and documented.
Selecting a Control
| Situation | Best practical response |
|---|---|
| Patch exists, change risk is low | Patch via normal or emergency change |
| Patch exists but needs an outage window | Temporary controls now, schedule patch, track due date |
| No patch exists | Workaround, restrict exposure, monitor, follow vendor guidance |
| System is end-of-life | Replace or upgrade; segment and monitor temporarily |
| Business must keep a vulnerable app briefly | Document exception, add compensating controls, set expiry |
| Exploitation is active | Contain exposure immediately, then eradicate and recover |
Compensating Control Examples
Controls must be specific. "Monitor it" is a weak answer unless you define what is watched, where alerts go, and what action follows.
| Risk | Compensating controls |
|---|---|
| Legacy server unpatchable for 30 days | Network segmentation, allow-list access, EDR monitoring, increased logging |
| Vulnerable web endpoint awaiting a code fix | WAF virtual patch, rate limiting, monitoring, expedited release |
| Admin interface needed by a remote team | VPN or ZTNA, MFA, source restrictions, session logging |
| Weak third-party integration | Scope the API token, monitor usage, set a contractual remediation date |
Worked Decision Example
A medical scheduling server runs an unsupported OS. Replacement is funded and scheduled in 45 days, but the system must stay online. "Ignore it" and "take it offline" are both wrong. A defensible plan:
| Step | Reason |
|---|---|
| Restrict network access to only required application paths | Reduces exposure |
| Remove local admin rights and unused services | Shrinks attack surface |
| Increase logging and EDR coverage | Improves detection |
| Document a time-bound exception approved by the risk owner | Makes residual risk explicit and accountable |
| Track the replacement as the final remediation | Removes the unsupported-platform risk |
Residual risk is what remains after controls are applied; the business or risk owner, not the analyst, formally accepts it.
The order of operations matters on exam scenarios. Inherent risk is the exposure before any control; you reduce it with remediation or mitigation; what is left is residual risk; and only a designated owner may accept that residual risk through a documented, time-bound exception. An analyst who accepts risk on their own authority, or who lets an exception run past its review date, has failed the governance test CompTIA is checking. The exception record should name the risk, the owner, the compensating controls, the expiration date, and the review trigger so that nothing lingers silently.
Verification and Closure
Closure must rest on evidence that the risky condition actually changed, not on a status field.
| Claimed fix | Verification method |
|---|---|
| Patch installed | Credentialed rescan or package/version validation |
| Public storage removed | Policy review plus an anonymous-access test |
| Firewall rule tightened | Config review plus a connection test |
| Secret rotated | Confirm the old key fails and the new key is stored correctly |
| Vulnerable code fixed | Code review, regression test, DAST/SAST as appropriate |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| Accept risk without owner approval | Residual-risk acceptance belongs to the business/risk owner |
| Leave compensating controls forever | Exceptions must expire or be reviewed |
| Close tickets without verification | Validate with concrete evidence |
| Default to the most disruptive option | Balance risk reduction against business impact |
| One generic control for every vulnerability | Match the control to the attack path and weakness |
Quick Drill
Choose the response:
- Critical patch for an internet-facing gateway, exploit active: emergency patch or vendor workaround immediately, with containment as needed.
- Legacy internal app unpatchable for 20 days: segment, restrict access, monitor, document a time-bound exception, schedule remediation.
- Public bucket exposed confidential data: remove public access, investigate access logs, rotate any exposed secrets, notify per policy.
- Scanner shows "fixed" but no validation exists: rescan or run a targeted verification before closing.
- Vendor wants to accept risk on a payment system: route to the named risk owner, time-box it, and add compensating controls.
A legacy system cannot be patched for 30 days but must remain online. Which approach is most appropriate?
After a team claims a firewall rule was tightened, what should happen before closing the vulnerability ticket?
Which are valid compensating controls for an unpatchable legacy server? Select two.
Select all that apply