Collect Audit Logs
There’s a predictable early move in a lot of intrusions: once an attacker is on a machine, they clear its local logs. If the only record of what happened lives on the same computer that was compromised, you’ve effectively handed the person you’re investigating the ability to edit the evidence. Control 8.2 solves that by getting your logs off the individual machines and into a place an attacker can’t quietly reach.
If 8.1 was the decision about what to record, 8.2 is the act of actually turning logging on and collecting it. The two go together. A written logging policy that no system is following protects no one.
What this control actually says (in plain English)
Here’s the translation: make sure logging is switched on across your systems, and send those logs somewhere central rather than leaving them scattered on each device.
Now the official version. Control 8.2 says you should collect audit logs, ensuring that logging has been enabled across your enterprise assets in line with the process you defined in Establish and Maintain an Audit Log Management Process.
It sounds mechanical. The payoff is anything but.
Why business leaders should care
Two things make centralized collection worth the effort. The first is trust. Logs pulled into a separate, central location are far harder for an attacker to tamper with, because reaching them means breaching a second system, not just the one they already landed on. The second is speed. When an incident spans a laptop, a server, and your Microsoft 365 tenant, an investigator who can search all of it in one place answers questions in minutes instead of chasing evidence machine by machine while the clock runs.
There’s also a coverage problem that only shows up when you go looking. Plenty of organizations assume logging is on everywhere and discover, mid-incident, that the one system that mattered was never recording at all. Collecting logs centrally makes those gaps visible in advance, while they’re still cheap to fix.
What “good” looks like
You don’t need an enterprise security operations center to do this well. You need logging turned on where it counts and a central destination. Here’s the practical path.
- Enable logging on the assets that matter most. Endpoints, servers, network devices, and your cloud and identity platforms should all be recording. Your Microsoft 365 and Entra ID sign-in and audit logs are among the highest-value sources most organizations already have and often leave unused.
- Send it somewhere central. Forward logs to a central service, whether that’s a log management platform, a SIEM, or your security provider’s collection point. The goal is one place to look, separate from the systems being logged.
- Start with the highest-value sources. You don’t have to collect everything on day one. Begin with identity, administrative activity, and your security tooling, then expand.
- Confirm it’s actually flowing. A collector that silently stopped receiving logs is worse than none, because it looks like coverage. Check that data is arriving from every source you expect.
The audit and defensibility angle
Centralized, tamper-resistant logs are exactly what an investigator, an auditor, or an insurer wants to see after an incident. They let you scope what happened with confidence rather than assumption, which often means the difference between reporting “we confirmed the exposure was limited to these three accounts” and having to disclose a far broader worst-case because you simply couldn’t prove otherwise. Collection is what turns your logging policy into evidence you can actually rely on.
Logging that lives only on the device it describes is a promise you can’t keep, because the first thing an intruder does is break it. Getting those records into a central, protected place is a modest piece of engineering with an outsized payoff: when you finally need to know what happened, the answer is somewhere the attacker couldn’t reach. Turn it on, pull it together, and confirm it’s flowing.
