PCI DSS 11.5 intrusion detection: what an open source build must cover
If your payment environment needs intrusion detection and change detection before its next assessment, start with the two controls that Requirement 11.5 names: traffic monitoring at the cardholder data environment (CDE) perimeter and at critical points inside it, and a change-detection mechanism on critical files. Open source can meet both, but only when the engines, signatures, alerting and change-detection baselines are kept current and their operation is recorded as evidence. The standard describes outcomes, so the decision in front of you is which sensor positions, rule sources and alert paths your own network diagram requires, then how you will prove each one works.
Log correlation does not satisfy this requirement. PCI SSC FAQ 1074 states that log correlation does not replace intrusion detection mechanisms such as IDS or IPS, so a SIEM that only aggregates firewall and server logs leaves a gap. Confirm with your assessor which sensor placements they expect to see documented, and map each placement to the network segments that carry cardholder data. Keep in mind that the PCI Security Standards Council does not enforce compliance or impose penalties. The individual payment brands decide which entities must validate and run any enforcement, so ask your acquirer or brand contact what they require.
Your Qualified Security Assessor (QSA), or your own self-assessment template where a Self-Assessment Questionnaire applies, records the result, and that record is what the Attestation of Compliance relies on. Plan for the evidence before the assessment starts: sensor placement diagrams, engine and signature update logs, a sample of alerts with documented triage, and change-detection reports showing that critical file comparisons ran at the required frequency. Confirm the exact frequency and evidence formats against the current requirement text and your assessor's expectations, because they determine how much of this evidence must be generated automatically.
How each 11.5 requirement maps to the function
This table sets each PCI DSS 11.5 requirement against what the function must do, how Suricata, Zeek, Security Onion or Wazuh can serve it, and where assessors usually look for evidence. Read it as a build checklist: the first two rows cover network monitoring, the last covers file change detection, and the notes on placement, update cadence and tuning apply across all of them.
| Requirement | What the function must do | How to configure the tooling |
|---|---|---|
| 11.5.1 IDS or IPS monitoring | Monitor all traffic at the CDE perimeter and at critical points inside the CDE, alert personnel to suspected compromise, and keep engines, baselines and signatures current | Deploy Suricata sensors through Security Onion at the CDE perimeter and at each internal segment boundary facing cardholder systems, with rules managed in the Security Onion Console and alerts routed to the SOC queue |
| 11.5.1.1 Covert malware channels (service providers only) | Detect, alert on or prevent covert malware communication channels, applicable only if the entity is a service provider; mandatory since 31 March 2025 | Confirm applicability with the payment brand or acquirer first; if it applies, add Zeek connection and DNS logs and Suricata rules for command-and-control patterns, and document the detection logic |
| 11.5.2 Change detection on critical files | Alert on unauthorized changes to critical files and perform critical file comparisons at least once weekly | Use Wazuh file integrity monitoring on CDE hosts and define critical paths, schedule comparisons at a frequency of at least weekly, and send alerts to the same triage workflow as network alerts |
| Sensor placement | Traffic must be visible at the perimeter and critical internal points, so sensor coverage must match the CDE data flow diagram | Place taps or SPAN ports at the CDE edge, between CDE segments and the corporate network, and at payment gateway links; size each sensor for peak throughput and confirm packet loss is measured |
| Rule and engine update cadence | Engines, baselines and signatures must stay current throughout the year, not only at assessment time | Set a documented schedule for Suricata rule updates and Security Onion upgrades, test in a staging node, and in airgap mode apply updates from newer ISO media |
| Tuning and suppression | Tuning changes must be justified, reviewed and traceable, so a suppressed rule cannot silently hide a compromise | Record each modify, suppress or threshold change in the Detections interface with a ticket reference, a named approver and a review date, and keep the change history with the evidence |
| Alert handling evidence | Assessors look for records showing that alerts were reviewed and that suspected compromises reached personnel | Keep alert triage notes, escalation records and on-call acknowledgments; confirm with the QSA which retention period and sample set they will request |
Which open source platforms fit a PCI DSS monitoring build
Requirement 11.5 needs traffic monitoring at the cardholder data environment (CDE) perimeter and a change-detection mechanism on critical files. No single open source product covers both, so the platform choice follows from which control each component serves and how the pieces report into one alert queue.
Suricata as the IDS/IPS engine
Suricata is the signature-based engine that inspects traffic at the CDE perimeter and at critical internal points, and it is the component most directly tied to requirement 11.5.1. It is licensed under GPL-2.0, and version 8.0.7 was published on September 15, 2026. Confirm that your rule sources are current, that you can show a documented update process for engines and signatures, and that sensor placement covers every path into the CDE, including payment links to third parties.
Zeek for metadata and covert channels
Zeek records structured connection, DNS, HTTP and TLS metadata, which helps analysts spot the covert malware channels that service providers must address under requirement 11.5.1.1. Zeek is distributed under a BSD-style license from the Regents of the University of California. Confirm that your team has the skills to write or tune Zeek scripts, and treat Zeek logs as investigation support rather than as a replacement for IDS alerts, since PCI SSC FAQ 1074 says log correlation does not replace intrusion detection.
Security Onion as a bundled distribution
Security Onion packages Suricata, Zeek, the Elastic stack and sensor management into one Linux distribution, which shortens the build for a team without a large monitoring staff. Its repository is licensed under the Elastic License 2.0, a source-available license rather than an OSI-approved open source license, so have counsel review the terms. The Pro edition adds OIDC single sign-on, FIPS mode and OS STIG compliance on paid terms. Confirm Oracle Linux 9 support for Security Onion 3.x in your environment before you commit to hardware.
Wazuh for file integrity monitoring
Requirement 11.5.2 calls for a change-detection mechanism that alerts on unauthorized changes to critical files and compares those files at least once weekly. Wazuh provides file integrity monitoring as part of its XDR and SIEM platform and is licensed under GPL-2.0. Confirm in your own environment that its file integrity module covers the operating systems, containers and critical file paths in your CDE, that comparison runs at the required frequency, and that alerts reach the same queue as your IDS alerts.
Shuffle and MISP as optional support
Shuffle can automate triage and ticket creation from IDS alerts, and MISP can hold indicators shared with your sector community. Shuffle is licensed under AGPL-3.0 and MISP under AGPL-3.0, so both carry network copyleft obligations if you modify and host them. Neither is required for requirement 11.5, so add them only when your alert volume or threat sharing needs justify the extra maintenance. Confirm each tool's fit with your incident response and retention procedures before relying on it as evidence.
How Security Onion and Wazuh divide the work
The split that matters most is between sensing and deciding. In the Distributed deployment that Security Onion recommends for production, sensor nodes capture and inspect traffic at the CDE perimeter and critical points, search nodes hold the indexed data, and a manager node coordinates both. Security Onion's architecture documentation warns that if the manager goes down, search nodes stop indexing because they cannot reach Redis. For requirement 11.5.1, that means a manager outage can silently blind the analyst console while sensors keep running. Confirm with your integrator how the manager is protected, whether receiver nodes are included for pipeline redundancy and load balancing, and how an outage is detected and alerted on.
Wazuh covers the second control, the change-detection mechanism under requirement 11.5.2. Its file integrity monitoring compares critical files against a known baseline and alerts on unauthorized changes. The requirement itself sets the floor of a critical file comparison at least once weekly, so the schedule you configure in the Wazuh agent and the frequency you document in your evidence should match or exceed it. Decide now which files and directories count as critical for your CDE systems, because the choice drives both the alert volume and what an assessor will ask you to show.
An alert is only a control if a named person acts on it within a set path. Route Suricata and Security Onion alerts, and Wazuh file integrity alerts, to a ticketing or paging queue with an owner, severity levels and a required disposition for each alert. Write the triage path down: who reviews, what counts as a suspected compromise, what escalation looks like after hours, and how each decision is recorded. Requirement 11.5.1 expects personnel to be alerted to suspected compromises, and PCI SSC FAQ 1074 is clear that log correlation does not replace intrusion detection. Your triage record is the evidence that the alerting works.
Evidence an assessor asks for under 11.5
This table lists the evidence items a QSA is likely to request for requirement 11.5.1 and 11.5.2, the component that produces each item, and the points to confirm before the assessment. Use it to prepare the evidence folder early, since the assessor will judge whether the records show the monitoring ran continuously and that alerts were handled.
| Evidence item | Source component | What to confirm with the QSA |
|---|---|---|
| Sensor placement diagram showing CDE perimeter and critical points | Network diagram, Security Onion sensor nodes, tap and span records | Which links count as the CDE perimeter and critical points, and whether the assessor accepts the diagram scope |
| IDS engine and rule versions with update logs | Suricata version output, Security Onion update records, NIDS rule source logs | How the assessor wants version history shown and how often they expect signature updates to be recorded |
| Baseline and engine currency checks | Suricata and rule set configuration, update tool logs, airgap update media records | Whether an offline update process meets the expectation that signatures stay current in an isolated environment |
| Tuning and suppression records | Security Onion Console Detections interface (modify, suppress and threshold entries) | Whether each suppression needs a written justification and a reviewer sign-off |
| Alert samples and response tickets | Security Onion alert queue, ticketing system linked to the SOC | Which alerts the assessor will sample, and how to show that personnel were notified and the alert was closed |
| Change-detection configuration for critical files | File integrity monitoring tool (for example, Wazuh FIM), critical file list | Which files count as critical, and whether the scope matches the CDE asset inventory |
| Weekly critical file comparison reports | FIM scan output and alert history | Proof that comparisons ran at least weekly and how gaps or failed runs are documented |
| SAQ or ROC section mapping | SAQ D or ROC templates, internal control matrix | Which assessment path applies (defined or customized approach) and where each piece of evidence is referenced |
What tooling alone does not satisfy in 11.5
Deploying Suricata, Zeek or Security Onion gets the sensors running, but requirement 11.5 is judged on coverage, process and evidence. The cards below cover the points where an assessor finds gaps that a tool deployment alone does not close.
Log correlation is not intrusion detection
A SIEM that correlates firewall and server logs does not replace a sensor that inspects traffic at the CDE perimeter and critical points. PCI SSC FAQ 1074 is explicit on this point. Check that each in-scope boundary has a Suricata or Zeek sensor feeding alerts to a person who acts on them, and that correlation rules are treated as a complement, not the control itself.
Encrypted and out-of-scope segments
A sensor placed on the wrong segment sees nothing useful. Traffic that is encrypted end to end, or that crosses a segment the sensor cannot mirror, falls outside its view. Map every CDE entry and exit point, confirm the tap or span captures it, and document where inspection stops and what compensates, such as host-level alerting on those systems.
Documented signature and baseline updates
Requirement 11.5.1 expects engines, baselines and signatures to stay current, which means an owner, a cadence and a record of each update. Open-source rule sets change often, so a stale Suricata ruleset is a finding even when the sensor is healthy. Write the update procedure, test rule changes before production, and keep dated evidence of each update and any rules suppressed.
File integrity tools need proof of weekly comparison
Requirement 11.5.2 asks for change detection on critical files, with comparisons at least once weekly. Installing a file integrity monitor does not show that the comparison ran or that unauthorized changes produced alerts. Define the list of critical files for each CDE system, confirm the scan schedule in configuration, and retain reports showing each weekly run and how alerts were handled.
Customized approach needs a targeted risk analysis
If an entity meets 11.5 through the customized approach rather than the defined approach, the stated objective must be met in a different way and backed by a documented targeted risk analysis. A sensor design chosen for cost reasons does not qualify on its own. Confirm with the QSA which objective is being met, how the risk analysis was written, and how it is reviewed when the environment changes.
Assessment must use the correct template
The assessment is documented on an official PCI SSC template, either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance. Which one applies depends on the entity and its acquirer or payment brand. Confirm the required template and assessor role early, and do not treat an internal checklist or a certificate as validation of 11.5.
How an 11.5 monitoring rollout runs
The sequence moves from defining the cardholder data environment to a set of tuned detections, change-detection coverage and triage records that an assessor can trace back to requirements 11.5.1 and 11.5.2. Each step produces an artifact that the next one depends on.
Scope the CDE and connected systems
Start by documenting which systems store, process or transmit cardholder data or could affect its security, including connected networks, administrative paths and third-party access. DeployOpen works with your team and assessor-facing documentation to produce a current data flow diagram and a system inventory. This step is done when the scope is written down, reviewed by the people who own each system, and agreed in the written scope before any hardware is ordered. Ask the partner how they will handle scope changes that happen mid-project.
Map perimeter and critical points
Identify every point where traffic enters or leaves the CDE and each internal segment boundary that matters for cardholder data, such as payment application tiers, database zones and jump hosts. The output is a monitoring map that lists the tap or span location for each point and the traffic it must see. Confirm with your network team which points are physically reachable and whether encrypted traffic terminates before a sensor can inspect it.
Size and place sensors
Choose sensor hardware based on the link speeds at each monitoring point, the expected traffic volume and the retention period for packet capture and metadata. Security Onion publishes minimum hardware requirements for standalone, manager, search and sensor nodes, and it supports only x86-64 processors, so confirm those constraints against your procurement standards. The deliverable is a sizing sheet per site and a placement diagram that shows which sensor watches which segment. Ask for packet loss testing at expected peak load before sign-off.
Deploy Security Onion or Suricata
Install the chosen stack in the client's own environment, using the Distributed deployment type where production scale calls for separate manager, sensor and search nodes. For air-gapped zones, the ISO carries packages and rule sets, so the install does not depend on internet access. The step is complete when each sensor reports traffic to the console, the Suricata engine is running on each monitored interface, and the configuration is recorded in version control.
Load and tune rules
Load network intrusion detection rules into Suricata and document the rule sources, update cadence and the owner responsible for signature currency, which requirement 11.5.1 expects you to keep current. Tune noisy rules through modification, suppression and threshold settings in the Security Onion Console, and record each change with a reason. The check is a written baseline of expected traffic and a tuning log that an assessor can read without the engineer present.
Integrate change detection on critical files
Deploy a change-detection mechanism, such as file integrity monitoring, on the critical files identified in scoping, and set it to alert on unauthorized changes and to compare critical files at least once weekly. This is separate from network intrusion detection and requirement 11.5.2 is met by it, not by the sensors. Verify by making a controlled test change on a non-production copy and confirming that an alert reaches the same triage queue used for network alerts.
Run alert triage and escalation
Define who reviews alerts, what severity leads to escalation, and how the team records the outcome of each investigation. Connect the alerts to your ticketing or SOC process, and run a test alert through the full path to confirm that personnel are notified. The output is a triage procedure, a named on-call rota and a log of dispositions. Log correlation does not replace intrusion detection under PCI SSC FAQ 1074, so keep triage tied to the sensor alerts themselves.
Assemble evidence for the assessor
Collect the scope document, network diagram, sensor inventory, rule update records, tuning log, change-detection configuration, test results and triage records into one evidence package mapped to requirements 11.5.1 and 11.5.2. DeployOpen prepares this evidence, but the Qualified Security Assessor or self-assessment owner decides what is sufficient and signs the Attestation of Compliance. Ask the partner which evidence they will produce and how it will be refreshed after rule or topology changes.
Questions buyers ask before hiring help for PCI DSS intrusion detection
What drives the cost of PCI DSS intrusion detection with Security Onion?
Cost is driven by how many sensors you need, how fast the links they watch are, how much rule tuning the environment requires, and how much internal staff time the alerts consume. Sensor hardware and taps are one-time costs per site, while storage, rule maintenance, and analyst time recur. Security Onion is free to use, but the hardware requirements are published, so you can size sensors against your link speeds before buying anything. Security Onion Pro is a paid edition sold on 1 to 5 year terms, so ask for its licensing as a separate line item if you need features such as OIDC single sign-on or FIPA-related hardening. Ask any partner for a quote that separates one-time setup from recurring support, tuning and upgrades.
How long does a PCI DSS intrusion detection deployment take, and what does it need from us?
Duration depends on the size of the cardholder data environment, how many perimeter and internal points need monitoring, and how quickly your change process approves network access. Before work starts, expect to provide current network diagrams, a defined CDE scope, the locations where taps or span ports can be placed, and a named owner for change approvals. You will also need staff who can triage alerts once the sensors are live, because a sensor that produces alerts nobody reviews does not support requirement 11.5.1. Agree the timeline in a written, fixed scope before work begins, and confirm which parts depend on your network team's schedule.
Can our team run PCI DSS intrusion detection on its own?
A team with network engineering skills and a dedicated analyst can run Security Onion in house, provided it can size sensors, maintain rule sets, tune false positives, and document alert triage. The harder part is sustained operation: keeping signatures current, applying upgrades before end-of-life dates, and producing evidence that the monitoring ran continuously. Security Onion's Distributed deployment is the recommended production design, and it adds manager, sensor and search nodes that need ongoing care. Many organizations split the work, keeping alert review in house and bringing in a partner for the build, hardening, backups and upgrade planning. Decide which of these tasks your team can hold on a recurring basis.
Does PCI DSS intrusion detection require an SAQ or a ROC?
The answer depends on your merchant or service provider status, your card brand's validation rules, and the SAQ type that fits your environment. Requirement 11.5.1 appears in the SAQ D questionnaire, and service providers also face requirement 11.5.1.1 on covert malware channels. A Qualified Security Assessor completes a Report on Compliance, while a Self-Assessment Questionnaire comes with an Attestation of Compliance. Confirm with your acquirer or payment brand which validation path applies to you, because the PCI SSC does not enforce compliance itself. Certificates are not accepted as validation, so plan for the official templates from the start.
Should we deploy Security Onion 2.x or 3.x given the end-of-life dates?
For a new deployment, plan on Security Onion 3.x rather than 2.x. Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024, so neither should carry a production CDE. Version 3.0.0 supports only Oracle Linux 9 and replaced Stenographer with Suricata for full packet capture. An existing 2.4 installation on Oracle Linux 9 can upgrade to 3, while other distributions need a fresh install. Also confirm that your hardware is x86-64, since Security Onion supports only that processor type. Ask your partner for a written migration plan that covers packet capture, rule sets and retained alert history.
Does DeployOpen issue PCI DSS compliance attestations?
No. DeployOpen plans, implements, hardens, documents and supports the monitoring platform and prepares the systems, controls and evidence that requirement 11.5 depends on. Attestations and reports come from the entity itself and the independent assessor it engages, such as a Qualified Security Assessor for a ROC. DeployOpen does not issue audit reports, attestations or certifications. In practice, we supply the sensor design, rule management records, alert triage evidence and change-detection configuration so that your assessor can review them. Confirm with your assessor early which evidence they expect to see in your environment.
Is a change-detection tool needed alongside intrusion detection?
Yes. Requirement 11.5.2 asks for a change-detection mechanism, such as file integrity monitoring, that alerts on unauthorized changes to critical files and compares critical files at least once weekly. The PCI SSC's FAQ 1074 also makes clear that log correlation does not replace intrusion detection mechanisms such as IDS or IPS. Intrusion detection and change detection are separate controls, so budget and scope them separately. Confirm which file set counts as critical in your CDE, and check whether your chosen platform, such as Wazuh with file integrity monitoring, covers the hosts in that set.
Which versions and licenses to confirm before you build
Confirm the platform versions before you commit to a design, because the Security Onion line has changed recently. Security Onion 2.4 reached end of life on October 1, 2026, so a 2.4 deployment will no longer receive fixes and needs a plan to move forward. Security Onion 3.0.0 was released on March 31, 2026 and supports only Oracle Linux 9. If your sensor and manager standard is another Linux distribution, a 3.x build means a fresh install, and the in-place upgrade path from 2.4 applies only on Oracle Linux 9 after full packet capture moves from Stenographer to Suricata. The latest tagged release in the repository is 3.3.0, published September 11, 2026. Check the Security Onion end of life documentation and the project's GitHub repository on the day you buy, because tags move quickly.
Review the license before you assume the stack is open source in the OSI sense. The Security Onion repository is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved. Your legal team should confirm what ELv2 permits for your use, including whether you may offer the platform as a managed service to third parties if a partner or your own group will operate it for others. Security Onion Pro is a separate paid edition on 1 to 5 year terms, and the features it adds (OIDC single sign-on for the console, FIPS mode, OS STIG compliance, professional support) are candidates for your requirements list, not defaults. Suricata (GPL-2.0, version 8.0.7 published September 15, 2026) and Zeek (9.0.0, published August 21, 2026) carry their own licenses and should be checked separately.
On the PCI DSS side, PCI DSS v4.0.1 is the only active version, since v4.0 was retired on December 31, 2024. The PCI Security Standards Council ran a request for comments on v4.0.1 from June 3 to July 20, 2026 to begin the next iteration, but it had announced no release date for a new version as of October 2026. Write your requirement 11.5.1 and 11.5.2 evidence against v4.0.1 and avoid designing around any draft. Ask your Qualified Security Assessor or acquirer to confirm which version and which reporting template (ROC or SAQ) applies to your environment, because payment brands, not the Council, decide enforcement and validation timing. Record the version of every engine, rule set and file integrity tool in your evidence pack, with the date you confirmed it.
How DeployOpen scopes and delivers the monitoring build
The sequence moves from a written, fixed scope to a CDE-specific sensor and rule design, a deployment in your own environment, tuned alerting and a set of evidence files your QSA can review. DeployOpen prepares that evidence but does not issue any attestation.
Agree a fixed scope in writing
DeployOpen documents the engagement scope, deliverables and timeline in a written agreement before any work starts. The agreement names the systems in scope, the sites and networks covered, the responsibilities of your team and your QSA, and whether ongoing support is included. The step is complete when both parties have signed the scope and your QSA has seen the planned deliverables.
Review the CDE boundary and critical points
DeployOpen works with your network, security and compliance staff to map the cardholder data environment, its perimeter, the connections into and out of it, and the internal points where a compromise would matter most. This review identifies the traffic that requirement 11.5.1 expects monitored and records any segmentation assumptions that affect sensor placement. The output is a written CDE and monitoring-point inventory that your QSA can compare against your scoping documentation.
Design sensors and detection rules
Based on the inventory, DeployOpen designs the sensor layout, including tap or span points, sensor sizing and whether a Security Onion Distributed design fits your environment. It also defines the Suricata rule sources, the update process for engines and signatures, and the alerting path to your SOC. The design is confirmed when you approve a document that shows where each sensor sits, what traffic it sees and how alerts are routed.
Deploy inside your environment
DeployOpen installs and configures the sensors, manager and search components in your own cloud accounts, data centers or isolated networks, following the approved design. Where your network has no internet access, the installation uses offline media and an airgap update path. The step closes when sensors are capturing traffic at each approved point and a test alert reaches the responsible analysts.
Tune alerts and document decisions
DeployOpen reviews early alert volume with your analysts, then adjusts rules through modification, suppression and threshold settings in the Security Onion Console. Each change is recorded with its reason, the approver and the date, so that alert handling can be shown to an assessor. The step is complete when the agreed tuning baseline is in place and the change log is current.
Prepare evidence for the assessor
DeployOpen assembles the documentation your QSA will ask for, such as the monitoring-point inventory, sensor and rule configuration records, signature update logs, alert samples, and the procedure for reviewing and responding to alerts. Evidence is organized by requirement and mapped to the relevant sub-requirements. DeployOpen does not issue audit reports, attestations or certifications. Your QSA or the applicable assessment body decides whether the evidence supports compliance.
Hand over and support under retainer
DeployOpen hands over runbooks, configuration baselines and training for your operators, and confirms the handover against the written scope. If you choose a retainer, DeployOpen applies signature and engine updates, plans platform upgrades and maintains the evidence set as the environment changes. The retainer scope, response expectations and fees are agreed in writing, and you should confirm them before signing.
How DeployOpen supports PCI DSS intrusion detection
DeployOpen plans, implements, hardens and documents self-hosted open-source intrusion detection inside your own cloud accounts, data centers or air-gapped networks. The work starts with the cardholder data environment boundary and its critical points, so that the sensors, rules and change-detection controls can be evidenced against requirements 11.5.1 and 11.5.2 for your assessor.
How we scope
- We map the CDE perimeter, critical internal points and every network segment that carries cardholder data before selecting sensor locations.
- The written scope lists sensor placement, engines, rule sources, alert routing, file integrity monitoring targets and the evidence to be produced.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and a quote follows directly from that scope.
How we build
- We deploy Suricata, Zeek and Security Onion in the topology the scope defines, including manager, sensor and search nodes where a distributed design is chosen.
- We configure rule loading, tuning and suppression, and set up a documented process for keeping engines, baselines and signatures current.
- We configure file integrity monitoring on the agreed critical files with weekly comparisons, then test that unauthorized changes raise alerts to the right people.
How we hand over
- You receive architecture diagrams, sensor inventory, configuration records, rule update procedures and alert escalation runbooks tied to each requirement.
- We run test events against the perimeter and critical points and document detection results, so your team can repeat the checks.
- Staff training covers alert triage, tuning decisions and the routine evidence an assessor will request, including how the monitoring fits your PCI DSS documentation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering engine and rule updates and sensor maintenance after handover.
- We plan Security Onion and engine upgrades as scheduled changes, with testing before they reach the production CDE.
- We prepare systems, controls and evidence for your assessment. Independent qualified assessors make the compliance determination, and DeployOpen does not issue attestations.
