Why an open source SIEM for financial services starts with evidence, not tooling
A bank, payment processor or fintech that must show daily log review and 12 months of retention should decide the evidence it needs before it chooses a SIEM. For PCI DSS, the short answer is that a self-hosted SIEM can cover the logging and review obligations if it collects the right sources, keeps them intact and produces records an assessor can sample. Wazuh is the usual starting point for broad endpoint and server log coverage, and Security Onion fits teams whose main need is network-centric monitoring from Suricata and Zeek sensors. Where FTC Safeguards activity logging or DORA incident records also apply, the same evidence set has to serve those rules, so the platform choice follows from the log sources and deployment limits rather than from features alone.
PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to those that could affect the security of the cardholder data environment. That scope reaches merchants, processors, acquirers, issuers and service providers. The PCI SSC does not enforce compliance itself. The payment brands decide who must validate, and the assessment is documented either as a Report on Compliance from a Qualified Security Assessor or as a Self-Assessment Questionnaire with an Attestation of Compliance. Your assessor and acquiring bank therefore define what proof of log review looks like, so confirm their expectations for review records, time sources and log protection before you design the SIEM around them. PCI Data Security Standard lists the current requirements.
Start by listing every system that touches cardholder data, every system that could affect it, and every identity that administers them. Map each to a log source the SIEM must ingest, a reviewer who will sign off on alerts, and a retention period that the assessor will test. Confirm early whether the team can run a Distributed Security Onion deployment or a clustered Wazuh server with the staff and hardware for it, because those limits, not licensing, usually decide the design. Build this inventory first and the tooling decision becomes a comparison of fit, not a debate about brands.
Which financial regulations shape the SIEM build
This table maps each financial regulation or framework to what it asks of log sources, retention, review and tamper protection in a self-hosted SIEM. Read each row as a design input: the obligation on the left determines what the SIEM must collect, keep and prove. Confirm applicability with your qualified assessor, regulator or payment brand before fixing scope.
| Regulation or framework | What it requires for the SIEM | Evidence to prepare |
|---|---|---|
| PCI DSS v4.0.1 | Log all access to cardholder data environment systems, review logs daily through automated or manual methods, keep 12 months with the latest 3 months immediately searchable, and protect logs from change. v4.0.1 is the only active version since v4.0 retired on 31 December 2024; future-dated v4.0 requirements took effect 31 March 2025. | Log source inventory for the cardholder data environment, review records, retention settings, file integrity and access logs for the SIEM itself |
| FTC Safeguards Rule (16 CFR 314.4(c)) | Monitor and log activity of authorized users and require MFA for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. Applies to non-bank financial institutions under FTC jurisdiction. | Written Qualified Individual approval for any equivalent control, MFA coverage for SIEM console access, and user activity logs for systems holding customer information |
| DORA Articles 28 and 30 (ICT third parties) | Article 28(3) requires a register of information on ICT contracts. Article 30(2) requires contracts to state service locations, data processing locations and data return on termination. Relevant when a managed SIEM provider or hosting vendor stores your logs. | Register entry for each vendor holding log data, contract clauses on data location and return, and a documented exit plan under Article 28(8) |
| Swift Customer Security Controls Framework v2026 | 32 controls, 26 mandatory and 6 advisory, assessed independently and attested annually in the KYC-SA application. Swift environments need logging of the Swift interface and its administrators, with alerts on changes and tamper protection of those logs. | Mapping of each mandatory control to a SIEM log source or alert rule, independent assessment results, and annual KYC-SA attestation records |
| Log source scope for core banking and payments | Financial regulators and assessors look for the core banking, payment switch, card management and Swift gateway systems inside the monitored scope. Each source must produce records that show who did what, when and from where. | Asset inventory linking each log source to a regulated function, parser coverage tests and sample event records |
| Retention and tamper protection | PCI DSS sets a 12-month retention baseline. DORA and FTC expectations depend on your own record-keeping and incident evidence. Logs must be protected from alteration and access by the people whose activity they record. | Index lifecycle settings, role-based access on log indices, integrity controls on archives, and documented restore tests |
| Incident and reporting inputs (sibling page) | Detection and incident management duties under DORA Articles 10 and 17 are covered on the DORA detection and incident management page. The SIEM must keep alert and incident records that feed classification and reporting. | Alert records, case timelines and classification notes that link SIEM events to incident reports |
Which core banking, payment and SWIFT log sources to onboard first
Core banking and ledger systems hold account balances, postings and customer records, so they are usually the first sources an examiner asks about. Collection depends on the platform. Some expose audit tables or journal files that a forwarder can read, some write to a database that needs a query-based collector, and some only offer syslog or file export. Agree the method with the application owner before the project plan assumes an agent can be installed.
- Authentication events: Successful and failed logins, lockouts and password resets for operator and service accounts.
- Administrative changes: Creation or modification of users, roles, limits, products and interest or fee parameters.
- Transaction approvals: Manual overrides, reversals and approvals above internal thresholds.
- Configuration changes: Batch job definitions, schema changes and end-of-day parameter updates.
- Collection path: Agents where the operating system allows it, syslog or file forwarding for appliances, and database audit extraction where that is the only supported route.
Confirm the vendor-specific log formats, field names and retention of native audit tables with the application owner rather than assuming they exist.
Card authorization, switching and tokenization systems inside the cardholder data environment (CDE) are where PCI DSS logging requirements are tested most closely. Every system in scope for the CDE, and every system that could affect its security, needs logging that feeds the SIEM. Keep the SIEM's own collection paths within the scope agreed with the assessor, because each path can widen the CDE.
- Authentication and access: Logins to payment hosts, failed attempts and use of shared or generic accounts.
- Administrative actions: Changes to switch routing tables, key-related configuration and terminal or acquirer settings.
- Transaction-related alerts: Application errors, decline spikes and processing faults that indicate misuse or outages.
- Security control events: Firewall, file integrity and antivirus events on payment hosts.
- Collection path: Agents on hosts that support them, syslog from network devices and payment appliances, and a dedicated collection segment within the CDE.
Confirm with the payment platform vendor which events the application writes natively and whether the logs contain cardholder data that must be masked before they leave the environment.
SWIFT Alliance and connector hosts sit between the bank's internal systems and the SWIFT network, so they need separate handling. Swift's Customer Security Controls Framework expects users to protect these components and to be able to show that controls operate. Treat the connector hosts, their operator accounts and their message logs as a distinct log source group with its own access rules, retention and alert routing.
- Operator access: Logins to the Alliance hosts and connector administrative consoles, including privileged sessions.
- Message and session activity: Message submission, release and status events, reviewed against the bank's own payment controls.
- Software and configuration changes: Patching, configuration edits and changes to connector parameters.
- Isolation: Logs of connections between the SWIFT zone and the general network, since traffic crossing that boundary is high-value evidence.
- Collection path: Agents where supported, with syslog or file export for appliances, and a restricted collector that the general SOC cannot change without approval.
Confirm with the SWIFT service provider or connector vendor which logs they produce, where they are stored and how the bank's Swift attestation evidence is gathered.
Identity providers, directories and privileged access tools decide who can reach the systems above, so their logs often explain an incident faster than any other source. Collect them first, or at the same time as the core systems, so that a login to a banking application can be traced back to the directory and session that allowed it.
- Directory events: Account creation, group membership changes, password policy changes and privileged group additions.
- Single sign-on and MFA: Authentication attempts, factor enrollment, MFA bypass or exception events.
- Privileged sessions: Session start and end, approvals, command records where the tool produces them, and break-glass use.
- Key and secret access: Requests for database credentials, certificates or keys held in a secrets manager.
- Collection path: Native integrations or syslog from identity platforms, agents on domain controllers and Linux hosts, and API polling for cloud identity services.
Confirm which authentication and session events each identity product writes by default and whether they are retained long enough for the review cycle the bank has defined.
Cloud hosting, managed databases and third-party ICT services used by banks produce logs that the bank does not run itself. Under DORA, the contracts for these services must cover where data is processed and how the bank gets its data back, so the log export terms belong in the same review. Plan for the provider's native audit trail to be exported into the SIEM, and for the bank to know which events it will not see.
- Control plane events: Cloud account administration, role assignments, network rule changes and key policy edits.
- Data access events: Object storage and database access logs where the provider supplies them.
- Hosted application events: Administrative and authentication logs from SaaS banking and payment tools.
- Collection path: Provider log export to a bank-controlled storage account or stream, then ingestion by syslog or API collectors into the SIEM.
- Retention boundary: Agree which copy is the record of truth and how long the provider keeps logs if the bank's export fails.
Confirm with each provider which logs it exposes, the export format, delivery latency and whether the bank can keep an independent copy.
Which open-source SIEM platforms fit a regulated financial estate
No single open-source SIEM covers every financial estate equally well. The right choice depends on which log sources you must collect, whether network sensing is in scope, and which licenses and operating systems your legal and infrastructure teams will accept. The cards below set out where each option fits and what to check before you commit.
Wazuh as the host and log platform
Wazuh combines an indexer, a server, a dashboard and agents under a GPL-2.0 core, so the agent, decoder and rule layer is the part most teams build on. Its server can run as a cluster, and agentless syslog and API collection cover firewalls and devices that cannot run an agent. The dashboard ships prebuilt views for PCI DSS. For a financial estate, confirm which core banking, payment and SWIFT hosts you can install agents on, and which sources must come in through syslog instead.
Security Onion for network sensing
Security Onion bundles Suricata and Zeek with the Elastic stack, which suits teams that need network detection on payment and SWIFT segments alongside host logs. The Distributed deployment, with a manager, sensors and search nodes, is the recommended production design. Its Elastic License 2.0 is source-available rather than OSI open source, so have legal confirm acceptability. Version 3.x runs only on Oracle Linux 9, which may conflict with your standard build images.
Security Onion Pro for access controls
The paid Security Onion Pro edition adds OIDC single sign-on to the console, LUKS encryption for data at rest, FIPS mode and OS STIG compliance. Those features matter when examiners ask how analyst access to logs is controlled and how the platform is hardened. It is sold on 1 to 5 year terms, so the subscription becomes a recurring cost to add to any build estimate. Ask the vendor which of these controls are in scope for your deployment and how they are validated.
Graylog Open and OpenSearch as storage
Graylog Open and OpenSearch store and search logs at scale, but neither provides a complete correlation and compliance content layer on its own. Teams using them must build or source detection rules, PCI DSS review workflows, alert routing and retention policies. Confirm whether the storage layer meets your hot and archive retention needs, and who owns index lifecycle management after go-live. Choose these when your source mix is mostly application and database logs with a strong internal detection team.
Source mix decides the platform
Start with an inventory of log sources: mainframe or core banking exports, payment switches, SWIFT Alliance hosts, cloud accounts and network sensors. Hosts that can run agents point toward Wazuh. Network-heavy scope points toward Security Onion or a Suricata and Zeek sensor layer. Mixed estates often run both, with one platform forwarding to the other. Ask every candidate partner to map each source to a collection method and to flag sources with no supported agent or parser.
How a self-hosted SIEM fits inside a payment and core banking estate
The reference design separates three jobs: collection close to each log source, a manager or server tier that analyzes and routes events, and indexer or search nodes that hold alerts and logs for hot and cold retention. In a payment and core banking estate, collection agents or forwarders run in the client's own data centers or cloud accounts, and the SIEM itself stays inside that footprint. Wazuh maps to this model through its agents, server, indexer and dashboard, and Security Onion maps to it through its manager, sensor and search node roles, with its Distributed deployment recommended for production. Decide early which sources sit in the cardholder data environment (CDE), which sit in adjacent core banking or SWIFT zones, and which can forward to the SIEM from outside the CDE, because each boundary changes firewall rules and who can reach the log store.
The log store must sit outside the production networks it watches. Place the indexer, search and dashboard tiers in a management or security zone with tightly limited inbound paths, and allow only the forwarding flows that the collection design needs. The dashboard should be restricted to the SOC roles that review logs, with administrator access to the SIEM logged separately. Confirm with your QSA or internal assessor how the boundary is drawn for the CDE and for SWIFT-connected systems, because the SIEM can itself fall within scope when it stores or processes cardholder data or affects its security.
Redundancy needs explicit design. Security Onion's architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis, so a manager outage stops ingest into search even when sensors keep capturing. Ask any implementation partner how the manager tier is made resilient, how receiver nodes add pipeline redundancy and load balancing, and how log buffering behaves during an outage. Then test the failure: stop the manager in a non-production copy, confirm what is lost, and record the result as evidence for your operational resilience planning.
How a financial SIEM rollout runs from scoping to assessor-ready evidence
The sequence turns a set of financial log sources into a self-hosted SIEM whose scope, detections, access controls and daily review records can be shown to a QSA, an examiner or an internal audit team. Each phase closes with a written output that the next phase depends on.
Scope the cardholder data environment and in-scope systems
DeployOpen works with your compliance lead, network team and the payment or core banking owners to map which systems store, process or transmit cardholder data, which could affect the security of that environment, and which fall under the FTC Safeguards Rule or DORA. The output is a signed scope document listing systems, data flows, network segments and the owner of each log source. Done means every in-scope system has a named owner and a documented reason for inclusion or exclusion.
Inventory log sources and validate formats
The team builds a source inventory covering core banking, payment switches, SWIFT interface servers, identity providers, firewalls, databases, hypervisors and endpoints in scope. For each source it records the log format, transport (agent, syslog or API), time source, and whether the source can run an agent at all. Samples are collected and parsed in a test environment so that gaps are found before production. Done means every source has a validated sample and a documented collection method.
Size and deploy the platform in your infrastructure
Based on the inventory, DeployOpen sizes the Wazuh or Security Onion deployment against daily ingest and the retention tiers your assessor expects, then installs it in your data center or cloud accounts. For Security Onion, the distributed design with manager, sensor and search nodes is the recommended production layout, and the hardware minimums in the vendor documentation are the floor, not the target. Done means the platform runs in the environment you chose, with a tested backup and a documented upgrade path.
Configure detections and compliance views against PCI DSS Requirement 10
The team maps the audit log events required by PCI DSS Requirement 10 to specific collection rules, decoders and alert rules, then enables the matching compliance dashboards in the chosen platform. Detection content for payment and SWIFT activity is tuned against your own baseline so alert thresholds reflect real traffic. Done means each Requirement 10 expectation has a documented rule or view, a named owner and a test event that proves it fires.
Lock down MFA and access control on the SIEM
Logs that record payment and banking activity are themselves sensitive, so access to the SIEM is restricted by role, protected with multi-factor authentication, and tied to your identity provider where possible. The team configures audit logging for the SIEM's own administrative actions and confirms that log storage is protected from modification by ordinary administrators. Done means an access review shows every account, role and MFA method, and the SIEM's own audit trail is being collected.
Run the daily review workflow and a proof run
Before handover, the team runs a defined daily review cycle: alerts and review records are triaged, exceptions are documented, and escalations are routed to your SOC or on-call owner. A proof run injects controlled test events through representative sources to show that detection, alerting, review and retention work end to end. Done means a dated record exists for every review day in the proof run, and the test events appear in alert queues and stored logs.
Hand over runbooks and assessor-ready evidence
DeployOpen delivers runbooks for daily review, source onboarding, rule changes, backup and restore, upgrades and access reviews, along with an evidence index that maps each control to the configuration, logs and records an assessor would sample. Ownership of each recurring task is confirmed in writing with your team. Done means the evidence index is accepted by your compliance lead and the runbooks have been walked through with the people who will run them.
Which evidence assessors and regulators ask the SIEM to produce
This table maps the evidence that PCI DSS assessors, FTC Safeguards reviewers and DORA supervisors commonly ask for to the SIEM component or adjacent system that produces it. Read each row as a question to answer before go-live, and note that DeployOpen prepares this evidence but does not issue reports or attestations, which come from QSAs, self-assessments or independent auditors.
| Evidence item | Where it is produced | What to confirm before assessment |
|---|---|---|
| Daily log review records and alert dispositions | Wazuh dashboard alert history and case notes in the ticketing system | Named reviewer, review date, and a written disposition for each alert reviewed |
| Retention configuration and proof of searchable recent logs | Wazuh indexer index lifecycle settings and test searches against the oldest and newest log sets | Retention period matches the PCI DSS Requirement 10 expectation of 12 months, with the most recent 3 months searchable |
| Access logs for SIEM administrators | Wazuh server and indexer audit logs, plus the directory or SSO provider sign-in records | Admin actions are attributed to unique accounts and exported to a store the SIEM administrators cannot edit |
| Integrity controls and change history for the log store | Configuration management records, file integrity monitoring on SIEM hosts, and backup verification logs | Write-once or separately controlled storage for archived logs, and documented change approvals for rule and config edits |
| MFA configuration for SIEM and admin access | Keycloak, authentik or ZITADEL realm or policy exports for dashboard and console logins | Multi-factor authentication is enforced for every SIEM user, or an equivalent control is approved in writing by the Qualified Individual under the FTC Safeguards Rule |
| DORA incident timelines | Alert timestamps in the SIEM combined with incident tickets and the entity's ICT incident records | Each timeline shows detection, triage, classification and notification times that can be traced to a specific log entry or ticket |
What financial institutions ask before building a SIEM with a partner
What drives the cost of a self-hosted SIEM for a financial institution?
Cost follows scope: how many log sources you onboard, how much data each one produces per day, how long you keep it searchable, and how much detection engineering you need. The software itself is open source, so most spend is on infrastructure you own (compute, storage, network), implementation labor and recurring operations. Wazuh is distributed under GPL version 2, and Security Onion Pro is a paid edition sold on 1 to 5 year terms, so a paid edition adds a recurring license line only if you choose it. Ask any partner for a quote that separates one-time implementation from recurring run and support, and that lists source count, daily ingest and retention tier as explicit assumptions.
How long does a SIEM rollout take and what sets the pace?
The pace is set by the number of log sources, how many need custom parsing, how fast your change approvals move, and how much of the detection content must be written or tuned for your environment. A realistic plan starts with a sized architecture, moves through a pilot on a small set of sources, then expands in waves. Duration should appear as a written timeline in the fixed scope agreed before work starts, not as an estimate from a general guide. Ask the partner which milestones depend on your staff, such as access approvals and maintenance windows.
What does our team need to provide during a SIEM implementation?
Your team needs to name asset owners for each log source, approve the data flows and log access, and provide change windows for agents, firewalls and core banking or payment systems. Someone must also sign off on which events are in scope for PCI DSS and DORA reporting, because the SIEM can only collect what the owners allow. Plan for approvers on the security, operations and change advisory sides, and confirm who can grant service accounts that read logs from payment and SWIFT environments. Missing owners are the most common cause of delay, so ask the partner to list these dependencies in the scope document.
Can an internal security team run a self-hosted SIEM on its own?
A small internal team can run a SIEM if it has the skills to operate Linux, OpenSearch-based storage, agent management and detection tuning, and if it has time for the recurring work of patching and rule maintenance. Wazuh's 4.14 line shipped six patch releases in 2026, which means patching is a standing task rather than a one-off project. Many institutions split the work: the internal team owns alert triage and response, while a partner handles upgrades, hardening and support under a retainer. Ask the partner to show how much of the run work is covered, and which tasks stay with your staff.
Can a SIEM run without internet access in a restricted financial network?
Yes, the main platforms support offline operation, but the method differs by product. Security Onion supports full installs on networks without internet access, and its update tool applies updates from newer ISO media in airgap mode. Wazuh documents an offline installation guide, and vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform. Ask the partner to confirm how rules, signatures and vulnerability feeds reach the environment, how often they are refreshed, and who approves each media transfer.
How are upgrades handled given Wazuh patch cadence and Security Onion end-of-life dates?
Upgrades should follow a written policy that tracks each product's supported release line. Wazuh's current line is 4.14, with patch releases including 4.14.8 on 23 September 2026 and 4.14.9 on 14 October 2026, so a test-then-promote cycle is needed to keep pace. Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024. Security Onion 3.0.0 supports only Oracle Linux 9, and 2.4 installs on Oracle Linux 9 can upgrade to 3 after full packet capture moves from Stenographer to Suricata, while other distributions need a fresh install. Ask the partner to name the upgrade path, rollback method and the test environment used before production.
Which compliance evidence should we confirm before we sign a SIEM scope?
Confirm that the scope lists the log sources and events tied to PCI DSS, the FTC Safeguards Rule and DORA obligations, and that it names the retention and review records your assessors will sample. The FTC Safeguards Rule requires logging of authorized user activity, and the HIPAA-style audit log concepts apply only where your entity is in scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations; independent assessors and certification bodies do that. Ask the partner to show which evidence the implementation produces and which items remain with your compliance team.
What to ask an implementation partner before signing
Ask the partner to map each in-scope PCI DSS Requirement 10 and FTC Safeguards monitoring obligation to a named log source, a parser and a stored field, and to show that map before the statement of work is signed. For a card environment, that means the authentication servers, database audit trails, payment application logs, firewalls and file integrity events that cover the cardholder data environment, each with an owner. For a non-bank lender or broker under the FTC Safeguards Rule, ask how the partner shows that activity of authorized users is logged, and how a Qualified Individual's written approval of any equivalent control to multi-factor authentication would be recorded in the evidence file. Requirement IDs should appear in the partner's coverage matrix, not as a general claim of compliance.
Ask how the partner will onboard the SWIFT connector and core banking sources, which are usually the hardest to parse. Request a sample of each raw log format, the decoders or rules that will be written for it, and the test events used to prove alerts fire. For SWIFT, confirm which Customer Security Controls Framework controls the monitoring is meant to evidence, and ask whether the partner will leave the annual attestation in the KYC-SA application to your team. Ask who writes and tunes detection rules, who approves suppression changes, and how each change is versioned so an auditor can see what was active on a given date.
Ask the partner to prove retention and tamper resistance with a test, not a description. Request the storage design for hot and archived logs, the index or retention settings that enforce the period, a written method for restricting who can alter or delete events, and a sample of an integrity or access log that shows an attempted change. Confirm where backups and archives are stored and who holds their keys. For DORA, the partner's service agreement should state where data is processed and stored, give advance notice of changes to that location, and set out data return on termination or insolvency. Ask for the exit plan and the register of ICT services entry that will describe the SIEM. Confirm who owns each of these documents: the partner's contract, your register, or both.
How DeployOpen scopes and runs a financial SIEM build
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source SIEM platforms inside your own cloud accounts, data centers or air-gapped networks, so log data from core banking, payment and SWIFT systems stays under your control. Work starts with a written scope that names the platform, the log sources in each category, the retention tiers, the compliance views that must be produced and the responsibilities on each side. Most engagements are fixed-scope, which means deliverables and timelines are agreed before any build begins. Before scope is signed, confirm which of your environments are in the cardholder data environment, which systems carry Swift connectivity, and which entities in your group fall under DORA or the FTC Safeguards Rule, because those answers determine the log sources and retention that the build must cover.
During the build, DeployOpen prepares the evidence an assessor will ask for: configuration baselines, data flow diagrams for each log source, retention and access settings, change records for detection rules, and runbooks for daily log review. The deliverables cover what the SIEM produces, not what an auditor concludes. DeployOpen does not issue audit reports, attestations or certifications. A Qualified Security Assessor, an internal audit function or the relevant regulator makes that determination, so ask your assessor early which artifacts they expect in the format they expect. Security testing of the SIEM itself, its exposed dashboards and its APIs can be scoped as a separate adjacent engagement if your risk assessment calls for it.
After go-live, ongoing support, upgrades and continuous testing are available as retainers. This matters for a SIEM because Wazuh and Security Onion both ship patch and minor releases on a regular cadence, and an unpatched log platform is itself a finding. Ask any partner, DeployOpen included, to state in writing who applies upgrades, who tests detection content after each upgrade and who owns the on-call path when the SIEM itself fails. Those responsibilities should appear in the statement of work, not in a follow-up email.
