Wazuh for financial services

PCI DSS scope decides which Wazuh agents go out first, so the scope decision comes before any deployment plan. The standard applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to entities that could affect the security of that cardholder data environment. For banks, payment firms and fintechs, that covers issuers, acquirers, processors and service providers, along with the merchants they serve. The first question is which systems hold, handle or carry cardholder data. The second is which systems authenticate into that environment, administer it or connect to it. Those two groups form the first agent wave. Hosts outside them can follow once the core deployment is stable.

Scope mapping also sets the log sources that feed requirement 10, the logging and monitoring requirement. For each in-scope system, list where access and privileged activity is recorded: operating system authentication and sudo logs, database audit trails, application audit logs, and firewall or network device syslog. Wazuh agents collect local logs on the platforms they support, including Linux, Windows and AIX. Devices that cannot run an agent can send syslog to the Wazuh server, and the team can add periodic API probing where a device exposes one. The Wazuh dashboard includes a prebuilt PCI DSS view, but that view summarizes mapped alerts. It does not prove that every required log source is present, so each source should be checked against the scope inventory.

Requirement 11.5 covers change detection on critical files, and scope mapping determines which file paths Wazuh file integrity monitoring must watch. Start from each in-scope host type. Linux and AIX servers in the cardholder data environment will have different system binary, library and configuration locations, so one shared list will miss some paths and watch others that do not matter. Typical candidates include operating system binaries, authentication and logging configuration, payment application configuration, and the Wazuh agent configuration itself. Record the path list per host type, the owner who approves changes to it and the alert handling process. Confirm the final list with the QSA, since the assessor will ask how the paths were chosen.

Segmentation decisions made with the QSA change which hosts are monitored. If segmentation isolates a payment application or database from the rest of the network, hosts outside the isolated zone may fall out of scope and the agent wave shrinks. If a design change routes cardholder traffic through new systems, those systems join the wave and need their own log sources and integrity paths. Ask the QSA to confirm the scope in writing, including the data flow diagram, the system inventory and the segmentation testing that supports the boundary. DeployOpen can prepare the technical evidence for that scope, but the assessment and its Report on Compliance belong to the QSA.

Before a rollout plan is written, confirm four things: the list of in-scope and connected systems, the boundary and its testing evidence, the log sources required for each host type, and the file paths approved for integrity monitoring. Record who signs off each item and when it was last reviewed. A scope that changes after agents are deployed means rework on dashboards, rules and file lists, so treat scope confirmation as the first milestone of the engagement. The number of hosts, the platforms they run and the number of log sources also drive the effort of both the build and the ongoing tuning, which is why they belong in the written scope.

Wazuh documents agents for Linux, Windows, macOS, Solaris, AIX and HP-UX. For a bank, the AIX entry matters most because core and batch processing often run on AIX, while card switches, file transfer and middleware frequently run on Linux beside them. The documentation lists operating system families, so the team has to verify each combination before rollout: the exact AIX level in production, the agent version the documentation supports for that level, and the Linux distributions on the remaining payment hosts. Record each combination in the rollout plan with the documentation page and the 4.14 patch level used to check it. Listing a family only shows that an agent exists for it, and says nothing about whether the agent suits the host in front of you.

Next, confirm what the agent can read on the host. The agent collects log and configuration data only from the files and sources it is set to read, so each payment application needs a list of log paths, such as application logs, audit trails and batch job output, mapped to the Wazuh log collection settings. Check file ownership and permissions for the agent service account on each path. Also check how rotated and compressed logs appear, because a rotation scheme the agent does not follow creates gaps in the logging evidence that PCI DSS requirement 10 expects. Identify which host-level audit sources feed the agent, and whether the chosen AIX level exposes them in a form the decoders and rules can parse. Test each path with sample events on the non-production host before the rule set is treated as complete.

File integrity monitoring needs its own check. PCI DSS requirement 11.5 expects change detection on critical files, so the team should decide which AIX and Linux paths are in scope before enabling monitoring. Typical candidates include payment application binaries, configuration directories and trust stores, but each bank's list depends on its own architecture. Confirm in the Wazuh documentation for the chosen 4.14 patch level which scan schedules and monitoring modes are available on AIX, since the options available there may differ from those on Linux. Establish a baseline on the test host, then run a planned change and verify that the alert contains the path, the change type and the hash values the team expects. Directories that change every night, such as batch output, will generate noise, so agree exclusions with the change advisory board in advance.

