Redacted Contracts, Unpatched Servers: What the DWP Outsourcing Dispute Teaches IT Teams About Verification

This week The Register reported that Sopra Steria widened its legal challenge to Capita's Whitehall outsourcing deal with the Department for Work and Pensions (DWP). An unredacted contract has prompted fresh claims of preferential treatment — and, more to the point for those of us running infrastructure, fresh concern about risk that nobody could quantify while the details stayed hidden.

Most of us will never touch a seven-figure Whitehall agreement. But strip away the politics and this story is about something every sysadmin, IT manager, and MSP tech knows cold: you cannot manage risk you cannot verify. And nowhere in day-to-day operations is that more true than patch management.

Ask five IT teams "are we patched?" and you'll get five answers, each technically true, each pulled from a different tool, none of them complete. The WSUS console says 96%. The RMM says 89%. One server has been pending a reboot for eleven days. Two machines failed KB5041585 silently. And the helpdesk has an open ticket for a server that mysteriously restarted at 2:07am — because nobody connected the dots between the update deployment and the "unexplained" outage.

That is the unredacted contract problem, playing out in miniature on your network, every Patch Tuesday.

The Problem in Depth: Your Patch Report Is More Redacted Than You Think

Fragmented tooling produces conflicting truths. A typical mid-size shop runs WSUS or SCCM for servers, Intune for a slice of the endpoint estate, a standalone RMM like NinjaOne or ConnectWise Automate, and a helpdesk — ServiceNow, Freshdesk, Halo — that has no idea what the patching tools are doing. Each tool has its own definition of "patched." WSUS reports a needed count of zero for a machine whose update installed but never rebooted. The RMM shows it compliant. In reality, that device is running half a cumulative update and is one forced reboot away from an outage nobody scheduled.

Reports count installations, not outcomes. The classic monthly compliance report says 97% because 97% of devices received the update. It says nothing about the 3% where the install failed and will retry-loop forever, the dozen machines sitting in "pending reboot" for weeks, or the terminal server that blue-screened during the deployment window and got skipped quietly. Your report is a redacted contract: technically a document, structurally missing the parts that carry the risk.

The 2am outage that becomes an 8am incident. A Patch Tuesday window opens at 2am. The update installs, the server reboots, and a third-party application service with a lazy startup dependency fails to come back. Monitoring that only watches CPU, RAM, and ping never notices a stopped service, so nothing fires. At 8:38am the first "alert" is a furious message in the IT channel: the ledger system is down. A helpdesk ticket gets created with the cause listed as "unknown." The server owner spends the morning on forensic archaeology — Event Viewer, update history, application logs — before discovering the cause was the deployment he scheduled himself. MTTR: three hours, most of it reconstructing context that should have arrived with the alert.

Failed patches become ghost tickets and burned-out techs. Everyone who has patched at scale knows the loop: a machine reports a missing KB, you push it, it reports installed, the next scan says missing again. When patch tooling, monitoring, and ticketing don't share state, that loop plays out as three separate human interactions — an RMM push, some monitor noise, a helpdesk ticket — instead of one automated retry with an escalation path. Multiply by a few hundred endpoints across a dozen clients and Patch Tuesday becomes a three-day fire drill. Technicians stop trusting the reports and start spot-checking via RDP, which burns hours and fixes nothing systemic.

The accountability gap mirrors the outsourcing gap. The DWP's problem, per the reporting, is that the risk profile of the deal only became visible when the contract was unredacted. MSPs live this in reverse: when a client's environment breaks after "the IT company patched stuff," the first question in the post-mortem is what exactly was deployed, when, to what, and what failed? If the answer lives in a WSUS export, an RMM activity log, and someone's memory, you don't have an audit trail — you have folklore. For MSPs serving clients with Cyber Essentials, HIPAA, or public-sector obligations, "trust me, it's patched" is not an answer that survives an audit.

How AlertMonitor Closes the Gap

AlertMonitor runs on a simple premise: patch state, monitoring state, and support state are one story, so they should live in one system with a single definition of truth.

Real-time patch status per device — missing, failed, or pending reboot. Not a nightly roll-up that's stale before you read it. Open the patch module and you see, right now, which Windows machines are missing updates, which installs failed and why, and which devices are one reboot away from actually being patched. That third status is the one most tools bury, and it causes most of the surprises. In AlertMonitor it's a first-class state you can filter, report on, and act on.

