Open source EDR for financial services: why the evidence trail decides the design
A bank or payments firm running open-source EDR should design for the evidence trail first and detection second. The core question is whether the institution can detect endpoint compromise, investigate it and show a regulator, auditor or insurer what happened, using telemetry that never leaves its own environment. The short answer on platforms is Wazuh as the core telemetry, alerting and case layer, Velociraptor for hunts and forensic collection, and commercial EDR kept where the institution needs vendor-backed coverage or a supported product it has already committed to. This is a design decision, not a compliance outcome: no platform choice makes an institution compliant, and examiners judge the controls around the tools.
Financial services evidence demands change the build compared with most other sectors. The FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, and it requires monitoring and logging of authorized user activity. For card data, PCI DSS applies wherever cardholder data is stored, processed or transmitted, and the Swift Customer Security Controls Framework applies to Swift users. Each of these means the Wazuh manager, the indexer and the Velociraptor server are themselves in scope as systems that hold sensitive evidence. Access to them needs unique accounts, MFA, and audit logs that the team can show were reviewed. Your team should confirm which of these frameworks applies to each legal entity before choosing retention periods or access roles.
Outsourced monitoring and third-party terms add a second layer. Under DORA, Article 30(2) requires every ICT services contract to state where services are provided and data processed, and to cover data return on termination, and Article 28(3) requires a register of contractual ICT arrangements. If a partner runs 24x7 triage on your Wazuh alerts or operates Velociraptor for you, that arrangement belongs on the register and its contract must say where evidence is stored. Before you sign, confirm with counsel and your DORA owner which framework applies to your entity, and ask any partner or commercial EDR vendor to show the data location, the access model for analysts and how you would recover evidence on exit.
Which financial services requirements shape the endpoint build
This table compares the financial services requirements that most often reach the endpoint team, the source that sets each one, and what it means for agent coverage, retention, change records and where telemetry lives. Read each row as a question to put to your compliance, risk and audit leads before the build is scoped, since the applicability of each source depends on your licence, charter, footprint and contracts.
| Requirement | Source | What it means for the build |
|---|---|---|
| Multi-factor authentication and logging of authorized user activity | FTC Safeguards Rule, 16 CFR 314.4(c) | Endpoint and admin logins must be logged and traceable to a unique user. Confirm with the Qualified Individual whether any MFA exception is approved in writing under 314.4(c)(5) before relying on it. |
| Cardholder data environment scope | PCI DSS v4.0.1 (active version since v4.0 retired on 31 December 2024) | Every system in or connected to the cardholder data environment needs agent coverage or an equivalent log source. Define scope first, because the endpoint estate often grows beyond what teams assume. |
| Regulated entity scope and ICT register | DORA, Article 28(3), applicable since 17 January 2025 to 20 financial entity types | Wazuh, Velociraptor and any hosting or support provider must appear in the register of ICT contractual arrangements. Confirm which entities in your group fall in scope. |
| Exit strategy and tested transition | DORA, Article 28(8) | Keep agent configuration, rules and collected evidence in formats you can export and move. Document and test how monitoring would continue if the platform or partner changed. |
| Contract terms on location and data return | DORA, Article 30(2) | Telemetry storage location, data processing sites and data return on termination must be written into the partner contract. Self-hosting inside your own accounts makes these terms easier to state. |
| Access to programs and data, and computer operations | SEC Release 33-8810, SOX Section 404 IT general controls | Admin access to the EDR server, rule changes and agent deployments need approval records and periodic access reviews. Retain change logs for the audit period your assessors use. |
| Customer Security Controls Framework controls | Swift Customer Security Controls Framework v2026 (26 mandatory and 6 advisory controls) | Endpoints on the Swift environment need monitoring and evidence for the relevant controls. Attestation is made annually in the KYC-SA application by the Swift user, so DeployOpen prepares evidence but does not attest. |
Which open-source platforms fit a bank's endpoint estate and why
A bank's endpoint estate usually needs continuous telemetry, the ability to hunt across every host, and network context to explain what happened. The cards below pair each open-source component with the job it does and the checks a regulated buyer should make before committing, including where a commercial product may still sit alongside.
Wazuh for continuous endpoint telemetry
Wazuh provides the agent, server, indexer and dashboard for alerting across Linux, Windows, macOS and other supported systems. Its core is licensed under GPL-2.0, which bank legal teams should review against how they distribute or modify it. The dashboard includes prebuilt views for PCI DSS and NIST 800-53, which help map alerts to control evidence. Confirm agent support for legacy Windows builds and core banking hosts, and pin the 4.14 patch line that fits your change calendar, since the version must be confirmed at build time.
Velociraptor for estate-wide hunts
Velociraptor runs hunts and targeted artifact collection across the estate, using VQL queries wrapped in artifacts that the security team can review and change without rebuilding clients. Offline collectors cover hosts where an agent cannot be installed, such as some branch or terminal systems. It is licensed under AGPL-3.0, so confirm with counsel whether modifications must be shared if the bank runs a customized build. The server is fully supported on Linux, and the 0.77.3 update addresses multiple CVEs, so verify the deployed version before use.
Security Onion, Suricata and Zeek for network context
Endpoint alerts often need network evidence to show where a session went after a compromised login. Suricata provides intrusion detection and Zeek produces connection and protocol logs, and Security Onion bundles both with osquery and the Elastic stack. Suricata is GPL-2.0 and Zeek uses a BSD-style license, while Security Onion is under the Elastic License 2.0, which restricts some hosted offerings. Sensor placement across core, payment and branch segments is the main design question to settle early.
Shuffle for triage automation
Shuffle automates the repetitive steps of alert triage, such as enrichment, ticket creation and host isolation requests, so analysts spend time on decisions. It is licensed under AGPL-3.0, which needs review if the bank modifies the platform and offers it to users over a network. Every automated response should have an approval step for actions that disrupt trading, payments or customer service. Confirm which actions require a human decision in your change policy before any playbook is enabled.
Commercial EDR or MDR alongside open source
Some banks keep a commercial EDR or managed detection service for endpoints that open-source agents cannot cover, or for vendor-managed round-the-clock monitoring. This split adds licensing cost and a second console, so it should follow a documented gap analysis rather than a general preference. Ask the provider where telemetry is stored, how long it is retained, and whether it can export to your Wazuh or SIEM pipeline. Contracts for these services fall under DORA's register and exit planning requirements.
Deployment patterns for regulated banks: on-premises, private cloud and segmented zones
In an on-premises pattern, the Wazuh indexer, Wazuh server, Wazuh dashboard and Velociraptor server run on hardware the bank owns in its own data centers. Wazuh documents several installation routes that fit this model, including a prebuilt OVA virtual machine, Docker, Kubernetes, Ansible and Puppet, plus an offline installation guide for networks without internet connectivity. Velociraptor stores its data in files on the server filesystem and does not need a separate database, which simplifies backup planning but makes storage sizing a direct hardware decision.
- Indexer and server placement: Keep the indexer and Wazuh server in a controlled management zone, with the Wazuh server able to run as a cluster for horizontal scaling.
- Agent reach: Open only the agent-to-server ports from endpoint subnets through firewall rules that the network team can document and review.
- Storage and retention: All alerts and collected artifacts stay on bank-owned disks, so retention periods are set by the bank's own policy.
- Velociraptor server: Velociraptor is only fully supported on Linux, so plan the host build and patch cycle accordingly.
- Third-party duties: If a vendor administers the hardware or the software, DORA Article 30(2) still expects the contract to state where services are provided and data processed.
Confirm with your data center team and implementation partner which installation route your platform standards allow and who holds administrative access to the hosts.
In a private cloud pattern, the institution runs the stack inside a cloud account it owns and controls, with its own network boundaries, key management and logging. The architecture stays close to the on-premises model, but compute can be scaled and rebuilt faster, and the Wazuh server can run as a cluster on Kubernetes or virtual machines. Velociraptor's documentation notes that its file-based storage is compatible with distributed file systems such as Amazon EFS, which is relevant when choosing shared storage for the server.
- Indexer and server placement: Place the indexer and server in a dedicated account or subscription, with private addressing and no public endpoints for the dashboard.
- Agent reach: Use private connectivity from endpoint networks, such as VPN or dedicated links, rather than routing agent traffic over the public internet.
- Storage and retention: Choose storage tiers and snapshot policies that match retention rules, and confirm the region where data is stored.
- Velociraptor server: Host the Linux server on a cloud VM and back up the file store on a schedule the incident team can restore from.
- Third-party duties: A cloud provider is an ICT third party under DORA, so the register of information and the exit plan under Article 28 must cover the account and its location.
Confirm the account region, the key ownership model and whether the cloud provider's support staff can access the data.
Payment and core banking networks usually sit in segmented zones with strict rules on what can cross their boundary. A common design places a collector or agent gateway inside the segment and forwards only the required events to the central indexer, so that card data environments and core systems are not opened to broad management traffic. Velociraptor can be run with an offline collector for hosts that cannot reach the server, and its results can be written to JSONL or CSV for transfer. Where a segment has no connectivity, Wazuh's offline installation guide and offline vulnerability repository are the documented starting points.
- Indexer and server placement: Keep the indexer in the management zone and avoid placing full Velociraptor servers inside payment segments.
- Agent reach: Route agents through a relay or gateway with explicit, logged rules for each segment.
- Storage and retention: Store segment telemetry within the same jurisdiction and access controls as the central store, and document any copies made during transfer.
- Offline hosts: Use Velociraptor offline collectors for hosts that cannot run a client, and record chain of custody for each file.
- Third-party duties: Any managed provider that touches segment data must be named in the contract and register, with its data locations stated.
Confirm with your PCI or core banking owners which flows the segment boundary permits and whether an exception is needed for management traffic.
A third-party operated pattern applies when a partner runs part of the monitoring stack, for example to triage alerts around the clock or to maintain the Velociraptor server. The bank may keep the platform in its own infrastructure while the partner holds administrative accounts, or the partner may host the stack in its own environment. DORA treats both as ICT third-party arrangements, which means the register of information, the contract content and the exit strategy must reflect the exact division of responsibility. The technical design should separate administrative roles from the data itself so that the bank can revoke partner access without losing evidence.
- Indexer and server placement: Specify in the contract whether the indexer and server are in the bank's infrastructure or the partner's, and name each site.
- Agent reach: Require that agents connect only to endpoints or gateways the bank controls, with partner access brokered through logged accounts.
- Storage and retention: Write retention periods, deletion on termination and data return into the contract, as DORA Article 30(2) requires for insolvency or termination.
- Exit planning: Document a tested transition plan under Article 28(8) that moves the indexer data and rules to another environment.
- Access review: Review partner administrative accounts on the same schedule as internal privileged users.
Confirm with your legal and third-party risk teams how the partner's sites and support locations will be listed in the contract.
How a bank rolls out self-hosted EDR in phases
The sequence moves from a written scope and asset inventory to a tested, staffed and owned service, so each phase closes with evidence the bank, its auditors and its examiners can review. Each step is gated by the output of the one before it.
Agree a written scope and asset inventory
The bank and the implementation partner list every endpoint and server in scope, grouped by operating system, business owner, location and whether the host can take an agent. Business owners confirm which systems hold customer data, payment functions or regulated workloads, because those drive coverage and retention requirements. The step closes with a signed scope document and an inventory the security team owns. Hosts that cannot take an agent are flagged now so offline collection and log-based monitoring can be planned for them.
Decide architecture and data location
The team records where the Wazuh indexer, server and dashboard run, where Velociraptor's server and its file store sit, and which jurisdictions hold alerts, collections and backups. Decisions cover cluster sizing, retention periods set by the bank's records policy, access to the consoles and how the design maps to the contractual and data location terms the bank already requires of its ICT providers. The output is an architecture decision record signed by the CISO and reviewed by the bank's third-party risk function.
Run a pilot on a representative set
The pilot covers Windows and Linux servers, a sample of workstations from different business units and the hosts most likely to behave unexpectedly, such as payment gateways or batch servers. The team measures agent performance, alert volume and whether alerts reach the expected queue. Operating system coverage is confirmed by testing rather than assumption, and any gaps are documented as accepted limitations with an owner. The pilot ends with a report of coverage, noise and issues that the change board reviews before production.
Tune detection content with documented changes
The team reviews Wazuh rules and decoders against the pilot data, suppresses known benign activity and adds rules for the bank's priority behaviors, such as new administrative accounts on servers or unexpected scripting on workstations. Each rule change carries a ticket, a rationale, a test result and an approver. Active response actions, such as blocking a process or isolating a host, are enabled only for cases the bank has approved in writing. The output is a rule change log that examiners and internal audit can trace.
Establish the Velociraptor hunt baseline and offline procedure
The team runs baseline hunts for persistence, scheduled tasks, unusual services and credential access artifacts across the pilot estate, then saves the results as a reference point for later comparison. An offline collector procedure is written and tested on a host without a client, covering who may build a collector, how media is transferred, how results are hashed and where they are stored. The step closes when the hunt results are reviewed and the offline procedure has been exercised once with its records retained.
Staff 24x7 triage and write the escalation runbook
The bank confirms who triages alerts at each hour of the day, whether that is an internal rota, a partner's monitoring service or a combination, and who holds decision rights for containment. The runbook defines severity levels, response times the bank sets for each level, escalation paths to incident response, legal and the business owner, and the criteria for notifying regulators. Tabletop exercises test the runbook with the actual on-call roster. The step closes when the roster, runbook and exercise notes are approved by the security operations lead.
Set change control and capture evidence
Changes to agents, rules, artifacts, active response settings and server configuration go through the bank's change process, with records that show the request, testing, approval and rollback plan. The team configures logging of administrative actions on the EDR consoles and stores configuration snapshots. The evidence set is mapped to the controls the bank must demonstrate, such as access control and audit logging for its regulated systems. The output is an evidence index that names each artifact, its owner and where it is kept.
Hand over to production with a support decision
The bank accepts the production service against the signed scope, the tested runbook and the evidence index. It then decides whether to operate the platform with its own staff, to keep a support or upgrade retainer with the implementation partner, or to combine both, based on the skills and hours available. Upgrade cadence, patch review and vulnerability handling for the EDR components are assigned to named owners. The step closes with a handover record and a support agreement, if one is chosen, that states response expectations in writing.
Who watches alerts around the clock and what it costs
Who triages EDR alerts overnight and on weekends?
Overnight triage is done either by your own rota of analysts or by a partner's monitoring service, and open-source tooling does not change that fact. Wazuh and Velociraptor produce alerts and collections, but someone must decide whether each alert is benign, suspicious or an incident. Confirm three things before you commit: who is named on the rota, what their decision authority is at 2 a.m., and how quickly a critical alert must be acknowledged. Ask any partner to show the written triage runbook and the shift handover record, not just a staffing diagram.
Should a bank build an in-house SOC or partner for EDR?
Build in-house when you already run a staffed security operations center with enough depth to cover nights and holidays, and partner when you cannot justify that headcount. Many institutions split the work: they keep investigation and decisions in-house and buy monitoring hours or implementation help from a partner. The main cost drivers are analyst coverage across shifts, detection engineering time, on-call rules and support subscriptions for the platform. Ask for a quote that separates implementation, detection content, monitoring hours and escalation responsibilities so you can compare build and partner options on the same basis.
What does an EDR escalation path need to work?
An escalation path needs named roles, severity criteria, timed handoffs and a record of every decision. Write down who receives a critical alert, who can isolate a host, who informs the incident commander and who contacts legal, the regulator liaison or the insurer. The path should also say what happens when the primary contact does not answer. Test it with a tabletop exercise before go-live, and keep the outcome in your incident records because examiners and insurers will ask for it.
Which Wazuh active response actions can run without human approval?
Only actions your institution has explicitly approved should run automatically, and destructive actions should require a person. Wazuh active response can execute scripts on agents in response to rules, so the approval model belongs in the rule design. A common pattern is to automate low-impact steps such as enrichment, tagging and blocking a known malicious hash, while host isolation, account disablement and process termination on production systems go through an approver. Document each automated action, its trigger, its rollback and the owner who signed off on it.
How should EDR detection tuning changes be recorded?
Every change to a rule, suppression, threshold or active response script should be recorded with the reason, the reviewer, the test evidence and the date. Keep these records in version control where possible, so you can show which detections were active during any given period. Tuning without a trail makes it hard to explain a missed detection to an examiner or a forensic reviewer. Ask any implementation partner how changes are proposed, tested on a non-production group and approved before they reach the production rule set.
What does the on-call model cost to run in-house?
The main recurring cost is people: analysts covering every shift, a detection engineer who maintains rules, and an escalation contact who can make decisions after hours. The cost rises with the number of hours covered, the severity of your service levels and how often alerts need manual investigation. Infrastructure and support subscriptions add to that, and the platform itself may still need upgrades and capacity planning. Ask for a breakdown of recurring staff hours, one-time setup work and support terms so you can compare the figures with a partner or a commercial service without guessing.
Where does commercial EDR or MDR sit next to open-source EDR?
Commercial EDR or managed detection and response often sits alongside open-source tooling where you need proven vendor content, managed monitoring or a prevention capability that your open-source stack does not provide. Open-source Wazuh and Velociraptor remain useful for telemetry, hunting, forensic collection and integration with your SIEM. Confirm whether the commercial service supports your operating systems, whether it can run in your environment and where its data is stored. For DORA-regulated entities, also check the contract terms on data location and exit, which are set out in the supplied regulatory facts.
Can a small security team cover night alerts alone?
A small team can cover night alerts alone only if the alert volume is low, the decision rules are clear and the on-call burden is sustainable over time. Most teams find that tuning reduces noise, but it does not remove the need for a person who can act when a critical alert fires. Ask yourself how many people can be on call, how often they are paged and whether they are trained to isolate a host safely. If the answer is uncertain, a partner can provide monitoring hours while your team keeps decision authority.
Evidence auditors, regulators and insurers ask for and which component produces it
This table maps the evidence a bank typically needs for an audit, regulator review or insurer claim to the open-source component that produces it. Read each row as a starting point for what to collect, then confirm with your auditor and regulator which artifacts they accept as sufficient, since auditors decide sufficiency for each engagement.
| Evidence | Requesting party | Producing component |
|---|---|---|
| Unique user identification and access records | Internal audit, PCI QSA, FTC Safeguards reviewers | Identity provider logs (Keycloak, authentik or ZITADEL) plus Wazuh endpoint login events |
| Audit logs of activity on systems holding customer data | Regulators, SOX auditors, internal audit | Wazuh alerts and archived events, retained in the Wazuh indexer under your retention policy |
| MFA configuration and enforcement evidence | FTC Safeguards reviewers, PCI QSA, Swift assessors | Identity platform configuration exports and authentication policy records, supported by Wazuh login telemetry |
| Change records for detection rules and artifacts | Model risk and change management reviewers, internal audit | Version control history for Wazuh rules and decoders, plus Velociraptor artifact versions and the Wazuh configuration history |
| Forensic collections with chain of custody | Insurers after a ransomware claim, law enforcement, outside counsel | Velociraptor collections and offline collector outputs in JSONL or CSV, with hash records and handling logs kept by your team |
| Vendor and data location records for ICT contracts | DORA competent authority, internal third-party risk team | Contract register maintained outside the EDR stack, listing where the hosting provider and support staff process data |
| Compliance dashboard views for PCI DSS and NIST 800-53 | PCI QSA, NIST-aligned examiners, board risk committee | Wazuh dashboard prebuilt compliance views, exported with dated screenshots and mapped to your own control narrative |
Where commercial EDR still sits alongside open source in banking
A bank does not have to choose between open source and commercial endpoint tooling for every host. In practice, the decision is usually made platform by platform, and several cases still point toward a commercial product or a managed service. First, check whether a contract, a parent group standard or a regulator-facing commitment already requires a named vendor's agent or a vendor-backed coverage guarantee. Second, confirm open-source agent support on each operating system and device class in the estate, because Wazuh agents cover a broad range of platforms but support for specific legacy systems, appliances and payment terminals must be verified against the current release notes rather than assumed. Third, ask your insurer and your examiners what tooling they expect to see in evidence packs for endpoint detection, since some will ask for named products or independent attestations that a self-hosted stack cannot supply on its own. Record the answers in writing before the design is fixed.
The DORA contract and exit requirements apply to any ICT provider that supports critical or important functions, and that includes your own implementation partner as well as any commercial EDR or MDR vendor. Article 28(3) expects a register of information covering every contractual arrangement for ICT services, and Article 28(8) expects documented, tested exit strategies and transition plans. Article 30(2) requires each ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination. For a hybrid design, this means your partner contract, your managed monitoring contract and any vendor agent licence should each be checked for these clauses. Ask every party to confirm in writing where telemetry is stored, which subcontractors touch it, how long they retain it, and how you would move detections and evidence to another provider within an agreed timeframe.
Staffing is the gap that most often pushes banks toward a managed service. Wazuh and Velociraptor can run around the clock, but someone must triage alerts at all hours, and a small in-house team may not cover nights, weekends and holidays. Decide whether the remaining hours will be covered by an internal on-call rota, a partner's monitoring service or a commercial MDR provider, and document the escalation path and response times you agree. Ask each provider to state its staffing model, its analyst qualifications, how it handles Velociraptor collections and chain of custody, and what happens to your data and detection content if the relationship ends. Hedge any vendor claim about coverage until you have tested it with a sample incident in your own environment.
How much work and cost does open source EDR for a bank involve?
What drives the cost of open source EDR for a bank?
The main drivers are the size and mix of the endpoint estate, the staffing model for monitoring and response, and how long you keep telemetry. Open-source software itself carries no license fee for the core products, so the spend sits in infrastructure, storage, detection engineering, 24x7 analyst coverage, and any support or retainers you buy. Each endpoint adds agent management and alert volume, and Windows, Linux and legacy Unix hosts need different collection and tuning. Retention multiplies storage and indexer capacity, so decide retention periods with compliance and legal before sizing hardware. Ask any partner to split the quote into these components so you can see which ones scale with headcount and which scale with endpoints.
What is one-time and what recurs in an open source EDR program?
One-time costs usually include architecture and design, initial deployment of the Wazuh server, indexer, dashboard and agents, Velociraptor setup, integration with your SIEM or SOAR, and the first set of detection rules and artifacts. Recurring costs include infrastructure running costs, storage growth, staff time for alert triage and tuning, patching and upgrades (Wazuh has shipped 4.14 patch releases roughly every one to two months in 2026, so budget for regular maintenance), vulnerability data updates, and any retainers for support or continuous testing. Ask the quote to mark each line as one-time or recurring and to state which items renew annually.
Can the bank run open source EDR itself without a partner?
A bank with mature security engineering can run Wazuh and Velociraptor in-house, provided it has people who can operate Linux servers, manage agents at scale, write and tune detection rules, and perform forensic collections. The harder part is staffing: alert triage needs trained analysts across all hours if you claim 24x7 coverage, and that is a people cost rather than a software cost. Many banks choose a hybrid model in which internal staff own the platform and a partner supplies deployment, hardening, documentation or retainer-based support. Decide this by mapping existing skills against the workload, not by the software license.
How long does an open source EDR rollout take for a bank?
Duration depends on scope: how many endpoint groups are in scope, whether the server is deployed on-premises or in a cloud account, how many operating systems and legacy hosts need separate handling, how many integrations are required, and how quickly change approvals move. A pilot on one business unit typically runs before a wider rollout, and offline or segregated networks add time for media transfer and update procedures. No fixed duration is supplied here, so ask any implementation partner for a phased plan with milestones and the approval steps it depends on, then confirm the timeline in the written scope before work starts.
What does the bank need to provide for an open source EDR engagement?
The project depends on accurate asset data, including an inventory of endpoints, servers, operating system versions and owners, because Wazuh vulnerability detection and agent deployment both rely on knowing what exists. You will also need change approvals for agent rollout, firewall and network changes, and any active response actions that could disrupt a business system. SOC staff must be named for alert handling, escalation paths and after-hours response, and someone must own detection tuning. Legal and compliance should confirm evidence handling and retention requirements before forensic collections begin. Put these dependencies in the scope so delays are visible and assigned.
Can Wazuh and Velociraptor satisfy FTC Safeguards or PCI DSS requirements alone?
No single tool satisfies these frameworks by itself. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, and it requires logging and monitoring of authorized user activity. Wazuh can collect and alert on logs and provides dashboards aligned to frameworks such as PCI DSS, but MFA enforcement comes from your identity stack, and PCI DSS anti-malware and other requirements may need a dedicated product. Velociraptor supports investigation and collection. Map each control to the tool, process or evidence that covers it, and have your QSA or the FTC-applicable counsel confirm the gaps. The PCI SSC does not enforce compliance, and assessments are issued by a Qualified Security Assessor or through a Self-Assessment Questionnaire.
What should a written quote for open source EDR include?
Ask for a fixed scope listing endpoint counts by operating system, server and storage sizing with the retention period, the deployment model and hosting location, and every integration with the SIEM, SOAR and identity systems. The quote should separate implementation, hardening, documentation, training and handover from ongoing support, retainers and 24x7 monitoring, and state which items are one-time and which recur. Require named deliverables, acceptance criteria, assumptions about bank-provided inputs, change control for scope growth, and the upgrade and patching process. Also ask how the partner handles evidence for auditors and what is excluded, such as commercial anti-malware or external staffing. Fixed-scope agreements are the norm, so the written scope is what sets the price.
Which parts of the EDR program change most with staffing and retention choices?
Staffing and retention shape the program more than the software does. Staffing decides whether alerts are triaged in business hours, after hours or around the clock, and it determines how fast a suspicious host is isolated. Retention determines how far back investigators can search for ransomware dwell time, insider activity or evidence needed by regulators and insurers, and it sets indexer and storage capacity. A bank that keeps detailed telemetry for longer periods will carry higher infrastructure and reporting costs. Model both variables together with your incident response requirements, and ask the partner to show how each choice changes the quote.
How DeployOpen scopes, builds and supports EDR for financial institutions
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is the bank's cloud accounts, data centers or an isolated network. For an EDR program, that means the Wazuh server, indexer and dashboard, the Velociraptor server and the agent rollout all run in the institution's environment, under the institution's control of keys, logs and retention. Most engagements are fixed-scope, so the written statement of work should name the endpoint classes in scope (core banking hosts, payment workstations, trading desktops, branch systems), the response actions the team is allowed to take, the hours of 24x7 triage coverage, the evidence the program must produce and the handover acceptance criteria. Ask any implementation partner, DeployOpen included, to show how each of those items maps to a deliverable and a named owner.
Ongoing work is typically covered by a retainer for support, upgrades, rule tuning and periodic security testing of the EDR stack itself, including the management plane and the agent update channel. Upgrades deserve explicit planning: Wazuh has shipped several 4.14 patch releases in 2026, and Velociraptor's documentation asked users to move to 0.77.3 to address multiple CVEs, so the retainer should define how fast patches are tested and applied in a regulated change process. DeployOpen prepares systems, controls and evidence for assessments, such as the records a examiner or internal audit will ask for, but it does not issue audit reports, attestations or certifications. Those come from the institution's independent auditors, assessors or regulators. Quotes follow from the written scope, so the reader should ask for a quote that separates one-time build work from recurring support, and states what each party must provide, including staff time for approvals and change windows.

