The Story Every IT Manager Should Read Twice
The UK Ministry of Justice recently issued a public apology after court staff were found to have accessed files relating to victims of the Southport case. Sensitive personal data was involved. The detail that matters most to those of us who run IT: officials stated there was no evidence the data was shared with third parties. In other words, this was not a breach by an external attacker. It was internal staff opening files they had no business opening — and an organization that had to investigate, respond, and apologize publicly for something that happened inside its own walls.
If you manage infrastructure for an organization that handles sensitive data — legal, healthcare, finance, local government — or you're an MSP whose clients do, ask yourself the uncomfortable question this incident raises: if HR, legal counsel, or a regulator walked in tomorrow and asked, 'Who accessed this folder, from which machine, when, and what else did that account touch that week?' — how long would it take you to answer with evidence? Hours? Days? Or would you discover the logs rolled over 30 days ago and the evidence simply no longer exists?
This is not just a security story. It's an operations story. The same visibility gaps that make insider-access investigations painful are the same gaps that make your Tuesday ticket queue slow: shared admin accounts nobody can attribute, remote sessions through unlogged tools, scripts run from technician laptops with no record of what they changed. Whether the trigger is a regulator's question or a 2 a.m. outage, the root problem is identical — you cannot reconstruct who did what, on which machine, and when.
The Problem: Five Tools, Five Timelines, Zero Attribution
Walk through what endpoint management actually looks like in most mid-size IT shops and MSPs today:
- Monitoring lives in one place — PRTG, Zabbix, Nagios, or a cloud tool. It knows a disk filled up. It has no idea who was on that server earlier that day.
- RMM or remote access lives somewhere else — ConnectWise, N-able, NinjaOne if you're lucky, or just RDP, TeamViewer, and AnyDesk if you're not. Most of those remote sessions leave no centralized, attributable record.
- Ticketing sits in a third system — Jira Service Management, Freshservice, a legacy PSA. The ticket says 'Resolved — see notes.' The notes say 'fixed the permissions issue.' That is the entire audit trail.
- Scripting happens from technician workstations against production, with results going nowhere. A tech changes an ACL on a share in March; in June, nobody remembers why the ACL is the way it is.
Now run the scenario. An employee files a complaint: a colleague who left the company three weeks ago accessed a payroll folder they shouldn't have. What do you actually do?
If you're like most teams: you try to confirm file access auditing was even enabled on the folder (it was enabled on the server, maybe, but object access events were never scoped to the share). You pull Security event logs from the file server, then from the user's workstation, then from the VPN concentrator. Busy file servers rotate logs every 14–30 days, so half your evidence may already be gone. You export, grep, and cross-reference across four systems. Realistic time to an answer: two to four days, with a genuine risk the final answer is 'inconclusive.'
The MSP version is worse. A client asks why a firewall rule changed on their production network. You have 12 tabs open across 5 tools. The tech who made the change left your company four months ago. The change is reproducible from memory by exactly no one. What you tell the client is some version of 'we're looking into it,' and what it costs you is trust.
Why these gaps exist
- Siloed architecture. RMM platforms were bolted onto PSAs via half-documented integrations. Monitoring was bought separately. Remote access came from a consumer-grade license nobody sanctioned. Each tool keeps its own timeline; none of them is authoritative.
- Shared credentials. The 'techadmin' domain account is used by six people. Every action in the logs is attributed to 'techadmin.' Attribution after the fact is mathematically impossible.
- Logging treated as somebody else's problem. In organizations without a dedicated SOC, nobody owns endpoint activity logging. IT assumes security owns it; security assumes IT owns it. Result: nobody does.
- Action data and monitoring data never meet. A script that silently failed on 30 machines and the alert it should have prevented live in two different systems that never talk. So both automated remediations and manual technician actions vanish from the historical record.
The business impact compounds: longer incidents because the first responder has no context, inflated ticket volumes because nothing traces back to a root cause, SLA reports you can't defend because helpdesk and infrastructure data live apart, and burnout — because your best techs spend their afternoons doing log archaeology instead of engineering.
How AlertMonitor Closes the Gap
AlertMonitor was built around a simple refusal: your monitoring, RMM, helpdesk, and patching should not be four products pretending to be a platform. They should be one platform. That single architectural decision is what makes endpoint accountability practical instead of aspirational.
Every action lands in one device timeline. When a technician opens a remote session, runs a script across a device group, pushes software, or approves a patch — that action is written to the same timeline as the alerts, metrics, and tickets for that device. Click any machine in AlertMonitor and you see its complete operational history: what alerted, who connected, what ran, what changed, what got fixed. That MoJ-style question — who touched this machine, and when — becomes a filtered search, not a forensic project.
Per-technician attribution, without a side project. Because RMM sessions and script runs are native to the platform and tied to named technician logins, every action is attributable by default. Shared admin accounts stop being necessary because the workflow itself produces accountability as a byproduct of doing the work.
Script results feed back into monitoring. This is the detail that changes daily operations, not just investigations. When you run a PowerShell script across your 12 file servers from AlertMonitor, the per-device results return into the console and the timeline. An automated remediation and a manual fix look identical in the record — visible, timestamped, attributable. Your troubleshooting stops depending on tribal memory.
The ticket tells the truth. A tech opens a ticket, launches the remote session from it, runs the fix, and the session record plus script output attach to that ticket automatically. When the client — or an auditor, or legal — asks 'what exactly was done about this?', the answer is a link, not a reconstruction.
The concrete difference: the access-attribution question that used to take two to four days of manual log archaeology takes minutes in AlertMonitor — filter the device timeline by date range, technician, and action type, export, done. The MSP firewall-rule question is answered by opening the device history, not by calling a former employee.
Practical Steps You Can Take This Week
You don't need to wait for an incident to start closing this gap. Here's where to begin — and how to do each step inside AlertMonitor's RMM so the results become part of your permanent record.
1. Find out who has local admin rights right now. Shared and orphaned admin access is the single biggest attribution killer. Sweep it:
Invoke-Command -ComputerName FS01,FS02,APP01,DC01 -ScriptBlock {
Get-LocalGroupMember -Group 'Administrators' |
Select-Object @{n='Server';e={$env:COMPUTERNAME}},
Name, PrincipalSource
} | Format-Table -AutoSize
In AlertMonitor: select your 'Servers' device group → Run Script → paste this in. Results come back per-device into the console and timeline, giving you a dated snapshot of admin membership you can diff against next month's run.
2. Document exactly who can read your sensitive shares — before anyone asks.
(Get-Acl -Path 'D:\Finance\Restricted').Access |
Select-Object IdentityReference, FileSystemRights,
AccessControlType, IsInherited |
Sort-Object IdentityReference |
Format-Table -AutoSize
Run this across every file server holding personal or client data. Anything with IsInherited: False on a sensitive folder deserves a second look — someone explicitly changed that ACL at some point, and you want to know who and why now, not during an investigation.
3. Check who is currently logged into your servers. Unattended RDP sessions are how 'nobody' quietly becomes 'somebody did something':
Get-CimInstance Win32_LoggedOnUser |
Select-Object -ExpandProperty Antecedent |
Select-Object -Unique Domain, Name
And on your Linux jump hosts:
# Currently logged-in users
w
# Last 20 sessions
last -n 20
4. Verify your servers are actually patched. Unpatched machines and untracked admin access are the same disease — configuration nobody can vouch for:
Get-HotFix -ErrorAction SilentlyContinue |
Sort-Object InstalledOn -Descending |
Select-Object -First 5 HotFixID, Description, InstalledOn
AlertMonitor's patch management tracks this across the whole estate automatically, but a spot-check against reality is always worth two minutes.
5. Kill shared accounts, then make the sweep routine. Every name that appears in step 1 should map to a specific human. Then schedule the admin-membership and sensitive-share scripts to run weekly through AlertMonitor's RMM. Results persist in the device timeline, so you build a running, exportable history — which means the next 'who did what' question, whether it comes from a client, HR, or a ministry-level press office, gets answered with a report instead of an apology.
That last point is the real lesson of the MoJ incident. The difference between 'we investigated and here is the evidence' and 'we are unable to say for certain' is not budget or headcount. It's whether your operational tooling records what happens on your endpoints as a natural part of operating them. Make that your default, and accountability stops being a project and becomes a property of your platform.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.