Staged, scheduled deployments with rollback. Patching at scale is a rollout, not an event. In AlertMonitor you build device groups — "Pilot Ring," "Finance Servers," "Branch Offices - Site 3" — and stage deployments through them with maintenance windows. Pilot on a handful of non-critical machines, run production rings over the weekend, and if something misbehaves, roll back without hand-crafting uninstall commands at 7am. Deployment history — which KB, which policy, which devices, what result — is retained automatically, so the audit question "what exactly was deployed?" takes one click instead of one afternoon.

The 2am reboot fires an alert with context, not a mystery. Because patching and monitoring share a brain, a reboot triggered by a patch deployment is recognized as exactly that. Device comes back healthy? Logged as a completed patch cycle. Reboot runs long or a service fails to start afterward? An alert fires carrying the full context: patch policy name, KB number, install result, reboot timestamp. The on-call tech wakes up to "KB5041585 deployed via policy Servers-Monthly, reboot completed 02:07, service LedgerApp failed to start" — not "host down, cause unknown." That's the difference between a two-minute fix and a three-hour incident.

Helpdesk in the same loop. A patch-related alert can open or update a ticket with the patch context attached. No more tickets reading "server restarted overnight???" with no history. The ticket, the alert, and the patch event reference each other — which also means IT managers finally get SLA reports where incident timelines include the patch events that caused them.

For MSPs: cross-client compliance from one screen. Instead of logging into twelve client environments or reconciling twelve spreadsheets, the NOC dashboard shows patch compliance per client and per device group. Sort by worst client, drill into the failed devices, re-push or escalate. The Monday reconciliation meeting becomes a ten-minute review of an automated report.

The old workflow — WSUS console, RMM activity log, Excel tracker, helpdesk archaeology — collapses into one console where the patch state is the same state monitoring and the helpdesk see.

Practical Steps: Get to the Truth This Week

Before you fix the process, find out what's actually true today. Then make it permanent in a platform.

1. Find every machine sitting on a pending reboot — the status most reports hide and most outages come from:

# Check for pending reboot states on the local machine
$wuReboot = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
$renamePending = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" `
    -Name PendingFileRenameOperations -ErrorAction SilentlyContinue) -ne $null

[PSCustomObject]@{
    Computer          = $env:COMPUTERNAME
    WURebootPending   = $wuReboot
    FileRenamePending = $renamePending
    LastBootTime      = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
}

Run this remotely against your server list. Any machine showing True is running with a partially applied update and will reboot on its own schedule, not yours.

2. Pull the failed installs from update history. Compliance reports count successes; failures are where the risk lives:

# List failed Windows Update installs from local update history
$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$count    = $searcher.GetTotalHistoryCount()

$searcher.QueryHistory(0, $count) |
    Where-Object { $_.ResultCode -eq 4 } |   # 4 = Failed
    Select-Object Date, Title, ResultCode |
    Sort-Object Date -Descending |
    Format-Table -AutoSize

If the same KB appears repeatedly, you have a retry loop — that machine will never be compliant until someone intervenes.

3. Check when each server last actually installed an update. A server with nothing installed in 90 days is a finding, whether or not the console claims it's current:

# Report the most recent installed update per server
$servers = "FS01","SQL01","DC01","RDS01","APP01"

foreach ($srv in $servers) {
    $last = Get-HotFix -ComputerName $srv |
        Where-Object { $_.InstalledOn } |
        Sort-Object InstalledOn -Descending |
        Select-Object -First 1
    [PSCustomObject]@{
        Server      = $srv
        LastKB      = $last.HotFixID
        InstalledOn = $last.InstalledOn
    }
}

4. For the Linux boxes in the same estate, a quick sanity check on what recently landed:

# Recently installed packages on Ubuntu/Debian
grep " install " /var/log/dpkg.log | tail -20

5. Then make it operational in AlertMonitor. Scripts are triage; a platform is an operating model:

• Build device groups as rollout rings — pilot, standard, critical servers.
• Define maintenance windows per ring so reboots happen while someone is on call, not as users arrive Monday morning.
• Schedule the deployment, let the pilot ring run for 48 hours, and clear the failure list before the production rings fire.
• Configure the unexpected-reboot alert so any reboot not associated with a patch policy gets flagged — that's how surprise restarts stop surfacing as user tickets.
• Wire patch-context alerts into the helpdesk so every patch-caused incident carries its own explanation.

The difference shows up in the numbers: Patch Tuesday triage drops from days to a couple of hours, "unknown cause" incidents disappear because the cause rides along with the alert, and when a client or auditor asks for proof of patch status, you produce a live report instead of a redacted guess.

The DWP dispute is a public-sector story about contracts. The lesson is universal and operational: risk you can't verify isn't managed — it's just waiting. Your patch estate deserves better than a report with the important parts blacked out.

Related Resources

AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources