Intrusion Detection and Prevention

PCI DSS assessors generally don’t fail teams on whether IDS/IPS exists; they fail teams on whether it is placed correctly, monitored consistently, and kept current with evidence that stands up to testing. Requirement 11.5.1 is operational: it expects you to show where traffic is monitored at the CDE perimeter and at critical points in the CDE, how suspected compromise triggers alerts to personnel, and how the detection/prevention engines (including baselines and signatures) remain up to date (PCI DSS v4.0.1 Requirement 11.5.1).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this requirement as a coverage-and-evidence problem. You need a scoped network story (what is the CDE, where are the chokepoints), an operating model (who watches alerts, what counts as “suspected compromise,” what happens next), and a maintenance model (how updates occur, how exceptions are handled, and how you prove it). This page translates the requirement into a concrete build checklist, evidence list, and audit-ready questions so you can operationalize quickly without over-engineering.

Regulatory text

Requirement (excerpt): “Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network as follows: all traffic is monitored at the perimeter of the CDE and at critical points in the CDE, personnel are alerted to suspected compromises, and all intrusion-detection and prevention engines baselines and signatures are kept up to date.” (PCI DSS v4.0.1 Requirement 11.5.1)

What the operator must do:

1. Use IDS and/or IPS techniques appropriate to your architecture (network IDS/IPS, host-based detection, cloud-native equivalents) to detect and/or prevent intrusions.
2. Demonstrate monitoring coverage at:
   • CDE perimeter (ingress/egress points into the CDE), and
   • Critical points in the CDE (high-value internal chokepoints where lateral movement or sensitive system access occurs).
3. Alert personnel when suspected compromise indicators occur (alerts must reach a responsible team, not just land in a console).
4. Maintain currency of IDS/IPS engines, baselines, and signatures (updates and tuning are expected and testable). (PCI DSS v4.0.1 Requirement 11.5.1)

Plain-English interpretation (what “good” looks like)

You pass this control when you can walk an assessor through a simple narrative:

• “Here is our CDE and the traffic paths into, out of, and within it.”
• “Here are the sensors/controls watching those paths, including internal critical points.”
• “Here is how alerts map to on-call humans and tickets.”
• “Here is how we keep signatures/baselines current, and here is evidence from normal operations.” (PCI DSS v4.0.1 Requirement 11.5.1)

A common practical standard: if traffic can reach CDE systems or sensitive management planes without being inspected by an IDS/IPS control (or an equivalent technique), you should assume the requirement is not met until you can justify coverage.

Who it applies to

Entities: Merchants, service providers, and payment processors that store, process, or transmit account data, plus service providers whose systems or personnel can affect CDE security (PCI DSS v4.0.1 Requirement 11.5.1).

Operational context where this becomes real work:

• Hybrid networks (on-prem + cloud) where “perimeter” is not a single firewall.
• Segmented environments where the CDE is separated by internal firewalls; internal “critical points” matter more than the internet edge.
• Third-party managed security (MSSP/SOC) where you must still prove alerting, monitoring, and follow-up with your evidence.

What you actually need to do (step-by-step)

1) Define the monitoring scope: CDE perimeter + critical points

Build a short, assessor-friendly inventory of inspection points:

• Perimeter points: the interfaces where traffic enters/exits the CDE (internet edge to CDE, corporate network to CDE, partner connections to CDE).
• Critical points inside the CDE: pick the places an attacker would traverse or target:
  • segmentation firewalls between CDE zones
  • admin access paths (jump hosts, bastions)
  • database subnets and payment application tiers
  • egress points from CDE to shared services (DNS, authentication, logging)

Deliverable: a one-page “CDE traffic monitoring map” that ties each traffic path to a specific IDS/IPS technique. This is the document assessors ask for when they test “all traffic is monitored.” (PCI DSS v4.0.1 Requirement 11.5.1)

2) Choose the IDS/IPS techniques and place them intentionally

You can satisfy “IDS and/or IPS techniques” with different architectures, but you must prove coverage and monitoring:

• Network IDS/IPS at chokepoints (SPAN/TAP or inline)
• Host-based detection on critical CDE servers where network visibility is limited
• Cloud-native network threat detection where traditional taps don’t exist

