EDR Compliance: What Auditors Actually Look For
EDR compliance means proving to an auditor that your endpoint detection and response tool covers every in-scope device, works as intended, has its alerts reviewed by a person, and keeps records for as long as your framework requires. It is evidence, not a certificate. No vendor can issue one, and no regulator awards one.
For New Zealand and Australian businesses, this evidence is being requested more often. Clients ask for security attestations during procurement, insurers add endpoint questions to renewals, and privacy regulators expect proof of reasonable safeguards after a breach. Knowing what auditors ask to see turns a last-minute scramble into a routine check.
What Is EDR Compliance?
EDR compliance is the ability to show an auditor that your EDR deployment meets the security obligations you are assessed against. The tool is EDR. The compliance is the proof.
EDR stands for endpoint detection and response. In cybersecurity, the EDR meaning is simple: software that continuously records activity on laptops, desktops, and servers, flags suspicious behaviour, and lets analysts investigate and contain threats. Businesses without in-house analysts usually run it as managed endpoint detection and response, where a security team monitors the alerts.
Owning EDR does not make a business compliant. Auditors want to see the tool’s output and the people and processes around it.
Is EDR Required for Compliance?
Rarely by name. Most laws and standards ask for outcomes such as reasonable safeguards, malware protection, logging, and monitoring. EDR is a common way to deliver those outcomes, but only one framework below names it directly.
| Framework | What it says | EDR angle |
| NZ Privacy Act 2020 | Information Privacy Principle 5 requires reasonable security safeguards. The Privacy Commissioner expects notifiable breaches to be reported within 72 hours, which is guidance rather than a fixed statutory deadline. | EDR records help show safeguards were in place and help scope a breach. |
| AU Privacy Act 1988 (APP 11) | Requires reasonable steps to protect personal information from misuse, interference, loss and unauthorised access. | No tool is named. EDR is one way to evidence the steps. |
| ASD Information Security Manual (ISM) | ISM-1341 calls for a HIPS or EDR solution on workstations. ISM-1988 requires event logs to be searchable for at least 12 months. | The only explicit EDR reference among these frameworks. Voluntary for most private businesses. |
| ISO 27001:2022 | Annex A 8.7 (malware protection), 8.15 (logging) and 8.16 (monitoring activities). | EDR is a common way to evidence all three controls. |
| PCI DSS v4.0.1 | Requirement 10.5.1 asks for 12 months of audit log history, with the latest three months immediately available. | Applies only to card data environments. |
| HIPAA | 164.312(b) requires audit controls. 164.316(b)(2)(i) requires documentation to be kept for six years. | The six-year requirement applies to documentation, not log retention. |
The NZ Privacy Act 2020 and the Australian Privacy Act 1988 both stay silent on specific tools. They test whether your safeguards were reasonable for the personal information you hold. If a breach happens, EDR telemetry is often the fastest way to show what was affected and when.
The Essential Eight maturity model has no EDR strategy of its own, so a strong score does not prove EDR coverage. Mapping where EDR sits next to Essential Eight endpoint protection closes that gap.
What Does EDR Actually Do for an Audit?
EDR produces three kinds of audit evidence: telemetry, alerts, and response actions. Telemetry records what happened on each device. Alerts show what the tool flagged. Response actions show what was done about it, such as isolating a device or killing a process.
Speed is why auditors care. IBM’s 2026 Cost of a Data Breach Report puts the mean time to identify and contain a breach at 247 days: 183 to identify and 64 to contain. That is up from 241 days the year before. Detection and response evidence shows an auditor you are working to shorten that window.
EDR security tooling has limits, and knowing them prevents over-claiming. EDR cannot prove that a policy was approved, staff were trained, patches were applied, backups restore properly, or that every device is enrolled. Those need separate evidence.
What Auditors Look For in EDR Evidence
Auditors testing EDR compliance ask five questions. Each needs a document, export or screenshot you can produce on request.
Coverage on Every In-Scope Device
Auditors start with scope. Reconcile the agent list against your asset inventory, then show agent health status. Keep a documented exceptions list with a reason, an owner, and a review date for every device that runs without an agent. A laptop missing from the console is the most common finding.
Detection and Response Records
Show timestamped alerts with severity, the action taken, and how you handled false positives. An alert with no recorded outcome looks to an auditor like an alert nobody read.
Proof That a Person Reviewed the Alerts
A tool that generates alerts is not the same as a process that acts on them. Show who reviewed which alert and when. ISM-0109 expects event logs from workstations to be analysed in a timely manner, and most frameworks imply the same. Small teams often meet this through 24/7 managed detection and response, where analyst actions are logged automatically. Pair those records with your security incident response plan so the auditor can follow an alert through to closure.
Log Retention and Console Access
EDR log retention is where evidence most often falls short. Compare the platform’s retention setting with the longest applicable period. ISM-1988 requires 12 months of searchable logs, and PCI DSS 10.5.1 requires 12 months with three months immediately available. Retention is configurable, and the default may not meet either. Also show that console administrators use multi-factor authentication, and keep the console’s own audit log.
Reports Mapped to Your Framework
A raw alert export rarely satisfies an auditor. An EDR compliance report that maps evidence to specific controls does. Monthly reports work well, and dedicated compliance reporting can align that output to the framework you are assessed against.
EDR Rules, Policies and Exceptions Auditors Review
EDR rules are the configured settings that decide what the tool detects, blocks, and ignores. Auditors review three types: detection rules, response rules, and exclusion rules.
Exclusions get the most scrutiny, because each one is a blind spot. Expect questions about who approves rule changes, whether every exclusion has a documented reason and a review date, and whether a change log exists.
A written EDR policy ties this together. It should state which devices are covered, who reviews alerts, how quickly, and how long records are kept. ISM-0580 expects you to develop, implement, and maintain a security monitoring policy. Earlier versions of the ISM called it an event logging policy.
How to Choose an EDR That Produces Audit Evidence
Choose EDR by the evidence it can produce, not the feature list. Five questions separate tools that pass audits from tools that only detect threats:
- How long does the platform retain data, and can you export it?
- Can it report coverage and agent health against your asset list?
- Does it keep an audit log of administrator actions?
- Can it produce reports mapped to your framework?
- Who reviews the alerts, and is that recorded?
If you lack in-house analysts, a managed EDR solution answers the fifth question by design. The best EDR solutions compared covers how the main options handle detection and response.
How to Keep EDR Audit-Ready All Year
Audit-ready EDR is a routine, not a project. Three habits cover it:
- Quarterly: reconcile agents against the asset inventory and clear or renew exceptions.
- Monthly: review the EDR compliance report and file it with the alert-review records.
- Annually: check retention settings against current framework requirements and update the EDR policy.
This is continuous compliance in practice: small, regular checks that leave a paper trail. Our compliance readiness checklist covers the wider evidence auditors ask for beyond endpoints.
EDR Compliance in Summary: What to Have Ready Before the Auditor Asks
EDR compliance comes down to four proofs: coverage of every in-scope device, records of detection and response, evidence that a person reviewed the alerts, and retention that matches your framework. Few regulations name EDR, so auditors judge the evidence, not the tool brand. Get those four right and most audit questions become a matter of exporting a report.
The evidence works best alongside a tested incident response plan and the basics in a small business cyber security checklist. Together they show an auditor that detection, response and everyday hygiene are all covered.
Want a second opinion on your EDR audit evidence? CyberMark’s New Zealand-based team can walk you through the gaps and fix them without the enterprise overhead. Book your security assessment and get a clear plan before your next audit or insurance renewal.
Frequently Asked Questions
Is EDR the same as SIEM?
No. EDR collects data from endpoints and can respond directly on them, for example by isolating a device. A SIEM gathers logs from many sources, such as network, cloud and identity systems, and correlates them centrally. Many audits expect both kinds of evidence.
Is antivirus considered EDR?
No. Antivirus mainly blocks known malware. EDR continuously records endpoint behaviour, so analysts can investigate and respond to threats that antivirus misses. Frameworks such as ISM-1341 accept EDR, but traditional antivirus alone does not offer the same investigation records.
Are MDR and EDR the same?
No. EDR is the technology installed on devices. MDR is a service in which a security team monitors and responds to EDR alerts. MDR also supplies the “person reviewed it” evidence many auditors want.
How often should EDR alerts and reports be reviewed?
Review alerts continuously or daily, and reports monthly. PCI DSS 10.4.1 requires daily review of security events and logs from critical systems, using automated mechanisms. Other frameworks say “timely,” so document your own review schedule and stick to it.
Can a small business without an IT team meet auditor expectations for EDR?
Yes. Auditors test whether coverage, review and retention are evidenced, not how large your team is. A managed EDR service supplies alert review, response records and monthly reports without in-house analysts.
Need help reducing your business security risk?
Contact us