Payment and banking workloads increasingly run in cloud accounts, and the audit trails those accounts produce must reach the same alerting and retention process as logs from on-premises systems. If they do not, changes to cloud administration, identity and access to systems that store or transmit cardholder data can fall outside the logging review that PCI DSS requirement 10 expects. Treat each cloud and SaaS audit source as one more monitored source from the first design session, with a named owner for each source and a documented path from event to alert to retained record.

The first design decision is the integration method. For each cloud or SaaS source, use the method the Wazuh documentation describes for the version you run, and record which sources that version supports. Do not assume a source that works in one release behaves the same way in another. Next, map identities and accounts. Each cloud account, subscription, project or SaaS tenant should be tied to an owner, an environment (production payment flows, test, or shared services) and the identities that act within it. Without that map, a rule that fires on an administrative action in a sandbox account looks the same as one in the cardholder environment, and the alert does not tell the responder which team or which scope is affected.

Timestamps need attention before correlation is useful. Cloud providers and SaaS platforms record events in their own formats and time zones, and some sources deliver events in batches instead of as they occur. Choose one reference time for the monitoring program, confirm that the Wazuh server and agents keep accurate clocks, and check how the decoders and rules shipped with the server parse each source's timestamp field. Then verify the chain with a controlled test: make a known administrative change in a non-production account, and confirm that the event appears in the dashboard with the correct time, source and acting identity.

Retention is a sizing and cost decision. Decide which events go to the Wazuh indexer, where they are searchable and feed alerts and dashboards, and which are archived to lower-cost storage for longer retention. Event volume, the number of sources and the search window drive indexer storage the most. Archive storage, cloud API activity and the tuning time your team spends on noisy sources are the other cost components. Ask any implementation partner to price these separately in the written scope, state who operates each store, and confirm how archived logs are retrieved for an assessor or an incident. Before the design is final, confirm the supported sources and integration method for the exact Wazuh version in use against the current documentation, because source coverage changes between releases and the patch cadence on the 4.14 line is frequent.

Retention periods for Wazuh should be set by the compliance owner and the assessor before anyone sizes the indexer, and installation defaults should not stand in for that decision. Start with a written retention schedule for each log source: Linux and AIX servers, cloud audit logs, firewall syslog and file integrity monitoring events may each carry different obligations. For PCI DSS requirement 10 logging, confirm with your Qualified Security Assessor how long audit logs must be kept and how much of that period must remain immediately available for query. Record the answer against each source, with the approver and the date. Assessors commonly ask who approved a schedule and when it last changed, so keep that history in the evidence set.

Indexer storage follows directly from that schedule. The Wazuh indexer is a full-text search and analytics engine that stores alerts, so the disk it needs grows with alert volume multiplied by the retention period for each tier. Measure alert volume per agent and per source over a representative window, then model the footprint for each retention tier. Include replica settings and any snapshot repositories you keep for recovery, and plan for growth from new agents and new log sources, since a cluster sized for current volume will reach its limit sooner than the schedule assumes. Confirm the sizing method, replica configuration and snapshot approach against the Wazuh documentation for the version you deploy before ordering hardware or storage.

Isolated segments need the offline installation guide, which covers systems without internet connectivity. Vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Vulnerability detection correlates the software inventory that agents collect with that vulnerability data, so the repository is only as useful as its refresh process. Decide how packages, rule updates and vulnerability data cross the boundary, who approves each transfer, how transfer media is checked, and how often the repository is refreshed. Record each refresh date, because stale vulnerability data makes detection results hard to defend in an assessment. Confirm with the vendor which components depend on this path and the order in which they must be updated.

These choices also shape the exit plan. If a third-party provider runs or supports Wazuh for a regulated entity, DORA Article 28(3) expects the service to appear in the register of information, and Article 28(8) expects documented and tested exit strategies and transition plans for ICT services that support critical or important functions. Article 30(2) expects the contract to state where data is processed and to cover data return on termination or insolvency. Self-hosting keeps the data in your infrastructure, but the plan must still show how indexer data, snapshots, decoders, rules, custom configuration, dashboards and agent settings would move to another platform or be retired and deleted. Test that path, and confirm which retention tiers can be exported in a usable form.

The cost discussion centers on infrastructure, engineering and operations, since the self-hosted software is open source under GNU General Public License version 2 and has no license fee. Infrastructure cost is mainly storage and compute, and it recurs as retention periods and log volume grow. Engineering covers the initial build, the offline procedures and the exit documentation, which is largely one-time work with periodic revision. Operations covers patching, repository refreshes, backup restore tests and on-call coverage, which recur for the life of the platform. Ask any quote to separate these lines, mark each as one-time or recurring, and state who pays for each. Wazuh Cloud is a separate managed service with its own plans, so evaluate it on its own terms.