Decision rule: if you can’t show the sensor sees the traffic (or the host sees the behavior), it doesn’t count in practice.

3) Define “suspected compromise” and wire alerts to people

Create a short alerting standard for the CDE:

• Which alert categories are in scope (e.g., exploit signatures, C2 indicators, lateral movement patterns, privilege escalation on CDE hosts).
• Routing (SOC queue, on-call rotation, pager, ticketing integration).
• Minimum required fields in an alert record: timestamp, affected asset, detection source, severity, triage owner.

Then test it. Generate a benign test alert (or use a controlled detection rule) and capture evidence that personnel were alerted and triage occurred. The requirement explicitly tests that “personnel are alerted.” (PCI DSS v4.0.1 Requirement 11.5.1)

4) Build the monitoring and follow-up workflow (what auditors really test)

Document the operating loop:

1. Alert generated
2. Triage within your defined SLA (set one you can meet consistently)
3. Case/ticket created
4. Investigation notes
5. Containment/eradication actions (when needed)
6. Closure with rationale

Keep it simple, but make it repeatable. Your strongest evidence is a small sample of real alerts with tickets showing ownership and disposition, not a policy PDF.

Practical tip: if a third party SOC monitors alerts, contractually require access to case records and escalation evidence so you can produce artifacts on demand.

5) Keep engines, baselines, and signatures up to date (and prove it)

Requirement 11.5.1 explicitly includes maintenance of:

• Engines (the software/firmware that runs detection)
• Baselines (normal traffic/behavior profiles used for anomaly detection)
• Signatures (known-bad patterns) (PCI DSS v4.0.1 Requirement 11.5.1)

Operationalize with:

• Update method: automatic where possible; documented manual process where not.
• Change control tie-in: record significant tuning changes and exception approvals.
• Validation: confirm sensors are “green,” receiving traffic, and still forwarding events after updates.

Evidence should show both the configuration and the fact the process is happening in normal operations.

6) Put the control on rails with ownership and reporting

Assign:

• Control owner: typically Security Operations or Network Security
• Compliance owner: GRC validates evidence and readiness
• Reporting cadence: regular check that sensors are up, alerts are triaged, signatures are current

Daydream (as a natural fit): many teams centralize evidence collection by mapping each monitoring point to an artifact checklist (configs, screenshots, ticket samples, update logs) so audits stop being a scramble. Daydream can act as the system of record for “what counts as evidence,” plus who attested to it and when, without relying on tribal knowledge.

Required evidence and artifacts to retain

Use this as your audit evidence checklist for 11.5.1:

• CDE scope and network diagram(s) showing CDE perimeter and internal critical points, with IDS/IPS placement annotations (PCI DSS v4.0.1 Requirement 11.5.1)
• Sensor inventory: device/agent list, locations, covered segments, and data sources forwarded to SIEM/SOC tooling
• Configuration evidence:
  • policy/rule sets (high level)
  • proof sensors are enabled and monitoring relevant interfaces/hosts
• Alerting evidence:
  • sample alerts showing routing to personnel
  • on-call or escalation configuration (where alerts go)
• Operational follow-up:
  • tickets/cases linked to alerts with investigation notes and disposition
  • escalation records for higher-severity events
• Update and currency evidence:
  • signature/baseline update settings
  • change records for major tuning or engine upgrades
  • logs or console screenshots showing last update timestamps and sensor health (PCI DSS v4.0.1 Requirement 11.5.1)
• Exceptions and compensating notes (if any): why a segment can’t be monitored and what alternate technique covers it

Common exam/audit questions and hangups

Expect these, and prepare your “one-screen” answers:

• “Show me ‘all traffic’ at the CDE perimeter is monitored.” They will trace paths. Have the map and be ready to demonstrate telemetry.
• “What are the ‘critical points’ in the CDE, and why did you pick them?” If you can’t justify the points, you’ll look under-scoped.
• “Who is alerted, and how do you know they received it?” Provide routing config and ticket evidence. (PCI DSS v4.0.1 Requirement 11.5.1)
• “Prove signatures/baselines are current.” Show update settings and historical evidence, not a statement of intent. (PCI DSS v4.0.1 Requirement 11.5.1)
• “How do you handle false positives without turning detection off?” Show tuning governance and documented decisions.

