Remediation, Compensating Controls, and Risk-Based Decisions
Key Takeaways
- Remediation removes or fixes a vulnerability; mitigation reduces likelihood or impact; a compensating control reduces risk when the preferred control is not feasible.
- Risk-based decisions consider asset value, exposure, exploitability, operational impact, available controls, and business deadlines.
- Exceptions should be documented, approved by the risk owner, time-bound, and reviewed before expiration.
- Compensating controls such as segmentation, monitoring, WAF rules, or access restrictions are useful but should be matched to the risk.
- Verification is required: a ticket marked complete is not the same as a validated fix.
Last updated: April 2026
Remediation, Compensating Controls, and Risk-Based Decisions
The exam often asks for the best action when the ideal fix is not immediately possible. Separate the concepts:
| Term | Meaning | Example |
|---|---|---|
| Remediation | Fix or remove the weakness | Install patch, remove public access |
| Mitigation | Reduce likelihood or impact | Add rate limiting, restrict source IPs |
| Compensating control | Alternative control when primary control is not feasible | Segment unsupported system until replacement |
| Risk acceptance | Business owner approves residual risk | Time-bound exception for a legacy app |
| Risk avoidance | Stop the risky activity | Shut down unused exposed service |
| Risk transfer | Shift financial or contractual impact | Insurance or vendor indemnity |
Selecting a Control
| Situation | Best practical response |
|---|---|
| Patch exists and change risk is low | Patch through normal or emergency process |
| Patch exists but outage window is required | Use temporary controls, schedule patch, track due date |
| No patch exists | Apply workaround, restrict exposure, monitor, follow vendor guidance |
| System is end-of-life | Replace or upgrade; segment and monitor temporarily |
| Business must keep vulnerable app briefly | Document exception, add compensating controls, set expiration |
| Exploitation is active | Contain exposure immediately, then eradicate and recover |
Compensating Control Examples
| Risk | Compensating controls |
|---|---|
| Legacy server cannot be patched for 30 days | Network segmentation, allow-list access, EDR monitoring, increased logging |
| Vulnerable web endpoint awaiting code fix | WAF virtual patch, rate limiting, monitoring, expedited release |
| Admin interface needed by remote team | VPN or ZTNA, MFA, source restrictions, session logging |
| Weak third-party integration | Scope API token, monitor usage, contractual remediation date |
Compensating controls should be specific. "Monitor it" is weak if nobody defines what to monitor, where alerts go, and what action follows.
Worked Decision Example
A medical scheduling server uses an unsupported operating system. Replacement is funded and scheduled in 45 days, but the system must remain online. The best answer is not to ignore the risk. A practical plan could include:
| Step | Reason |
|---|---|
| Restrict network access to only required application paths | Reduces exposure |
| Remove local admin rights and unused services | Reduces attack surface |
| Increase logging and EDR coverage | Improves detection |
| Document a time-bound exception approved by the risk owner | Makes residual risk explicit |
| Track replacement as the final remediation | Removes the unsupported platform risk |
Verification and Closure
| Claimed fix | Verification method |
|---|---|
| Patch installed | Credentialed rescan or package/version validation |
| Public storage removed | Policy review and anonymous access test |
| Firewall rule tightened | Config review and connection test |
| Secret rotated | Confirm old key fails and new key is stored correctly |
| Vulnerable code fixed | Code review, test case, DAST/SAST as appropriate |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| Accept risk without owner approval | Residual risk acceptance belongs to the right business or risk owner |
| Leave compensating controls forever | Exceptions should expire or be reviewed |
| Close tickets without verification | Validate with evidence |
| Pick the most disruptive option by default | Balance risk reduction with business impact |
| Use one generic control for every vulnerability | Match control to attack path and weakness |
Quick Drill
Choose the response:
- Critical patch for internet-facing gateway, exploit active: emergency patch or vendor workaround immediately, with containment as needed.
- Legacy internal app cannot be patched for 20 days: segment, restrict access, monitor, document exception, schedule remediation.
- Public bucket exposed confidential data: remove public access, investigate access logs, rotate exposed secrets if any, notify according to policy.
- Scanner says "fixed" but no validation exists: rescan or perform a targeted verification before closure.
Test Your Knowledge
A legacy system cannot be patched for 30 days but must remain online. Which approach is most appropriate?
A
B
C
D
Test Your Knowledge
After a team claims a firewall rule was tightened, what should happen before closing the vulnerability ticket?
A
B
C
D
Test Your KnowledgeMulti-Select
Which are valid compensating controls for an unpatchable legacy server? Select two.
Select all that apply
Network segmentation
Enhanced monitoring
Anonymous public access
Shared administrator password