Remediation SLAs, failed patch jobs and auditor evidence
A 350-endpoint Windows 10/11 estate is managed by EMS 7.4 with vulnerability scan and patch management enabled in the assigned profile. After four weeks the vulnerability dashboard shows 1,800 findings. Of these, 240 are rated critical and cluster around a PDF reader, a browser plug-in and missing Windows cumulative updates; the remainder are low or medium, and the same CVEs repeat across many hosts. Patch deployment reports 310 endpoints successful and 40 failed. Most failures are laptops that were travelling during the Wednesday 22:00 deployment window; six desktops have shown pending reboot for two weeks. Endpoints have no direct internet access and use an explicit proxy, while EMS does have internet access. The internal auditor wants a monthly report proving that critical vulnerabilities are remediated within 14 days, and the SIEM team wants EMS events forwarded with 90 days of retention. EMS disk usage has reached 78 percent.
1. How would you turn the 240 critical findings into a defensible remediation plan before the next monthly audit?
Read the worked answer
Start by reducing noise, then rank by risk rather than by count.
Normalise: deduplicate by CVE. Two hundred and forty findings are probably a dozen or so distinct CVEs repeated across hosts. The remediation unit is a product update or patch rollout, not 240 tickets, and the report to the auditor should show both the finding count and the distinct-CVE count, because they answer different questions.
Rank:
- Tier 1 - CVEs known to be exploited in the wild or with public exploit code, on any host: remediate within 7 days.
- Tier 2 - remaining critical CVEs on high-value assets (finance, HR, anything holding personal data) or on laptops, which leave the network and face untrusted networks: within 14 days.
- Tier 3 - critical CVEs that cannot be patched because of application certification or vendor constraint: documented exception with an owner, a compensating control and a review date.
Make the SLA real: a defined 14-day clock only works if patch availability, reboot tolerance and business sign-off are agreed in advance. If an application owner blocks a cumulative update, the audit answer is a recorded exception, not a missed target - but that conversation has to happen before the report is written, not after. Re-scan after deployment to confirm remediation, since patch status and vulnerability status are separate records.
2. Diagnose the 40 failed patch deployments and describe the job settings and verification you would use on the second attempt.
Read the worked answer
Group the failures before changing anything; they are not one problem.
- 34 travelling laptops: the job had a single Wednesday 22:00 window. An endpoint that is offline at that moment simply misses the deployment. For a mobile estate, a fixed window is the wrong model: configure the job so it applies on next contact with a deadline, and force the reboot after a defined grace period with user notification. Keep the endpoint-facing dependency in mind - the client must reach EMS (TCP 8013) from home, since EMS participates in distributing patches.
- 6 pending reboot: the patch stage succeeded and the install stage did not complete. Check reboot policy, user deferrals and whether the machines are simply left logged in and never restarted.
- Other plausible causes to rule out on the remaining hosts: proxy configuration where an endpoint-side source is used, insufficient disk space, superseded patches, Windows build or edition outside support, or a conflicting GPO.
Second attempt: pick three failing endpoints, read the per-endpoint patch status and FortiClient logs, fix the root cause on those, and only then re-push in rings of about 25 rather than blasting all 40 again. Verification: do not trust the deployment status alone. Run a fresh vulnerability scan on the remediated group and show the critical finding count dropping; that is the evidence the auditor will ask for.
3. Design the reporting and logging answer for the auditor and the SIEM team, including what to do about the 78 percent disk usage.
Read the worked answer
Reporting. Create scheduled monthly reports from EMS covering vulnerability status by severity and host plus patch deployment compliance, and export them to a dated, read-only location. Snapshot at the start and end of each month so the 14-day cycle is provable rather than asserted, and attach the exception register with owners and review dates. Add the raw endpoint list behind every summary figure, because auditors sample hosts and expect the detail to reconcile.
Log forwarding. Forward EMS and endpoint events to the SIEM and confirm the 90-day retention is met at the SIEM side. Verify the forwarding option and event coverage in your build before promising it: you want registration, tag, vulnerability, patch and administrator actions, not just alerts, because "who changed the profile" is often the question. Test by performing a known action and confirming it arrives.
Disk pressure. Seventy-eight percent is a warning, not a crisis, and enabling more verbose logging will consume the remainder. Plan storage before changing log settings: rotate and purge aged telemetry, move retention responsibility to the SIEM (EMS holds a shorter window, the SIEM holds 90 days), and monitor the threshold so a full disk does not silently stop registrations and telemetry - which would break both the audit trail and tag-based access at the same time.