Frequent implementation mistakes (and how to avoid them)

1. Only monitoring the internet edge. Fix: treat internal segmentation boundaries and admin paths as “critical points” and document them. (PCI DSS v4.0.1 Requirement 11.5.1)
2. Alerts exist but no one owns triage. Fix: define ownership, escalation, and ticketing; retain samples of real closures.
3. Sensors deployed but not seeing traffic. Fix: validate taps/SPANs, cloud flow sources, and host agents; keep periodic health checks.
4. Signature updates are assumed, not evidenced. Fix: record update configuration and retain console evidence or logs that show currency. (PCI DSS v4.0.1 Requirement 11.5.1)
5. Over-reliance on a third party SOC without evidence rights. Fix: bake evidence access into contracts and runbook expectations.

Enforcement context and risk implications

No public enforcement cases were provided for this specific PCI DSS requirement in the supplied source catalog. Practically, the risk is operational and audit-facing: incomplete monitoring or weak evidence makes it hard to detect intrusion attempts and hard to prove control operation during PCI DSS assessments and follow-up remediation (PCI DSS v4.0.1 Requirement 11.5.1).

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and visibility)

• Confirm CDE boundaries and list all ingress/egress paths into the CDE.
• Identify internal “critical points” and document why each is critical.
• Inventory existing IDS/IPS techniques and gaps against the traffic map.
• Verify alert routing reaches personnel (test alert, capture evidence). (PCI DSS v4.0.1 Requirement 11.5.1)

Next 60 days (close coverage gaps and make evidence repeatable)

• Deploy sensors/agents or enable cloud detections at missing perimeter/critical points.
• Standardize alert categories and severity definitions for “suspected compromise.”
• Implement ticketing linkage for alerts and require investigation notes.
• Set up signature/baseline/engine update procedures and capture “currency” evidence snapshots. (PCI DSS v4.0.1 Requirement 11.5.1)

By 90 days (operate, tune, and become audit-ready)

• Run a tabletop or controlled detection test to validate end-to-end workflow.
• Review false positives and tune rules with change records.
• Package an assessor-ready evidence binder:
  • monitoring map
  • sensor inventory
  • sample alerts + tickets
  • update/currency proof
• In Daydream, map each artifact to the requirement so collection becomes a recurring task, not a one-time scramble.

Frequently Asked Questions

Do we need both IDS and IPS to meet PCI DSS 11.5.1?

No. The requirement allows “intrusion-detection and/or intrusion-prevention techniques,” but you still must monitor CDE perimeter and critical points, alert personnel, and keep engines/baselines/signatures up to date (PCI DSS v4.0.1 Requirement 11.5.1).

What counts as a “critical point” inside the CDE?

A critical point is a place where monitoring materially increases your ability to detect intrusion activity inside the CDE, such as segmentation boundaries, admin access paths, and sensitive tier transitions. Document your rationale and tie it to the traffic paths you identified (PCI DSS v4.0.1 Requirement 11.5.1).

If a third party SOC monitors our IDS alerts, what evidence do we need?

You still need proof that personnel were alerted and that alerts were monitored and resolved, typically via case records, escalations, and closure notes you can access. Put evidence access requirements into the third party contract and operating runbooks.

How do we prove signatures and baselines are “kept up to date”?

Retain configuration showing update settings, plus periodic console screenshots or logs showing last update times and sensor health. Keep change records for major tuning and engine upgrades (PCI DSS v4.0.1 Requirement 11.5.1).

Can host-based detection replace network IDS at the perimeter?

It can contribute, but you must still meet “all traffic is monitored at the perimeter of the CDE” and at critical points, so you need a defensible coverage story. Many teams combine network monitoring at chokepoints with host detection on the most sensitive CDE systems (PCI DSS v4.0.1 Requirement 11.5.1).

What’s the fastest way to get audit-ready if we already have sensors deployed?

Build the monitoring map, confirm alert routing and follow-up tickets exist, and collect currency evidence for engines/baselines/signatures. Most “already deployed” programs fail on documentation and operating evidence, not tooling (PCI DSS v4.0.1 Requirement 11.5.1).