Enforcement is a recorded decision
The switch to enforcement is an approval task. It names the approver, the date and the client’s agreement, and later tasks stay locked until it is given, so audit mode can’t quietly become the permanent setting.
EDR Rollout Checklist Template
EDR rollouts rarely fail at install. They fail in the hour between removing the old antivirus and the new agent protecting the device, and in the months when policies stay in audit mode because nobody decided to switch them on.
Endpoint detection and response is now one of the first controls a cyber insurer, a customer questionnaire or an auditor asks about. Getting the agent onto devices is the straightforward part. The work that decides whether it protects the client is everything around the install: knowing which line-of-business applications need exclusions, running policies in audit mode long enough to learn what normal looks like, replacing the old antivirus without leaving a device unprotected, and then making a deliberate, recorded decision to move to enforcement. This free EDR rollout checklist gives MSP service managers and security engineers that sequence for one client. It covers planning, audit-mode policies, a pilot, deployment waves with the antivirus handover, an approved switch to enforcement and verification that ends with evidence the client can give its insurer. A conditional phase onboards the client to a 24/7 MDR or SOC service when one is included.
Installing the Agent Is the Easy Half
Most EDR platforms can run in a detect-only or audit mode, where they record what they would have blocked without blocking it. That is the right place to start. A line-of-business application that injects into another process, or an accounts package that runs macros, can look exactly like an attack, and finding that out on a pilot group is far cheaper than finding it on the finance team at month end.
The risk is that audit mode becomes permanent. Nobody owns the decision to enforce, so the client pays for prevention it isn’t getting, and its insurance application says EDR is deployed. Microsoft’s own guidance for attack surface reduction rules follows the same pattern: plan, test in audit mode, enable, then maintain, with only the standard protection rules typically safe to switch straight to block or warn. This checklist makes the move to enforcement a dated approval with a named approver, so it happens on purpose and on time.
Audit or detect mode
Watching, not stopping
Purpose: learn the estate and tune exclusions before anything is blocked.
Output: detections, false positives and a reviewed exclusion list.
Risk if it lasts: attacks are recorded rather than prevented.
Enforcement mode
Blocking, with tamper protection on
Trigger: an approved decision after the audit period has been reviewed.
Includes: prevention on, tamper protection on and isolation tested.
Outcome: protection the client can describe accurately on an insurance form.
What the EDR Rollout Checklist Covers
Seven phases take one client from planning to verified, evidenced enforcement. Phase 3 appears only when a 24/7 MDR or SOC service is part of the arrangement.
Phase 1
Phase 1: Plan the Rollout
- Check operating system support — every Windows, Windows Server, macOS and Linux version in the estate against the agent’s support list, including VDI
- Collect exclusion requirements — from line-of-business software vendors’ documentation, not guesswork, with the application owner named
- Agree who watches alerts — your service desk in hours, a 24/7 MDR or SOC service, or the client’s own team, and what happens out of hours
- Record the current antivirus or EDR — product, version, how it is removed and who holds any uninstall password
- Agree the plan with the client — waves, dates, user communication and who approves the move to enforcement
Phase 2
Phase 2: Build Policies in Audit Mode
- Create the client’s policy group — from your standard baseline, with separate groups for workstations and servers
- Set prevention to audit or detect-only — so the pilot shows what would be blocked without blocking it
- Add documented exclusions only — each scoped as narrowly as the vendor allows, with its source recorded, and no blanket folder exclusion for remote management tools
- Configure attack surface reduction rules if the client uses Microsoft Defender — standard protection rules to block, the rest to audit
- Route alerts to the PSA — detections create tickets with the client, device and severity, in the security queue
Phase 3 — If MDR Included
Phase 3: MDR / SOC Onboarding
Shown only when a 24/7 MDR or SOC service is included. Complete it before the pilot, so the service is watching from the first device.
- Register the client with the MDR service — tenant or site, device groups and the contract reference
- Agree escalation contacts — client and MSP names, phone numbers and the order to call them, in and out of hours
- Agree isolation authority — which devices the service may isolate without asking, and which servers need a call first
- Share environment context — critical servers, privileged users and the remote management tools that are expected on the estate
- Test the escalation path — a test alert reaches the right person at the client and at the MSP
Phase 4
Phase 4: Pilot
- Deploy to the pilot group — IT’s own devices, one device per role and the users of each critical application
- Confirm every pilot sensor reports healthy — correct policy group, latest version and no conflicts with the existing antivirus
- Review audit-mode detections daily — mark each one genuine or false positive, and record any exclusion added as a result
- Check performance and applications with users — log-on time, application launches and anything that now behaves differently
Phase 5
Phase 5: Deploy & Replace the Old Antivirus
- Deploy in waves — workstations by site or department, servers last and in their own maintenance window
- Replace the old antivirus one device at a time — the EDR agent reports healthy before the old product is removed
- Check which product is active on servers — Windows Server does not switch Microsoft Defender Antivirus on or off automatically
- Remove the leftovers — old agents, services and console entries, with uninstall passwords retired and the old subscription cancelled
- Record coverage after each wave — devices reporting against the RMM inventory, as a count and a percentage
Phase 6
Phase 6: Move to Enforcement
Nothing moves to enforcement until the switch is approved. Approval halts the tasks that follow.
- Review the audit period — detections, false positives, exclusions added and anything still unresolved
- Approve the switch to enforcement — the service manager approves, with the client contact’s agreement attached
- Turn on prevention group by group — pilot first, workstations next and servers last
- Turn on tamper protection — with any bypass or uninstall codes stored in the password vault, not in tickets
- Test isolation on a pilot device — isolate it, confirm how you can still reach it and release it
Phase 7
Phase 7: Verify & Evidence
- Reconcile EDR coverage against the inventory — every device in the RMM and the directory has a healthy sensor or a recorded exception
- Run a safe test detection — the EICAR test file or the vendor’s documented test, on one device per group
- Time the alert-to-ticket flow — from detection to a ticket in the PSA and, where included, a call from the MDR service
- Save the evidence pack — coverage export, policy mode, tamper protection status and the monitoring arrangement, dated
- Update documentation and the agreement — policy groups, exclusions with their owners and the device count billed
Replacing the Old Antivirus Without a Gap
The moment of greatest risk in an EDR rollout is the handover from the old product. Install first, confirm the new agent reports, then remove the old one. How Windows behaves in between depends on whether the device is a client or a server, and Microsoft documents the difference.
| Device | What happens by default | What to check |
|---|---|---|
| Windows 10 and 11 | Microsoft Defender Antivirus disables itself when another antivirus is installed, and can re-enable automatically when that product is removed or stops protecting | Windows Security shows the expected product as the active antivirus after each step |
| Windows Server | Defender does not change mode automatically. It must be set to passive or disabled by hand, and re-enabled by hand if the other product is removed | Run Get-MpComputerStatus and read AMRunningMode on every server before and after the swap |
| macOS | No built-in fallback takes over when an agent is removed | The new agent’s privacy permissions, such as full disk access, are approved through MDM before the old agent comes off |
| Linux servers | No built-in fallback | Agent health in the console and the application owner’s sign-off after install |
Two problems catch MSPs out most often. The first is an uninstall password for the old product that only the outgoing provider holds, which is why Phase 1 records it before anything else happens. The second is a server where two products end up scanning at once. Microsoft advises putting Defender into passive mode, or disabling it, on servers where another antivirus is primary, to prevent the problems that multiple products cause.
The evidence a cyber insurer is likely to ask for
Applications and renewal questionnaires commonly ask whether EDR is on every endpoint and server and whether alerts are monitored around the clock. Phase 7 produces the answer and the proof, dated, so nobody has to reconstruct it at renewal:
- A coverage export: devices with a healthy sensor against the inventory, with exceptions listed.
- Policy mode by group, showing prevention on rather than audit only.
- Tamper protection status.
- The MDR or SOC contract, or a written description of who monitors alerts and when.
- The test detection record, showing the alert reached a person.
Why Run EDR Rollouts in CheckFlow?
Every client’s rollout in one view
When several clients are mid-rollout, the grid view shows who is still in audit mode, whose servers are waiting for a window and which enforcement approvals are overdue.
Evidence ready at renewal
The coverage export, policy screenshots and test detection record are uploaded to the tasks that produced them. When the insurer or the client’s auditor asks, the dated evidence is already filed.
EDR coverage can only be as good as the inventory you measure it against. The RMM Agent Deployment Checklist produces that reconciled inventory, and most MSPs run the two rollouts in the same waves. For a brand-new client, both sit inside the wider MSP Client Onboarding Checklist.
EDR is near the top of every cyber insurance questionnaire. The Cyber Insurance Readiness Checklist uses the evidence from Phase 7 alongside MFA, backup and patching evidence before the client signs. See how CheckFlow for MSPs runs security rollouts and reviews across every client.
Frequently Asked Questions
What is the difference between antivirus and EDR?
Traditional antivirus looks for known malicious files and blocks them. EDR records activity on the device, such as processes, network connections and changes, detects suspicious behaviour even when no known file is involved, and lets an analyst investigate and respond, for example by isolating the device. Many products now combine both, which is why the antivirus handover needs care: the new agent may be replacing both roles at once.
How long should EDR run in audit mode?
Long enough to see a normal working cycle for the pilot users, including month-end or other periodic jobs that only run occasionally. For many small and mid-sized clients that is one to four weeks. Set the review date when you start, not when you remember. The point of audit mode is to tune exclusions, and once detections are reviewed and stable, staying in it only delays protection.
How do you replace antivirus with EDR without leaving devices unprotected?
Install the EDR agent first and confirm it reports healthy, then remove the old product, one device at a time. On Windows 10 and 11, Microsoft Defender Antivirus steps aside and can re-enable automatically, but on Windows Server it does not change mode by itself, so check every server by hand. Track coverage after each wave, so a failed install is found that day rather than at the next audit.
How do you test EDR safely?
Use a test designed for the purpose. The EICAR test file is a harmless 68-character file that anti-malware products deliberately detect, and most EDR vendors document their own safe test detections. Run the test on one device per policy group and time how long it takes for the alert to reach a ticket and, where an MDR service is included, a person. Never use real malware to test.
Who should be allowed to isolate a device?
Agree it in writing before enforcement. A common arrangement lets the MDR or SOC service, or your on-call engineer, isolate workstations immediately when an attack is suspected, because minutes matter, while isolating a server needs a call to the client first because it can stop the business. Record the agreed contacts and the exceptions in Phase 3, and test isolation on a pilot device before you rely on it.
Should servers be in the first deployment wave?
Usually not. Start with IT’s own devices and a representative pilot, then workstations, and bring servers in last, in their own maintenance window, with the application owner available. Servers are where exclusions matter most and where an over-zealous block costs the most. They are also where the antivirus handover needs checking by hand, because Windows Server does not switch Defender on or off automatically.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.