What PCI DSS 11.5 intrusion detection means for your CDE
A QSA or a customer has asked how your cardholder data environment detects intrusions and unauthorized file changes, and the answer must point to specific mechanisms, not a description of your log pipeline. Requirement 11.5 asks for two separate capabilities. The first is intrusion detection or prevention (11.5.1): techniques that monitor all traffic at the CDE perimeter and at critical points inside the CDE, alert personnel to suspected compromise, and keep their engines, baselines and signatures current. The second is change detection (11.5.2): a mechanism, such as file integrity monitoring, that alerts on unauthorized changes to critical files and compares those files at least once a week. If you are a service provider, 11.5.1.1 adds a duty to detect, alert on or prevent covert malware communication channels. That sub-requirement became mandatory on 31 March 2025.
The risk being addressed is undetected compromise. An attacker who gets past perimeter controls may sit inside the CDE for weeks, alter a payment application binary, add a persistence mechanism or quietly exfiltrate data over an ordinary-looking channel. Logs from firewalls, servers and applications will often record the activity, but only if someone is looking at the right events at the right time. PCI SSC FAQ 1074 states that log correlation does not replace intrusion detection mechanisms such as IDS and IPS. A SIEM that correlates logs is useful for investigation, but it does not satisfy 11.5.1 on its own. Confirm with your QSA which sensors they expect at each CDE boundary and critical point before you design the architecture.
In practice, three things make this requirement hard. The first is alert tuning: an IDS or IPS with default rulesets will produce either floods of false positives that staff learn to ignore or silence that hides real events, so you need a documented process for reviewing signatures and suppressing noise without disabling detection. The second is baselines. File integrity monitoring only works once you have agreed, documented baselines for the critical files in scope, and every approved change must update them through change management, or the weekly comparison will fail on routine work. The third is coverage. Weekly comparisons must reach every critical file and directory your scope defines, which requires an inventory that many teams do not yet have. Ask your QSA and your technical owners to sign off on that inventory before testing begins.
Which systems and teams fall under intrusion and change detection
Requirement 11.5 applies wherever the cardholder data environment (CDE) meets traffic, critical points and critical files. The cards below show which systems, accounts and parties pull into that work, and which scoping choices change how much monitoring you must build and operate.
The CDE perimeter
Requirement 11.5.1 expects intrusion detection or prevention to watch all traffic at the edge of the CDE. In practice this means the firewall or gateway where in-scope networks meet the rest of the corporate or cloud estate, and every internet or partner path into them. Confirm with a network diagram that every ingress and egress point is listed, because an unmonitored side door is the gap assessors look for first.
Critical points inside the CDE
Beyond the perimeter, 11.5.1 also reaches critical points inside the CDE, such as segments that hold payment databases, authentication services, or payment application servers. Your team decides which internal points are critical, documents the reasoning, and places sensors or host-based detection there. Segmentation depth therefore changes the count: a flat network forces coverage of far more internal points than a tightly segmented one.
Critical files on in-scope systems
Requirement 11.5.2 covers change detection, typically file integrity monitoring, on critical files. Build the list from the system build standards, payment application binaries, configuration files, and logs that protect audit trails. Each in-scope host class needs its own list, and the list must be reviewed when new software is added. Missing files on a single server class are a common finding.
Service provider duties under 11.5.1.1
Requirement 11.5.1.1 applies only to service providers. It asks for IDS or IPS techniques that detect, alert on or prevent covert malware communication channels. If you host, manage or process payment environments for other entities, confirm your status with your acquirer or the payment brands before scoping. Service providers also need to show that this detection covers the customer environments they touch, not only their own network.
Cloud accounts and shared platforms
Cloud accounts that store, process or could affect cardholder data belong in scope, even when the provider runs the underlying hardware. Confirm which accounts, virtual networks and management planes can reach the CDE, and place detection at each boundary you control. Ask your cloud team to document which controls the provider covers and which fall to you, because the shared responsibility split decides who runs the sensors and reviews the alerts.
Third parties with access to in-scope systems
Vendors that remotely support, patch, or administer in-scope systems expand the scope of 11.5 because their sessions cross your perimeter. Map each vendor connection, record the systems it reaches, and confirm that its traffic passes through monitored points. Contracts should require vendors to tell you about changes to those systems so that your file integrity baselines stay accurate.
How an assessor tests intrusion detection and change detection
The assessor first confirms that intrusion detection or prevention sits at the perimeter of the cardholder data environment and at the critical points inside it. They compare the network diagram and data-flow documentation against sensor placement, then check whether every path into and out of the CDE crosses a monitored point. Traffic that bypasses the sensor, such as a management network or a replicated database link, is a common gap. The assessor then triggers or reviews a benign test event and follows it through to the person or queue that receives the alert, looking for evidence that someone acted on it.
- Placement evidence: Current network diagrams marked with each IDS or IPS sensor and the segments it watches.
- Coverage gaps: Traffic paths that avoid every sensor, including VPN, backup and administrative flows.
- Alert routing: Configuration showing where alerts go, such as a SIEM or ticketing queue, and who receives them.
- Response records: Tickets or case notes showing triage of real and test alerts, with timestamps and outcomes.
- Mode settings: Whether sensors detect only or prevent, with the rule actions applied to each.
Before the assessment, confirm that sensor placement matches the current diagram, that alert routing reaches an accountable team, and that you can produce ticket history for a sample period.
Detection is only as good as its rules. Assessors check that the engine, its rulesets and any baselines are updated on a documented schedule and that the update history is traceable. They look for the version in production, the date of the last rule update, and the source of each ruleset. A sensor running a current engine with stale signatures, or rules that were never enabled after installation, fails this test even when the device appears healthy. Assessors may compare the running configuration with the vendor or community sources to confirm that enabled rulesets are the ones claimed.
- Engine version: The version running in production and the process that tracks vendor releases.
- Ruleset sources: Named rulesets, such as Emerging Threats or Abuse.ch when used with OPNsense, and the update schedule for each.
- Update logs: Records showing when rules were pulled and applied, including any failed updates and how they were resolved.
- Enabled rule review: Exported configuration showing which rule categories are enabled or disabled, with a documented reason for each exclusion.
- Baseline tuning: Records of anomaly or threshold baselines and who approved changes to them.
Confirm the update cadence with your team and the vendor documentation before the assessment, since the assessor will ask why a given ruleset is or is not enabled.
For change detection, the assessor first asks which files are critical and why. They expect a documented list covering operating system binaries, configuration files, security tool settings and application code in the CDE, and they check whether that list matches what is actually monitored. They then test the mechanism: the assessor may change a monitored test file and confirm that an alert is raised, identifying who or what made the change. Finally, they review the comparison records to confirm that critical files were compared at least once a week and that unauthorized changes were investigated.
- Critical file list: A documented scope with the rationale for each category and the systems it covers.
- Baseline records: Stored checksums and attributes, with the date of creation and approval for each baseline.
- Weekly comparison evidence: Scan or job logs showing a comparison at least once every seven days across the sample period.
- Alert samples: Examples of alerts for created, modified or deleted files, showing the user or process responsible.
- Disposition records: Tickets showing that each unauthorized change was reviewed, approved or reverted.
Test a change in a non-production monitored file before the assessment, then retain the alert and the ticket as sample evidence.
This focus applies only to service providers. The assessor checks whether intrusion detection techniques look for covert malware communication, meaning command-and-control or data exfiltration traffic that tries to hide inside allowed protocols. The assessor expects the provider to explain which channels it considers in scope, such as outbound DNS, HTTPS to unknown destinations or tunneling protocols, and how the detection logic addresses each. They also check that suspected channels generate alerts that are investigated and that the provider can show the detection working. Since this requirement became mandatory on 31 March 2025, assessments covering that date should be prepared with this evidence in place.
- Threat scope: A documented description of covert channel types the provider monitors and the reasoning behind them.
- Detection logic: Rules, protocol decoders or analytic queries that address each channel type, with their version history.
- Protocol visibility: Logs of DNS, TLS, HTTP and similar transactions that the detection depends on, such as Suricata EVE records.
- Alert and response records: Samples of suspected covert channel alerts and the investigation that followed.
- Test results: Records of simulated or red team traffic used to confirm that detection and alerting function.
Confirm with your team whether the provider's services fall under this requirement, since the assessor will first ask whether the provider's own environment is covered.
Implementing 11.5 step by step
This sequence moves from knowing where cardholder data flows to a working set of sensors, monitored critical files and alerts that reach people who act on them. Each step ends with an output you can show an assessor.
Inventory the CDE perimeter and critical points
Start with the current network and data-flow diagrams and list every boundary where traffic enters or leaves the cardholder data environment, plus internal points such as segment gateways, jump hosts, payment application servers and database tiers. Your network or security team owns this list, and an implementation partner can help cross-check it against live traffic captures. The step is done when each monitored point has a name, a location on the diagram and a named owner, and the list matches the scope you give your assessor.
Deploy IDS or IPS sensors at those points
Place intrusion-detection or intrusion-prevention sensors so that they see all traffic crossing the perimeter and the critical internal points identified in the previous step. For open-source options, OPNsense includes an intrusion detection and prevention system built on Suricata, and Suricata can run as a standalone sensor. Confirm that each sensor sees the traffic you expect by testing with known traffic, and record the placement in the diagrams. The output is a sensor map showing coverage and the engine, ruleset and update schedule for each sensor.
Set up rule and signature maintenance
Requirement 11.5.1 expects the engines, baselines and signatures to stay current, so define who pulls ruleset updates, how often they run, and how a failed update is detected and escalated. Document the rulesets in use, such as the Emerging Threats or Abuse.ch rulesets for OPNsense, and the process for tuning rules that generate false positives. The output is a maintenance procedure with a log of updates that an assessor can sample.
Define critical files and capture baselines
List the critical files, directories and configuration items that matter for the CDE, such as system binaries, payment application executables, security configuration, logging settings and cryptographic key stores. Confirm the list with the system owners and the risk assessment. Then record a baseline of checksums and attributes for those items on known-good systems, using a file integrity monitoring tool such as Wazuh, which stores checksums and attributes and alerts when files change. The output is a documented list of monitored files with their baseline records.
Configure alerts and route them to responders
Connect IDS and file integrity alerts to a log platform and define who receives them, how they are triaged and what severity triggers an incident response. Log correlation does not replace intrusion detection, so keep the sensor alerts as their own feed rather than relying on a summary report. Test the path by generating a controlled change and confirming the alert reaches the responder within the time your procedure sets. The output is a routing matrix and a test record showing that the alert was delivered and acted on.
Schedule weekly critical file comparisons
Requirement 11.5.2 expects critical file comparisons at least once weekly, and real-time monitoring is an option where the tool supports it. Schedule the comparison job, and where the tool supports it, use real-time alerts as a supplement, and confirm the schedule runs without manual intervention. Some teams also use backup verify jobs as a second check, for example Bareos Verify jobs, which compare files against cataloged attributes. The output is a scheduled job record, its run history and a sample of alerts showing unauthorized changes were reviewed.
Add covert channel detection for service providers
If your organization is a service provider, Requirement 11.5.1.1 requires IDS or IPS techniques that detect, alert on or prevent covert malware communication channels, and this has been mandatory since 31 March 2025. Enable the detection rules that cover command-and-control and tunneling traffic on your sensors, and confirm which protocols each sensor inspects. Suricata's EVE JSON output can record protocol transactions such as HTTP, DNS, TLS and SSH, which helps reviewers investigate suspected channels. The output is a documented detection configuration with test results, and a note confirming whether your entity is in scope for this requirement.
Document evidence and review the results
Collect the sensor map, rule maintenance log, baseline records, alert routing matrix, job history and sample alert reviews into one evidence folder mapped to 11.5.1, 11.5.1.1 and 11.5.2. Review the sample with the assessor's likely questions in mind, and confirm which items your QSA will want to see live. The output is a dated evidence pack that the organization owns and that the independent assessor tests during the assessment.
Evidence that passes an 11.5 review
An assessor testing 11.5 looks for proof that intrusion detection and change detection run continuously, alert someone, and get acted on. The cards below cover the artifacts that show this, how each one is produced, and how to keep it current between assessments so the evidence reflects the environment as it is today.
Sensor configuration and rule update records
Keep an export of the IDS/IPS configuration covering which interfaces and network segments are monitored, including the CDE perimeter and each critical internal point. Record the rule sources in use, their versions, and the dates they were last updated. An assessor will check that engines, baselines and signatures are current, so the update history matters as much as the current settings. Schedule a monthly export and attach it to the change record for each rule update, so gaps are visible without a rebuild during the assessment.
Alert samples with response tickets
Assessors usually ask for a sample of alerts and then trace each one to a ticket showing triage, a decision and closure. Pull alerts from the sensor across the review period, including a mix of blocked and alerted events, and link each to the ticket that handled it. Note the analyst, the time to acknowledge, and the outcome, such as a false positive with a tuning change. Store the sample set with the ticket identifiers so the trail survives ticket retention rules.
File integrity baseline and change reports
Document which files, directories and configuration paths are monitored, the baseline captured for each, and who approved the baseline. Change reports should show each created, modified or deleted file with the time, the process or user responsible, and whether a change request covers it. Unexplained changes to critical files are the case 11.5.2 most directly addresses. Review the monitored list whenever a system is added or rebuilt, because a file that was never added to the baseline produces no evidence at all.
Weekly comparison logs
The standard requires critical file comparisons at least once a week, so keep a log for each scheduled comparison showing the run start and end time, the scope compared, and the result. A missing week is a finding, so alert on a job that fails to run, not only on a job that finds changes. If a verification job is used instead of or alongside real-time monitoring, its catalog and verify output can serve as the comparison record. Confirm the retention period for these logs with your assessor before the review.
Documented alert routing
Write down where each alert type goes, who receives it out of hours, how it escalates when unacknowledged, and which system holds the record. Include the path from sensor to log platform to ticketing tool, and name the owner of each link. Assessors test this against actual notifications, so send a test alert through each route and keep the result. Review the routing whenever on-call rotations or tools change, and record the review date in the document itself.
Log correlation is not a substitute
Centralized logs help investigations, but PCI SSC FAQ 1074 is explicit that log correlation does not replace intrusion detection mechanisms. Keep the IDS/IPS sensor output as its own evidence stream, separate from general syslog, so the assessor can see the detection layer on its own. Export EVE JSON alert records to a dedicated store where they can be filtered by alert type and time. Confirm with your QSA how they want the sensor data presented before you build the report.
What intrusion and change detection costs to meet
This table breaks down what meeting Requirement 11.5 costs in money and effort, separating one-time work from recurring work and naming who is paid for each part. Use it to build a quote request, since no price or duration is published for these components and the real figure depends on your CDE size and alert volume.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Sensor or licensing spend | Commercial IDS/IPS or FIM vendor, or none for open-source tools | Licenses usually recur; open-source software carries no license fee | Number of network segments, throughput and whether support is bought; self-hosted open source removes license spend but not hosting or support |
| Hardware and hosting for sensors | Your infrastructure team or cloud account, or a DeployOpen-prepared build | One-time build, then recurring hosting | Traffic volume at the perimeter and critical points, and how many sensors are placed inside the CDE |
| Engineering to tune rules and baselines | Internal engineers or an implementation partner under a fixed-scope agreement | One-time tuning, then recurring tuning after changes | Number of applications and systems, and how often the environment changes |
| FIM baseline and monitored file list | Internal platform team or implementation partner | One-time to define critical files, then recurring review | Count of critical files and directories, and how many systems are in scope |
| Alert triage staffing | Your security operations staff or a managed monitoring provider | Recurring | Alert volume, false positive rate after tuning, and required response hours |
| Weekly file comparison operations | Your operations team, usually automated by the monitoring tool | Recurring | Frequency of comparisons above the weekly minimum and the number of hosts compared |
| Log integration and retention | Your SIEM or log platform team | One-time integration, recurring storage | Volume of EVE JSON or FIM events forwarded and retention period set by your policy |
| Maintenance of engines, signatures and baselines | Internal staff or retainer support from a provider | Recurring | Update cadence of rulesets and how often approved changes refresh FIM baselines |
| External review and assessor sampling | Independent QSA, who tests evidence; your team prepares it | Recurring at each assessment | Number of systems sampled, quality of alert records and change tickets, and how well evidence is organized in advance |
Who owns intrusion detection work and who can help
Your organization owns Requirement 11.5. That means you decide which intrusion detection and change detection mechanisms run, where they sit, who watches their alerts, and how exceptions are handled. Accountability does not transfer to a vendor or partner, even when they build the tooling. The internal team is also responsible for proving that the controls operate day to day, which is the part assessors test most closely.
- Control ownership: Naming an accountable owner for the IDS/IPS and file integrity monitoring, with a documented scope that covers the CDE perimeter and critical points.
- Alert handling: Staff who receive, triage and close alerts, plus the escalation path when a suspected compromise is raised.
- Baseline and signature upkeep: Routine updates to engines, rulesets and file integrity baselines, and approvals for baseline changes.
- Weekly review evidence: Records showing that critical file comparisons ran at least weekly and that results were reviewed.
- Scope inventory: Current network and data-flow diagrams that show which segments and critical files are monitored.
Before engaging anyone, confirm internally who will sign off on the mechanism and who answers the assessor's questions about it.
An implementation partner can design, deploy, configure and document the detection stack in your environment. DeployOpen works this way: it prepares systems and evidence inside your infrastructure, while your organization keeps control of the decisions. A partner does not decide whether your controls satisfy the requirement, and it does not issue any report or attestation. Its output is a working system and the records that show how it was built and operated.
- Deployment work: Installing and hardening an IDS/IPS such as the Suricata engine in OPNsense, and configuring file integrity monitoring with Wazuh or verify jobs in Bareos.
- Evidence preparation: Configuration exports, baseline records, sample alerts and EVE JSON log routing into your log management tools.
- Documentation: Runbooks, data-flow inputs and a description of how each mechanism meets 11.5.1, 11.5.1.1 and 11.5.2.
- Testing support: Controlled tests that confirm alerts fire on simulated changes or traffic, with results handed to your team.
- Operational handover: Training and written procedures so your staff can run the mechanisms after the engagement ends.
Ask any partner to put the scope, deliverables and timelines in writing before work starts, and to state which tasks remain with your staff.
A Qualified Security Assessor is the independent party that assesses your environment against PCI DSS and completes the Report on Compliance. The QSA examines the evidence, interviews staff, observes the mechanisms in operation and decides whether each requirement is met. Only the QSA issues the ROC, and the Attestation of Compliance that accompanies it is signed on the basis of that assessment. Certificates from any other source are not recognized as validation.
- Independent testing: The QSA samples alerts, baselines and weekly comparison records rather than accepting a description of them.
- Report issuance: The ROC and AOC are the only documents that count as validation for PCI DSS purposes.
- Interview and observation: Assessors ask operators how they respond to an intrusion alert and how they investigate a changed critical file.
- Scope confirmation: The QSA agrees the boundary of the CDE before testing begins.
- Independence limits: The same firm cannot design the controls it then assesses without the independence question being raised.
Confirm with your QSA which evidence it will request for 11.5 before you finish building the controls, so the records are collected as the system runs.
Organizations commonly outsource the parts of 11.5 that need specialized skills or staff time they lack, while retaining the parts that define accountability. Outsourcing a task does not outsource the requirement itself. Your organization remains responsible for the result, and the assessor will test the output as if you performed the work.
- Usually outsourced: Initial deployment, rule and baseline tuning, file integrity monitoring configuration, log routing and evidence export.
- Usually retained: Alert triage decisions, incident escalation, approval of baseline changes and the weekly review record.
- Shared or contested: Managed detection services that watch alerts on your behalf, which still need documented responsibilities and evidence of review.
- Never outsourced to the assessor: Design or operation of the controls the same firm later validates.
- Contract terms: The agreement should name who maintains evidence, how long records are kept and who receives alerts.
Review the split with your QSA early so that the outsourced work is reflected correctly in your responsibility matrix.
Common gaps that fail 11.5 and how to close them
Most 11.5 findings are not missing tools. They are tools that run without alert routing, rules that have gone stale, or monitoring that covers too little and cannot be shown to a QSA. The cards below cover the gaps assessors raise most often and the closure action for each, so the evidence matches what the requirement asks for.
IDS deployed without alert routing
An intrusion detection sensor that writes alerts to a local console nobody watches does not meet the requirement to alert personnel to suspected compromises. The assessor will ask who receives alerts, how fast, and what happens next. Close it by sending alerts to a monitored queue or log platform with a named owner, an escalation path, and a sample alert with its response record. Test the route by triggering a benign rule match and confirming the alert arrives.
Rulesets and signatures left stale
Requirement 11.5.1 expects detection engines, baselines and signatures to stay current. A ruleset last updated months ago, or a sensor with updates disabled after a failed upgrade, is an easy finding to miss internally and an easy one for an assessor to find. Close it by setting a documented update schedule for each rule source, recording the version in use, and keeping the update logs as evidence that the schedule runs.
Coverage limited to the perimeter
Monitoring that sees traffic at the internet edge but not at critical points inside the cardholder data environment leaves the requirement only partly met. Assessors check that the monitored points match the CDE boundary in the network diagram. Close it by mapping every CDE entry point and each critical internal segment, then confirming each one has a sensor, a tap or a host agent that reports to the same alerting pipeline.
FIM limited to a few directories
File integrity monitoring that covers only the web root or one configuration folder misses the critical files that an attacker is most likely to change, such as system binaries, cron jobs, authentication settings and payment application configuration. Close it by building the list of critical files from the system inventory and the CDE data flow, then configuring the FIM agent against that list. Keep the list under version control so a reviewer can see what changed and when it was added.
Weekly comparisons not evidenced
Requirement 11.5.2 requires critical file comparisons at least once every week, and many environments run the check without keeping proof. A FIM tool that scans on a schedule still needs scan records that show each weekly run, the files compared, and the result. Close it by setting the comparison schedule explicitly, exporting run history to the evidence store, and checking a sample of weeks before the assessment.
Log correlation mistaken for intrusion detection
A SIEM that correlates firewall and server logs is valuable, but PCI SSC FAQ 1074 is explicit that log correlation does not replace intrusion detection mechanisms such as IDS or IPS. Teams that cite log review as their 11.5.1 control usually receive a finding. Close it by deploying a dedicated IDS or IPS that inspects traffic at the required points, and using the SIEM to consume its alerts rather than to stand in for them.
How long and how much work does 11.5 take, and can we do it ourselves?
Can our in-house team meet requirement 11.5 without an outside partner?
Often yes, if you already run network security monitoring and file integrity tooling and have people who can tune and review them. Requirement 11.5 asks for intrusion detection or prevention at the CDE perimeter and critical points, and a change-detection mechanism with at least weekly comparisons of critical files. Your team owns the controls and the evidence in every case. The questions to settle early are whether anyone can maintain signatures and baselines, who reviews alerts, and whether the QSA will accept your design. Confirm those points with your QSA before you commit.
What drives the effort for intrusion detection and change detection?
The main drivers are the size and number of network segments, the number of critical files and systems in the CDE, and how much of the stack is already instrumented. Effort rises when traffic must be monitored at many points, when baselines must be built from scratch for each host, or when alerts must be routed into an existing log pipeline. It falls when the CDE is small, well segmented and already logged. Ask your team to inventory perimeter and critical-point traffic, list the critical files per system, and identify which hosts have no monitoring today before estimating anything.
What does the work need from our internal team?
Expect ongoing time from people who understand your network and systems, not only a one-off setup. The work includes defining monitored points, deploying sensors or agents, creating file integrity baselines, deciding which files are critical, reviewing alerts and documenting how each alert is handled. Someone must also keep detection rules and baselines current after patches and changes. Name an owner for each of these tasks, and confirm that the owner has time in the calendar before the project starts.
How does an implementation partner fit into a fixed-scope engagement?
DeployOpen works under a written, fixed scope: the agreed deliverables, timelines and responsibilities are set before work begins. In this context, a partner can plan the monitoring design, deploy and configure open-source intrusion detection and file integrity tools inside your own infrastructure, document the configuration, and prepare the evidence the assessment will review. The partner does not own your controls, does not decide your compliance outcome, and does not issue any report or attestation. Only your QSA can assess the environment and sign the Report on Compliance or the relevant Attestation of Compliance.
What should we ask for in a written quote for 11.5 work?
Ask for a list of the systems and network points in scope, the tools to be deployed and their versions, the configuration deliverables, and the evidence each deliverable produces. Request a clear statement of what the partner does, what your team does, and what the QSA will review. Ask how alerts will be handed over, whether training and documentation are included, and what happens if the scope changes. Finally, ask whether ongoing support, rule updates and periodic testing are priced separately as a retainer, since those recur after the initial build.
Which costs are one-time and which recur for 11.5?
The one-time costs usually include design, initial deployment, baseline creation and documentation. Recurring costs include staff time for alert review, keeping intrusion detection signatures and engines current, maintaining file integrity baselines after approved changes, and producing the evidence the QSA samples during each assessment. Licensing for commercial tools, if any, also recurs. Open-source components remove licence fees but not the labor to run them. Ask your quote to separate one-time and recurring items so you can budget for both.
What should we confirm with our QSA before starting 11.5 work?
Confirm which systems the QSA considers in the CDE and at its critical points, and where they expect the perimeter to sit. Ask what evidence they will sample for the intrusion detection and change detection requirements, and how often they expect the weekly file comparisons to be shown. Check whether a customized approach or compensating control is being considered, and what documentation that requires. Agree these points in writing before deployment, because changing the design late usually costs more than settling it early.
How DeployOpen prepares 11.5 controls and evidence
DeployOpen plans, implements and documents self-hosted intrusion detection, intrusion prevention and file integrity monitoring inside your own infrastructure, so the 11.5 controls and their evidence are ready for your assessor. Your organization owns the controls, and only your independent QSA or assessor can validate them.
How we scope
- Confirm which CDE perimeter and critical points need traffic monitoring under 11.5.1 for your environment.
- Identify the critical files and directories that the change-detection mechanism under 11.5.2 must cover.
- Record in the written scope whether 11.5.1.1 applies, since it covers service providers only.
How we build
- Deploy an IDS/IPS engine at the CDE perimeter, configured to alert personnel on suspected compromises.
- Set up file integrity monitoring with baselines, weekly or more frequent comparisons, and alerts on unauthorized changes.
- Establish a schedule for keeping engines, rulesets, signatures and baselines current, with the update process documented.
How we hand over
- Deliver configuration documentation, network placement diagrams and the monitored file list for your assessor.
- Provide sample alert records, FIM comparison logs and change reports that show the controls operating as designed.
- Document the responsibilities, runbooks and alert-response steps your team needs to run 11.5 after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement ends.
- Confirm with your assessor which evidence formats they accept before the assessment window opens.
- Review alert tuning and baseline changes with your team so 11.5 evidence stays current between assessments.
