Open source SIEM for PCI DSS requirement 10: what the function must do
A self-hosted SIEM covers the collection, review and retention parts of PCI DSS Requirement 10, but it does not satisfy the whole requirement on its own. A merchant, processor or service provider still has to decide which components are in scope, enable audit logging on each of them, and show that people act on what the logs say. Requirement 10.2.1 sets the baseline that audit logs are enabled and active for all system components and cardholder data, and the sub-requirements under it list the event types to capture, such as administrator actions, access to audit logs, invalid access attempts and changes to authentication credentials. Wazuh or Graylog can receive and store those events, but only if the sources are onboarded and their logging is turned on at the source. The SIEM does not switch on logging for a payment application or a firewall that has it disabled.
PCI DSS v4.0.1 is the only active version of the standard, since v4.0 was retired on 31 December 2024 and v3.2.1 on 31 March 2024. Requirements 10.4.1 and 10.4.1.1 are where the SIEM does most of its visible work: daily review of logs from in-scope and security-function components, performed through automated mechanisms. Requirement 10.5.1 sets the retention period, which is at least 12 months with at least the most recent three months immediately available. Confirm the index retention and hot storage settings in your chosen platform against those figures, and confirm with your assessor how they will sample the review records.
The PCI Security Standards Council does not validate compliance or run enforcement. Qualified Security Assessors complete a Report on Compliance, merchants and service providers may complete a Self-Assessment Questionnaire, and the payment brands decide which entities must validate and how. Ask your QSA or acquirer early which SAQ or ROC applies and which evidence they expect from the SIEM, such as configuration exports, sample alerts and review logs. Plan to produce that evidence from the platform itself rather than from screenshots assembled after the fact.
How each Requirement 10 control maps to SIEM configuration
This table maps each PCI DSS Requirement 10 control group to what the SIEM must collect, review or protect, and where the setting lives in Wazuh or Graylog. Read it as a worksheet: the right column tells your team what to configure, and the evidence column shows what an assessor will ask to see.
| Requirement | What the SIEM must do | How to configure it in Wazuh or Graylog | Evidence an assessor expects |
|---|---|---|---|
| 10.2.1 to 10.2.1.7 (audit log events) | Capture user access to cardholder data, administrator actions, audit log access, invalid access attempts, credential changes, log start and stop, and system object creation or deletion | Wazuh: enable auditd and Windows event collection on in-scope hosts and map rules to these event types. Graylog: configure syslog and Beats inputs and confirm each source sends these event classes | Log source inventory, enabled audit settings and sample events for each event class |
| 10.3.1 (read access to logs) | Limit who can read log data to people with a job-related need | Wazuh: restrict dashboard and indexer roles with role-based access. Graylog: assign streams and roles so analysts see only the data their job requires | Current role assignments and the approval record for each access grant |
| 10.3.2 (logs protected from modification) | Stop anyone, including administrators, from altering stored logs | Restrict write and delete permissions on indexer and Graylog data directories, and separate log administration from the systems being logged | File permissions, admin account list and change records for log storage |
| 10.3.3 (prompt backup to central storage) | Forward logs promptly to a secure central server or media that is hard to change | Wazuh: centralize agent and syslog forwarding to the server cluster. Graylog: send inputs to Graylog nodes and back up Data Node or OpenSearch indices to write-once media | Forwarding configuration, backup schedules and restore test results |
| 10.3.4 (file integrity monitoring on logs) | Detect changes to audit log files and their settings | Wazuh: add log directories to syscheck or file integrity monitoring and alert on changes. Graylog: monitor configuration files with an external integrity tool, since Graylog does not provide this natively | Monitored file list, sample change alerts and records of the monitoring results reviewed |
| 10.4.1 (daily log review) | Review logs daily from cardholder data systems, critical components and security functions such as firewalls, IDS/IPS and authentication servers | Wazuh: use the PCI DSS dashboard view and route high severity alerts to a daily queue. Graylog: build dashboards and scheduled searches for these sources and route event notifications to a named reviewer | Daily review records showing who reviewed, what was checked and how findings were handled |
| 10.4.1.1 (automated log review) | Use automated mechanisms to perform the review, with human follow-up on what they flag | Wazuh: rules and active response generate alerts automatically. Graylog: event definitions and correlation feed notifications. Confirm with your assessor which automated checks count as the review | Rule and event definition exports, alert logs and the escalation workflow |
| 10.5.1 (12-month retention, 3 months hot) | Keep audit log history for at least 12 months, with the most recent 3 months immediately searchable | Wazuh: set indexer retention and snapshot policies so alerts stay searchable for 3 months and archives persist to 12. Graylog: size index sets with rotation and retention, and keep older indices in archive storage that can be restored | Retention settings, a search demonstrating data from the oldest retained month and storage sizing calculations |
| 5.3.4 (anti-malware logs kept to 10.5.1 period) | Retain anti-malware audit logs for the same period as other audit logs | Forward endpoint anti-malware logs into the same retention tier as Requirement 10 sources, not a shorter default | Retention settings applied to anti-malware log sources and a sample record from the full period |
Which events the SIEM must collect from cardholder data systems
Scope starts with every system component in the cardholder data environment, not just the payment application. Requirement 10.2.1 requires audit logs to be enabled and active for all system components and cardholder data, so the first deliverable is an inventory that lists each server, database, workstation, network device, firewall, authentication service and cloud service that stores, processes or transmits cardholder data, or that could affect its security. Each entry should name its log source, the collection method and the owner. Confirm the inventory with your qualified security assessor early, because gaps found at assessment time are expensive to close. Scope also reaches the systems that run security functions, such as the authentication servers and intrusion detection components that Requirement 10.4.1 later requires you to review. The seven sub-requirements, 10.2.1.1 to 10.2.1.7, map to specific feeds. Individual user access to cardholder data and administrator actions usually come from operating system audit subsystems, database audit features and application logs, so the Wazuh agent on Linux and Windows hosts reads those sources, while database and application logging needs explicit configuration that the vendor's documentation describes. Access to audit logs, invalid access attempts and changes to credentials come from the same host logs plus directory and authentication services. Log initialization and shutdown, and creation and deletion of system-level objects, are commonly captured by the host and the platform's configuration history. The PCI SSC FAQ on database and application logging is the natural next read for the database and application part.
Devices that cannot run an agent still need a documented syslog or API path. Firewalls, load balancers, switches and many appliance-based payment devices cannot host a Wazuh agent. Wazuh supports agentless monitoring of such devices through syslog collection and periodic API probing, and Graylog accepts syslog inputs. For each device, confirm which events it can export, whether it can send over TCP or TLS, how time is synchronized, and whether the forwarded events include the user, source address, target and outcome fields an assessor will look for. Test the path with a sample event from each class, then check that the event appears in the SIEM, because a silent forwarding failure is one of the most common gaps found when logs are reviewed. Record the test results as evidence for Requirement 10.2.1.
Which open source platforms fit a PCI DSS Requirement 10 deployment
Requirement 10 is less about the product than about whether it can collect the required events, review them daily, and keep protected, searchable history for a year. The options below differ mainly in agent coverage, licensing, and how much engineering the team must own to run them.
Wazuh with the PCI DSS dashboard
Wazuh combines agents on endpoints, a server that applies decoders and rules, an indexer that stores alerts, and a dashboard. Its dashboard includes prebuilt views for PCI DSS, which can help map alerts to the review and retention records an assessor asks for. The core repository is GPL-2.0, so review the license with counsel if you plan to modify and redistribute it. Confirm that agents cover every in-scope system, and that agentless syslog covers firewalls and other devices that cannot run an agent.
Graylog Open for log search and alerts
Graylog Open ingests syslog, GELF and Beats, routes events through streams and processing pipelines, and sends alerts from event definitions. Its index rotation and retention settings can be set to keep at least twelve months of history, with the most recent three months searchable. Graylog Open is licensed under SSPL-1.0, which is not OSI-approved, so legal review is needed before offering it as a managed service. Plan for MongoDB and a search backend, and confirm which correlation and compliance content you must build yourself.
Security Onion for network-based evidence
Security Onion bundles Suricata, Zeek, osquery and the Elastic stack into a platform for monitoring and log management. It fits deployments that need network evidence alongside host logs, such as intrusion detection records that support the correlation expected under Requirement 10. Its Elastic License 2.0 restricts offering the software as a managed service, which matters for service providers. Check that the team can run a multi-component sensor and manager stack, and that it can update the platform on the schedule the organization requires.
OpenSearch-based custom builds
Some teams build their own pipeline with OpenSearch for storage and search, a log shipper such as Filebeat or Fluent Bit, and their own alerting and dashboards. This gives full control of index lifecycle policies, storage tiers and access controls on the logs themselves. The trade-off is engineering effort: the team must write and maintain the parsers, detection rules, PCI DSS reports, and integrity controls that the packaged platforms provide. Confirm who will own those components after go-live and how the design proves log protection to a QSA.
Platform fit check before selection
Before choosing, confirm the in-scope log sources, daily ingest volume, retention tiers, and whether systems run without internet access. Ask each candidate how it protects logs from modification and how it supports file integrity monitoring on audit logs. Request a demonstration of the daily review workflow, including who reviews, how exceptions are recorded, and how review evidence is exported. Keep the license terms, offline update path and support model in the written scope.
How daily log review and log protection work in a SIEM
The sequence turns raw audit logs into reviewed, tamper-resistant evidence: logs are collected, reviewed daily through automation, alerts reach the people who own security functions, and the logs themselves are locked down and monitored for change.
Enable audit logging on every in-scope component
Confirm that audit logging is enabled and active on each system component that stores, processes or transmits cardholder data, plus the critical systems and security tools around it. The implementation team, working with the system owners, builds an inventory of log sources and checks each one against the event types in Requirements 10.2.1.1 to 10.2.1.7, including individual user access to cardholder data, administrator actions, invalid access attempts and changes to credentials. Done means every source appears in the SIEM with a test event, and the inventory records any gaps for remediation.
Build dashboards and automated review rules
Configure review views and detection rules in the SIEM, such as Wazuh compliance dashboards for PCI DSS or Graylog event definitions, so that the platform performs the log review that Requirement 10.4.1.1 expects to be automated. Your security team defines which events are high priority and which failed authentication or privilege changes trigger an alert. Done means each rule has a documented owner, a tested trigger, and a sample alert that shows the rule firing as designed.
Route alerts from security function components
Send alerts from network security controls, intrusion detection and prevention, and authentication servers to a named queue that the on-duty analyst watches. Requirement 10.4.1 calls for daily review of these components and of every system that handles cardholder data, so the routing must reach a person or a documented workflow each day. Done means a test alert from each category arrives at the queue and the analyst's acknowledgment is recorded in the case system.
Restrict read access to logs
Limit who can read audit logs to individuals with a job-related need, using role-based access in the SIEM and separate accounts for analysts, administrators and auditors. The identity team reviews the group memberships against the access request records and removes any account that no longer needs access. Done means the access list is exported, approved by the data owner, and kept with the review evidence for Requirement 10.3.1.
Protect logs from modification and back them up centrally
Forward logs to a secure central store, such as a dedicated indexer cluster or write-once backup media, so that copies exist outside the system that generated them. Administrators should not be able to alter stored events through normal SIEM functions. This step covers Requirements 10.3.2 and 10.3.3, including logs from external-facing technologies. Done means a restore test recovers a sample of logs from the backup, and the team can show who can change retention settings.
Monitor audit log files for changes
Deploy file integrity monitoring or change detection on the audit log files and their configuration, so any modification, deletion or stopped logging produces an alert. The engineer tests this by changing a monitored file in a non-production environment and confirming the alert. Requirement 10.3.4 expects evidence of the monitored files, the settings and the monitoring results, so keep the configuration and sample alerts together. Done means the test alert is recorded and routed to the same queue as other security events.
Record the reviewer's findings each day
Automation flags events, but a person must still document the review. Each day, the reviewer records the date, the sources reviewed, the alerts examined, the disposition of each one, and any escalation or follow-up. Keep these records in a ticketing or case system that cannot be edited silently. Done means an assessor can pick any sampled day and trace it to completed reviews, open items and the people responsible, which supports the evidence expected under Requirement 10.4.1.
Meeting 12-month retention with three months immediately available
Requirement 10.5.1 asks for audit log history to be kept for at least 12 months, with at least the most recent three months immediately available for analysis. In a self-hosted SIEM this splits storage into two tiers: a hot tier of indices that search returns in seconds, and a cold tier that holds older data you can still restore and query. The three-month hot window is the minimum you must keep searchable, and it is also the window your daily reviews under Requirement 10.4.1 depend on. Requirement 5.3.4 ties anti-malware logs to the same 10.5.1 retention period, so the endpoint protection feed needs the same tiering as your authentication and firewall logs, not a shorter default.
In Graylog Open, the hot tier is governed by index sets. Rotation by message count, size or time decides when a new index is created, and retention decides what is deleted, with the oldest indices removed first. Confirm that your index set retention keeps at least 12 months of data, and that the number of indices kept online covers the three-month window. Graylog's architecture guidance sizes log storage as daily ingest multiplied by retention days multiplied by 120 percent, and recommends giving the message journal 3 to 5 times daily ingest on SSDs. For Wazuh, the equivalent work is done in the Wazuh indexer's index lifecycle settings, which you should test against your own alert volume before go-live. Graylog Enterprise adds data tiering and archive restore, which matters if you need cold storage without keeping everything on hot nodes, but it is a paid edition.
The number that drives this design is your daily ingest, and no published figure substitutes for it. Measure ingest for each PCI-scoped source over a representative period, including peak business days, and include authentication servers, databases, firewalls and anti-malware consoles. Ask your partner to show the sizing worksheet, the journal settings, the rotation and retention values for each index set, and a restore test from the cold tier that proves the 12-month requirement can be met. Plan a periodic check that retention has not silently shortened when disks fill, because a SIEM that deletes early fails the requirement even though it looks healthy.
Evidence QSAs ask for and which SIEM component produces it
This table maps each piece of Requirement 10 evidence an assessor typically asks for to the Wazuh or Graylog component that produces it. Use it to plan where evidence lives before the assessment, not during it. The main takeaway is that the SIEM produces most of the logs and review records, but the access lists, retention proof and the SAQ or ROC context still come from your own processes and documentation.
| Evidence item | Wazuh component that produces it | Graylog component that produces it |
|---|---|---|
| Log source inventory for in-scope systems | Agent inventory and enrolled agent list in the Wazuh server and dashboard, plus syslog-connected device records | Input and sender inventory in the Graylog web interface, with stream assignments per source |
| Enabled audit log configuration (10.2.1) | Agent configuration and audit policy files managed centrally by the Wazuh server, exported for review | Input configuration and collector settings in Graylog, with the source system audit settings confirmed on each host |
| Review records and automated review output (10.4.1, 10.4.1.1) | Dashboard alert and rule-match history, plus compliance-framework views for PCI DSS | Event definition history, alert notification logs and dashboards, with notification routing to the reviewer |
| Read access list for log data (10.3.1) | Dashboard user and role configuration, reviewed against the access request records | Graylog user, role and stream permission settings, exported and compared with the approved access list |
| Log protection and change detection (10.3.2, 10.3.4) | File integrity monitoring results for the log directories and the Wazuh server configuration | Integrity checks run on log storage and configuration, supplemented by OS-level file monitoring on the Graylog hosts |
| Retention settings and 12-month proof (10.5.1) | Indexer retention policies and index state showing at least 12 months, with the most recent three months searchable | Index set retention and rotation settings, plus archive or Data Node storage records showing 12 months are present |
| SAQ or ROC and AOC context | The SIEM supplies evidence only; scope, approach and the completed SAQ or ROC are prepared by the entity and its assessor | The SIEM supplies evidence only; scope, approach and the completed SAQ or ROC are prepared by the entity and its assessor |
What a SIEM alone does not satisfy under Requirement 10
A SIEM collects and searches logs, but Requirement 10 is also assessed on the procedures, decisions and records wrapped around the tool. The cards below cover the gaps assessors most often find when the platform is in place but the operating process is not.
Documented review procedure and sign-off
Requirement 10.4.1 expects daily review of logs from in-scope components, and Requirement 10.4.1.1 expects that review to be automated where mechanisms are used. Automation does not remove the need for a written procedure that names the reviewer, the alerts or log sets reviewed, the escalation path and the record of each review. Check that your SIEM produces a reviewable record, such as dashboard snapshots, alert acknowledgments or ticket links, and that someone signs off on exceptions.
Onboarding every in-scope log source
A Wazuh or Graylog deployment only covers what has been connected. Each system that stores, processes or transmits cardholder data, plus the systems that perform security functions such as firewalls, IDS/IPS and authentication servers, must send logs in and be tested. Keep a source register that maps each component to its agent or syslog feed, its log types and the date it was verified, and review it whenever the cardholder data environment changes.
Policy on who may read logs
Requirement 10.3.1 limits read access to audit logs to people with a job-related need. The SIEM itself becomes a high-value target, since it holds records of every administrator action and access attempt. Define who holds analyst, administrator and read-only roles in the dashboard, the indexer and the server, how those roles are granted and removed, and how access to the SIEM is itself logged. Confirm that the platform's role model can express this policy before you build it.
Incident response follow-up
A correlated alert is only the start of Requirement 10 evidence. Assessors look for a path from an alert to a documented investigation, containment and resolution, including who was paged and what was decided. Decide which alerts open a ticket, how severity maps to response time, and where investigation notes live. Shuffle or a ticketing system can carry that workflow, but the response procedure and its records must be written and kept by your team.
Scope and segmentation decisions
The SIEM cannot decide which systems are in scope. Your team must define the cardholder data environment, document how network segmentation separates it from other systems, and record which components are critical or perform security functions. Those decisions determine which logs must be collected and reviewed daily. Re-confirm the scope after network changes, new payment flows or new third-party connections, and keep the documented boundary with the evidence that supports it.
Customized approach documentation
If you meet a Requirement 10 objective through the customized approach rather than the defined approach, the SIEM is only one part of the argument. You must document the control objective, how the design meets it, the risk analysis, and the testing and monitoring that show it works. The Qualified Security Assessor or the self-assessment must be able to trace that record. Confirm with your assessor and acquirer whether this approach suits your environment before you rely on it.
Questions buyers ask about PCI DSS Requirement 10 and open source SIEM
What does it cost to run a self-hosted SIEM for PCI DSS Requirement 10?
The software license is often the smallest line item, because Wazuh and Graylog Open are free to download and use. The larger costs are the infrastructure that stores logs for 12 months, the people who onboard log sources and tune detection rules, and any partner scope. Storage and compute grow with daily ingest and retention, so they recur every month. For a paid Graylog tier, the published pricing page lists Graylog Enterprise starting at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees (source: Graylog pricing page). Ask any partner for a written quote that separates one-time implementation, infrastructure, licenses and ongoing support.
How long does a PCI DSS log management deployment take?
Duration depends on the number of log sources, how many systems fall in the cardholder data environment, whether agents can be installed everywhere, and how much detection content must be written before the first daily review. A small, single-site environment with a few servers and firewalls moves faster than a multi-site estate with payment applications, databases and cloud workloads. Offline or segmented networks, change windows and the time needed to agree log retention and access rules add further time. Because DeployOpen works under fixed-scope agreements, the timeline is set in writing before work starts, based on the agreed scope. Ask for the timeline to be tied to named deliverables.
What does our internal team need to provide for the deployment?
Your team needs to supply an accurate inventory of systems in or connected to the cardholder data environment, network diagrams, access to log sources and change approval processes. Someone must own the daily log review process, approve who can read logs under Requirement 10.3.1, and decide how alerts reach responders. Security staff must confirm which events matter for each system so that the logging matches the sub-requirements of 10.2.1. Expect to name an internal owner for ongoing operations, including patching the SIEM and reviewing its own audit logs. Confirm these responsibilities with any partner before scope is signed.
Can a merchant implement PCI DSS Requirement 10 without a partner?
A merchant with a skilled security operations team can deploy Wazuh or Graylog Open without a partner, since both are self-hostable and documented. The harder parts are usually not installation but sustained work: writing and tuning rules, building the daily review record, protecting logs from modification, and proving retention to an assessor. Wazuh's dashboard includes prebuilt views for PCI DSS, which can help a small team organize evidence, but those views still need correct data behind them. If the team lacks capacity for this ongoing work, a partner can implement the platform and hand over runbooks, or support it under a retainer. The choice is a staffing decision as much as a technical one.
Is Graylog Open or Wazuh the better fit for PCI DSS Requirement 10?
Wazuh usually fits best when you need host-based monitoring, file integrity checks, agent-driven collection and a prebuilt PCI DSS dashboard. Graylog Open fits better when your main need is centralized log search, streams and alerting from syslog and application sources, with agents playing a smaller role. Wazuh is distributed under GPL version 2, while Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license, so license review matters if you plan to offer the platform as a service. Your decision should follow your log sources, the team that will operate the tool, and your legal review. A short proof of concept against your real sources answers the question better than a feature comparison.
How does a QSA assess a self-hosted SIEM for Requirement 10?
A Qualified Security Assessor examines the logging configuration, sample log records, review evidence and retention settings, then records findings in a Report on Compliance. Assessors may also examine system settings, the monitored files and the results of monitoring activities, as described for Requirement 10.3.4. Your entity's status is recorded in an Attestation of Compliance, while smaller entities may use a Self-Assessment Questionnaire. Certificates from vendors or consultants are not accepted as validation. DeployOpen prepares systems, controls and evidence for assessments, but does not issue audit reports, attestations or certifications; the QSA and the payment brands decide the outcome.
Does a self-hosted SIEM make us PCI DSS compliant?
No. A SIEM supports compliance but does not create it. PCI DSS covers the whole environment, including logging, daily review, access control, file integrity monitoring and documented processes, and it is validated through an assessment rather than by any tool. A self-hosted SIEM can produce the audit logs, retention and review records that Requirement 10 expects, provided it is configured and operated consistently. The payment brands decide which entities must validate and how, and the PCI SSC does not enforce compliance itself. Ask your QSA early which evidence they expect to sample from the SIEM.
When the customized approach changes the SIEM design
Most SIEM designs for PCI DSS Requirement 10 follow the defined approach, but PCI DSS v4.x also allows the customized approach for entities with robust security and risk management. Under the customized approach, an entity meets the stated objective of a requirement in a different way, so the SIEM does not have to match the wording of each sub-requirement. The PCI SSC explains the difference between this route and compensating controls in its blog post on compensating controls versus the customized approach, which is the best starting read for the team that owns the design. Confirm early whether your environment is eligible and whether your Qualified Security Assessor (QSA) will accept this route for the specific requirements you want to change, because the decision shapes the whole log architecture.
If you pursue the customized approach, the design documentation becomes the core of your evidence. Expect to record the objective each affected control serves, the risk analysis behind the alternative design, the logging and review mechanisms that replace the defined steps, and the testing that proves those mechanisms work. For a self-hosted Wazuh or Graylog deployment, that means documenting which sources feed the indexer or Graylog inputs, how alerts for administrator actions and invalid access attempts are produced, how the review happens, and how log integrity is protected. Ask your QSA which of these artifacts they will examine, in what form, and how long they expect the customized design to remain stable across upgrades of the SIEM platform.
Raise the question with your QSA before any architecture or tooling decision is final, because a SIEM built for the defined approach may need rework if the customized route is later rejected. Confirm the scope of the review, including which components are in the cardholder data environment and which security functions, such as authentication servers and intrusion detection, must still meet the defined steps. Also confirm how the SIEM's own access controls, time synchronization and backup design will be assessed. Agree these points in writing with the QSA and the partner implementing the SIEM so that the design, the evidence plan and the assessment expectations match from the start.
How DeployOpen scopes and delivers a PCI DSS Requirement 10 SIEM
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a PCI DSS Requirement 10 SIEM runs in the cardholder environment's own cloud accounts, data centers or air-gapped networks. We agree the scope, deliverables and timelines in writing before work starts, and we prepare the logging controls and evidence that a Qualified Security Assessor or the entity's assessor will examine.
How we scope
- Inventory every system component that stores, processes or transmits cardholder data or sensitive authentication data, plus security function components.
- Map each log source to the event categories in Requirement 10.2.1 and its sub-requirements, and record gaps.
- Confirm the daily review method, the 12-month retention target and the three-month hot storage tier in the written scope.
How we build
- Deploy the chosen platform, such as Wazuh or Graylog, with agents, syslog inputs and parsing for each in-scope source.
- Configure access restriction, log file protection, central backup and file integrity monitoring on audit log storage for Requirement 10.3.
- Build and test alert rules and automated review workflows, then verify that retention and search performance meet the agreed tiers.
How we hand over
- Deliver architecture, configuration baselines, data flow diagrams and runbooks in a form the entity's team and assessor can read.
- Provide an evidence pack listing log source coverage, review records, retention settings and integrity monitoring results against each requirement.
- Train the operators who will perform daily log review and document the procedures they follow.
How we support
- Offer ongoing support, upgrades and continuous testing through a retainer, separate from the fixed-scope build.
- Track platform releases, such as Wazuh 4.14 patch releases or Graylog 7.x updates, and plan upgrades with the client's change process.
- Re-validate log coverage when new payment systems, cloud services or cardholder data flows are added to the environment.
