Objective 2.3 · Lesson 2 of 2

Choose a treatment and prove it worked

Remediation is complete when evidence supports the intended result. A closed change ticket or a disappearing dashboard item is useful workflow information, but neither independently proves reduced exposure.

Select a change that addresses the cause

Patching can remove a software defect; configuration management can correct an unsafe setting and keep it from returning. Attack surface management can remove an unnecessary service, stale public endpoint, or unused permission. Match the action to the cause of the finding. Blocking one observed request pattern may reduce immediate exposure while leaving the underlying application flaw available through another route.

For application weaknesses, work with developers on secure coding and regression coverage. Examples include enforcing authorisation at the server, using parameterised database access, and validating expected inputs. Prepare representative tests, deployment checks, and a rollback plan. Assess dependencies before changing shared components so the team reduces security risk without unexpectedly disabling an essential business workflow.

Use compensating controls with an expiry

When a supported fix is unavailable or cannot be deployed safely yet, identify controls that interrupt the relevant attack path. Restricting access to a vulnerable management interface can reduce exposure; targeted monitoring can shorten detection time but does not remove the flaw. Describe what each control does and what remains possible. Avoid presenting a detective control as if it prevents exploitation.

Create an exception with a named risk owner, business reason, affected assets, residual risk, compensating controls, review date, and conditions that end the exception. Seek approval through the established process and agree escalation if controls fail or exploitation evidence changes. An exception is a managed decision with a deadline, not a way to make the finding disappear from reporting.

Verify both security and service behaviour

Define closure evidence before implementation: the corrected package or setting, a successful relevant retest, and confirmation that the intended instances received the change. Use comparable scope and access to the original assessment. A finding that disappears because the scanner lost credentials or the application went offline has not been demonstrated to be fixed. Keep failed or skipped checks visible.

Verify normal service behaviour and check that configuration or deployment automation will preserve the correction. For temporary controls, test the restricted access path and the associated monitoring, then continue tracking the underlying issue. Retain before-and-after evidence with dates and responsible owners. Reopen the item if later deployment, drift, or expanded exposure invalidates the original closure conditions.

Keep these points in mind

  • Prefer treatments that address the weakness or remove the unnecessary exposure.
  • Temporary controls need ownership, residual-risk documentation, and review conditions.
  • Close findings only when relevant retests and service checks succeed with adequate coverage.

Pause and practise

An application cannot accept its security update until a dependency is tested. Draft a temporary treatment and three closure criteria.

Show a worked response

Limit the affected feature to the minimum required users or disable it if the business permits, add relevant monitoring, and record a time-bound exception with the owner. Close the underlying finding only after the supported update reaches every affected instance, the original check passes with valid assessment access, and regression tests confirm the required business workflow still functions.

← Previous lesson