EDR requirements checklist

Alerting, containment and evidence collection are three different jobs, and an EDR requirements checklist should specify each one separately. An alert tells an analyst that something needs attention. Containment changes the state of a host, such as blocking a process or isolating a machine. Evidence collection captures what happened in a form that can later be examined, explained to an insurer or handed to law enforcement. A platform can do well at the first and poorly at the other two, so the checklist should ask for each capability by name rather than accepting a general claim about response.

On the containment side, Wazuh active response is the feature to examine. Before any test, the reader must decide which actions may run without human approval (for example, a scripted block of a known-bad hash on a lab host), which actions require an analyst to approve them, who holds that approval authority at each hour of the day, and how each automatic action is logged and reversed. Response actions and their safeguards must be confirmed per platform and per operating system in the reader's own tests, against their own endpoint builds. Do not assume that an action documented for one OS works on another.

On the evidence side, Velociraptor supports targeted artifact collection and hunting across the estate, so the checklist should require the team to test a collection on a sample host and a hunt across a defined group. For hosts that cannot take a client, offline collectors are the next question. Local triage is different: the velociraptor gui command starts a GUI, frontend and local client on one machine, which suits examining a single host when the central server is unavailable. Record who ran each collection, when, with which artifact version, and where the output was stored, because chain of custody depends on those details. Confirm the retention location, access controls and hashing approach with counsel and your incident response plan before relying on the output.

An EDR platform can produce records that support compliance assessments, but the records do not make an organization compliant or certified. The useful question is which evidence each framework asks for and whether your endpoint records can show it. Under the HIPAA Security Rule at 45 CFR 164.312, audit controls must record and examine activity in systems that hold ePHI, so you need agent-level logs of authentication, process and configuration events, and the retention and review process that proves someone looked at them. The same section requires unique user identification and person or entity authentication, which an EDR console can corroborate by linking alerts to named accounts. Confirm that your Wazuh alert archive and agent logs cover the ePHI systems in scope and that retention matches your policy.

The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to monitor and log the activity of authorized users, and to implement multi-factor authentication for anyone accessing information systems. For endpoints, this means showing that logon and privilege events are collected from workstations and servers, that administrator actions are logged, and that someone reviews them. The Wazuh dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. These views organize alerts and agent data by control area, which can speed up evidence gathering, but a dashboard view is not an audit finding. Map each dashboard view to the specific control statements in your scope document before you rely on it.

DeployOpen prepares the systems, control configurations and evidence packages for assessments. It does not issue audit reports, attestations or certifications, and independent auditors decide whether your evidence is sufficient. Before you design collection, ask your assessor which evidence formats they accept, such as exported alert logs, screenshots of dashboard views, configuration baselines, signed review records or sampled investigation tickets, and how far back they expect records to go. Ask them whether they accept self-hosted, time-stamped log archives and how they want integrity protected. Those answers determine retention, export and access control requirements for the platform, and they should be recorded in the written scope before deployment begins.

The most useful questions on an EDR shortlist are the ones where platforms and partners give different answers. Ask each candidate the same set, and require the answers in writing. Start with where telemetry is stored: which component holds the alerts and raw events, which region or data center hosts them, who holds administrative access to the store, and how long each data class is kept. For a self-hosted Wazuh design, the answer should name the Wazuh indexer and the Wazuh server, and say which of them run inside your network. Then ask how agents are upgraded. Wazuh's server can manage agent configuration and upgrades remotely, so ask who approves each upgrade wave, how a failed upgrade is rolled back, and how many agent versions the platform supports at once.

Next, ask what happens when a host is offline. A laptop that is off for two weeks still needs its queued events delivered, and a host that cannot take an agent still needs an investigation path. Ask how the candidate buffers telemetry, what it loses on disconnect, and whether it offers an offline collection method, such as Velociraptor offline collectors that write results to JSONL or CSV. Ask who approves response actions and how the approval is recorded: which roles can isolate a host, kill a process or disable an account, whether a second person must confirm, and what the platform logs when an automated response fires. Then ask how detections are tested and tuned. Look for a documented test cycle, a way to replay known attack behavior against rules, and a named owner for false-positive review. Finally, ask what evidence an auditor can receive: exported alert history, configuration baselines, change logs for detection content, and access records for the console. The EDR RFP questions page covers vendor, MDR and partner questions in more depth.