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.