PCI DSS incident response automation with Shuffle

How PCI DSS incident response automation fits the 12.10 requirements

Automation with Shuffle can execute and document much of an incident response, but PCI DSS requirement 12.10 still requires a written plan, trained people and tested procedures. A payments team preparing for a PCI DSS v4.0.1 assessment needs to show all three. Requirement 12.10 has eight sub-requirements (12.10.1 to 12.10.7, plus 12.10.4.1). They cover the plan and its contents, yearly review and testing, 24/7 designated personnel, training with a frequency set by a targeted risk analysis, monitoring of security alerts, lessons learned, and procedures for stored primary account number (PAN) found where it is not expected. Shuffle can carry out the monitoring and triage steps, but the plan that defines them, the roles behind them and the test results are evidence the assessor will ask for by name.

The Payment Card Industry Security Standards Council (PCI SSC) owns the standard but does not enforce it. The individual payment brands decide which entities must validate and run any enforcement programs, so the first decision is to confirm with your acquirer or the relevant brands what they expect from your Report on Compliance or Self-Assessment Questionnaire. PCI DSS v4.0.1 is the only active version, since v4.0 was retired on 31 December 2024. Several v4.x requirements, including the 12.10 items that became mandatory on 31 March 2025, are now in force. Confirm your assessment year and template against the PCI Data Security Standard page before you scope the work.

Map each sub-requirement to an owner before you build any playbook. For example, the 12.10.3 coverage needs a named on-call rota that a Shuffle workflow can page, while 12.10.2 needs a dated test record of the plan itself. Playbooks for alerts from intrusion detection, change detection and payment page monitoring can produce timestamped case records and evidence, which supports 12.10.5 and 12.10.6. Ask your implementation partner which sub-requirements their playbooks cover and which remain manual procedures, and keep that split in the plan as written evidence.

Mapping PCI DSS 12.10 requirements to automated playbook functions

This table pairs each PCI DSS 12.10 requirement in scope for automation with what the function must do and how to configure it in Shuffle and the detection stack. Read each row as a design question: what evidence the assessor will ask for, and which part is automated versus kept as a human procedure. Requirements 12.10.4.1 and 12.10.7 became mandatory on 31 March 2025, so they belong in the current design rather than a future backlog.

Requirement	What the function must do	How to configure it in Shuffle and the detection stack
12.10.1 Incident response plan	Keep a documented plan covering roles, communication (including payment brands and acquirers), containment, recovery, backup, legal reporting analysis and payment brand procedures.	Store the plan as the reference for playbook names and owners. Build a notification workflow that opens a case, lists the contacts from the plan and records each notice sent. Legal reporting analysis stays a human decision with a recorded checkpoint.
12.10.2 Annual review and test	Review and test the plan at least once every 12 months.	Schedule tabletop runs of key playbooks in a non-production Shuffle instance using replayed alerts. Keep run history and the reviewer sign-off with the plan version.
12.10.3 24/7 designated personnel	Make designated people available around the clock to respond to alerts.	Route high-severity Wazuh and Suricata alerts through Shuffle to an on-call channel with escalation timers. Confirm the paging tool and the rotation roster with your own operations team.
12.10.4.1 Training frequency	Set training frequency from a targeted risk analysis for the people who respond.	Use playbook changes and tabletop results as inputs to the risk analysis. Shuffle does not set training frequency; record the schedule and attendance in your learning system.
12.10.5 Monitoring alerts from IDS, change detection and payment page monitoring	Monitor security alerts from intrusion detection, change-detection and payment page monitoring, and respond to them.	Ingest Suricata and Wazuh file integrity alerts, plus payment page monitoring alerts from your chosen tool, into Shuffle triggers. Enrich with asset owner and scope tags, then open a case for each alert that reaches the defined threshold. Confirm which payment page tool sends alerts and in what format.
12.10.6 Lessons learned	Update the incident response plan and procedures after incidents based on lessons learned.	Export case timelines, playbook run results and timing gaps into a review record. Require a human change to the plan version before playbook changes are promoted.
12.10.7 Stored PAN found where not expected	Define procedures for responding when stored account data is found where it is not expected. Mandatory since 31 March 2025.	Run data discovery or scan results through a Shuffle workflow that tags the asset, isolates the location per approved steps and opens a case. Deletion or isolation of systems should require an approval step. Confirm the discovery tool and its output fields with your assessor-facing documentation.

Which alerts Shuffle playbooks should handle first

Start with the three alert sources that most directly show a threat to the cardholder data environment (CDE): intrusion detection alerts from Suricata or Wazuh, file and configuration change alerts from Wazuh agents, and payment page monitoring events. Each gets its own playbook, because each needs a different first enrichment step. For intrusion detection, a playbook should look up the source and destination against threat intelligence, check whether the host sits inside the CDE scope you have documented, and pull the related Wazuh alerts for the same host. For change detection, the playbook should compare the changed file or configuration with the approved change record before anyone is paged. For payment page monitoring, the first question is whether the script or resource that changed is on the approved inventory. Confirm with your monitoring vendor exactly which fields their events carry, since the playbook can only enrich what arrives.

Put a human approval gate in front of any action that touches a system in the CDE. Isolating a host, blocking an IP at a firewall that protects payment flows, or disabling a checkout script can stop card acceptance, so these steps should pause and request approval from a named role, such as the on-call incident commander, with the alert context attached. Read-only enrichment can run without a gate. Shuffle's workflow editor and its app authentication settings let you restrict who can run each workflow, so decide before go-live who holds approval rights and who may edit the playbooks themselves. Each run should write an audit record of its trigger, each action taken, each approval and its approver, and the outcome. Keep those records in your case system, because they support the incident evidence that 12.10.1 expects your plan to address.

Two operational points affect cost and continuity. Shuffle licenses on app runs, which are actions that execute in a workflow, so noisy detection rules that fire thousands of enrichment actions will raise the bill, and tuning alerts before automating them is cheaper than automating noise. Confirm the current licensing terms in writing. Also, Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER value. The Shuffle configuration documentation warns that losing or changing this value breaks every saved app authentication, so store it in your secrets vault, back it up under the same controls as the database, and test a restore before you rely on it.

Which open-source platforms fit each part of the response chain

A PCI DSS response chain runs from sensors to a playbook to a documented record. The platforms below cover different links in that chain, and none of them is a complete answer on its own. Confirm each fit against your cardholder data environment, your logging volumes and the staff who will run the playbooks.

Shuffle for orchestration

Shuffle is the automation layer that runs triage, enrichment and response playbooks, and it is licensed under AGPL-3.0. Its documented deployment options include a single server with Docker Compose, distributed Docker Swarm, a hybrid model with a local Orborus, and Kubernetes with Helm charts. For a 24/7 response capability, check which option gives you more than one Orborus node so workflows keep running if one fails. Review the AGPL-3.0 obligations with counsel before you modify the code and offer it to others.

Wazuh for host and PCI alerts

Wazuh combines an indexer, a server, a dashboard and endpoint agents, and it is distributed under GPL-2.0. Its dashboard includes prebuilt views for PCI DSS, and agentless syslog collection can cover firewalls and other devices that cannot run an agent. Confirm that your in-scope systems can run agents, and that the alert volumes and retention you need fit the indexer sizing. Vulnerability detection can run from an offline repository if your network has no internet access.

Suricata for intrusion detection

Suricata is a network intrusion detection and prevention engine developed by the Open Information Security Foundation under GPL-2.0. It fits the sensor role for alerts from intrusion detection, so the playbook can receive network events for the cardholder data environment. Placement matters: a sensor must see traffic that crosses the CDE boundary, and encrypted sessions limit what signature matching can see. Decide whether prevention mode is acceptable on these segments before a playbook is allowed to act on its alerts.

Zeek for network context

Zeek is a network analysis framework distributed under a BSD-style license from the Regents of the University of California. It records connection, protocol and file activity as logs, which gives responders context for an alert, such as which host talked to a payment service and when. Zeek does not block traffic by itself, so pair it with a detection engine if you need signatures. Confirm the log retention you need for PCI DSS investigations before you size storage.

Security Onion as a bundled option

Security Onion bundles Suricata, Zeek, osquery and the Elastic stack into one platform for monitoring and log management, under the Elastic License 2.0. A bundle reduces the number of components your team must build and patch, but it also sets the versions and the data model you work with. Elastic License 2.0 restricts some uses, including offering the software as a managed service to others, so confirm the license terms against your delivery model. Check how its alerts reach Shuffle before you choose it over separate components.

Case tools to confirm

The record of each PCI DSS incident needs a case system that holds alerts, actions, evidence and lessons learned, and the case tool must be checked before you commit to it. Several open-source case tools are built on OpenSearch or similar stores, but licensing and maintenance status change, so verify each candidate against the current license file and release history. Confirm that the case tool can export a timeline your assessor can read, and that its data store is backed up with the rest of the response evidence.

Choosing a Shuffle deployment for a card data environment

A single server deployment uses Docker Compose on one host, which Shuffle documents as its simplest architecture. It suits a small team that needs a working playbook engine quickly and can accept that one host failure stops automation. Because every component sits on one machine, the placement of that machine defines your segmentation boundary.

Availability: One server means no built-in redundancy. Playbooks that respond to alerts from payment page monitoring stop until the host is restored, so treat this model as a starting point rather than a 24/7 control.
Segmentation: Place the host in a dedicated security zone outside the cardholder data environment (CDE), with only the ports needed to reach agents, sensors and ticketing tools open.
Credential handling: Saved app credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, so back up that value securely and record where it is held.
Scale limits: Worker capacity is bounded by one machine, which matters when several workflows fire during a single incident.
Upgrade path: Confirm with the vendor how a move from Compose to Swarm or Kubernetes is handled before you go live.

Before approving this model, confirm with your QSA how the Shuffle host, its OpenSearch store and its network paths are scoped in your PCI DSS assessment.

Evidence assessors and payment brands ask for, and where it comes from

This table maps each piece of incident response evidence an assessor typically samples to the component that produces it and what the reader should confirm before the assessment. Assessors review the Report on Compliance or the SAQ with its Attestation of Compliance, not a certificate, so the records below need to be complete, dated and traceable to the plan. Shuffle and Wazuh generate much of the operational evidence, but the plan, roster and training records remain organizational documents.

Evidence item	Which component produces it	What to confirm
Written incident response plan (12.10.1)	Organization documents, reviewed against Shuffle playbooks	Plan covers roles, payment brand and acquirer notification, containment, recovery and backup
Annual review and test records (12.10.2)	Tabletop exercise reports and Shuffle test workflow runs	Dated within the last 12 months and linked to plan version changes
24/7 designated personnel roster (12.10.3)	HR or on-call schedule, Shuffle user and role assignments	Named coverage for every hour, with escalation paths that match playbook approvals
Training records (12.10.4 and 12.10.4.1)	Learning management records, training matrix	Frequency set by the targeted risk analysis, with the analysis itself on file
Alert monitoring coverage (12.10.5)	Wazuh alerts, Shuffle trigger logs, payment page monitoring alerts	Which intrusion detection, change detection and payment page signals reach a case
Playbook run history	Shuffle workflow execution records in OpenSearch	Retention period, export method and who can view executions
Wazuh PCI DSS dashboard views	Wazuh dashboard prebuilt compliance views	Which requirement views are mapped to the environment and how gaps are tracked
Lessons-learned records (12.10.6)	Post-incident review documents, updated playbooks and plan revisions	Each significant incident has a review and a traceable change
Stored PAN discovery procedure (12.10.7)	Written procedure, discovery scan results, Shuffle response playbook	Scan scope covers unexpected locations and the response steps are tested

What automation alone cannot satisfy in 12.10

Requirement 12.10 asks for a plan, people, decisions and evidence, and Shuffle can only execute the parts that are written down and tested. The cards below cover the gaps that stay with the organization and its assessor, because an automated run on its own does not prove the plan works.

The plan and its roles

Requirement 12.10.1 expects a written incident response plan with named roles, communication strategies, containment, business recovery, backup and legal reporting analysis. A playbook can carry out steps, but it cannot decide who owns the incident or who speaks to the acquirer. Check that every automated step traces back to a documented role and that the plan covers the critical components in scope.

24/7 staffing decisions

Requirement 12.10.3 needs designated personnel available around the clock. Automation can page the on-call person and open a case, but it cannot make that person available or decide who covers a holiday. Confirm the escalation path when the primary responder does not acknowledge an alert, and document who is authorized to approve containment at night.

Legal and brand notification judgment

Requirement 12.10.1 calls for notifying payment brands and acquirers and for analyzing legal reporting obligations. Whether an event is reportable depends on facts a workflow cannot assess, such as the data involved and the contract terms. Use Shuffle to gather evidence and draft notices, but keep the decision with counsel and the relationship owner, and record who made it.

Customized approach documentation

If the organization meets a requirement through the customized approach, it must document how the stated objective is met, which the defined approach does not require. An automated playbook is an implementation detail, not that documentation. Ask the assessor early whether the customized approach applies, and keep the objective, the risk analysis and the monitoring evidence in a document owned by a person.

Annual test and tabletop exercise

Requirement 12.10.2 requires the plan to be reviewed and tested at least once every 12 months. A workflow that ran successfully against a test alert shows the connector works, but not that people follow the plan under pressure. Schedule a tabletop exercise that includes the decision points automation skips, and record the lessons learned that feed plan updates.

Assessor validation

A Qualified Security Assessor or the organization's own assessor validates the plan, the staffing and the test records against the requirements, and the result is documented on PCI SSC templates. Automated run logs are useful evidence but do not replace the assessor's review. Ask which records the assessor will sample and keep them in a form the assessor can read without the platform running.

Questions buyers ask before hiring help with PCI DSS response automation

What drives the cost of automating PCI DSS incident response with Shuffle?

The cost depends mostly on how many integrations you connect, how many playbooks you build, how many approval gates you need and what environment the platform runs in. Each integration means building or adapting Shuffle apps, which are built from OpenAPI specifications or written in Python with the Shuffle app SDK, and each one must be tested and kept working as the connected tools change. Playbooks that touch the cardholder data environment usually need more review than enrichment-only playbooks. Ask any partner for a quote that lists integrations, playbooks, approval points and deployment target separately, and state which costs are one-time (design, build, testing) and which recur (maintenance, upgrades, retained support).

Can our security team build these PCI DSS playbooks in-house?

Often yes, if you have engineers who can write Shuffle apps and workflows and who understand your payment flows, but the work is more than installing software. The platform runs as a server with an OpenSearch document database and separate Orborus runtime nodes, so someone must own the installation, high availability design and credential handling. Shuffle encrypts saved app credentials with the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks every saved app authentication, so key custody needs a documented owner. Compare the internal staff hours against the playbook backlog, and ask a partner to split the scope into what they build and what your team operates afterward.

How long does a PCI DSS response automation rollout take?

Duration follows from the scope you agree in writing: the number of alert sources, playbooks, integrations and approval steps, plus the deployment model you choose. No fixed timeline applies across environments, so ask for a phased plan with a named milestone for each playbook and a test gate before production. A reasonable first phase usually covers the alert sources that feed your incident response plan, such as intrusion detection, change detection and payment page monitoring, followed by the playbooks that need approvals. Ask the partner to state assumptions about access to your tools, change windows and sign-off, because delays in those areas move the schedule more than the build itself.

What do the security and payments teams need to provide?

Both teams own decisions that the automation cannot make for them. Security must confirm which alerts are in scope, what containment steps are allowed without a human, and who approves destructive actions. Payments and fraud teams must confirm which systems in the cardholder data environment can be touched, how payment brand and acquirer notification works in your plan, and which steps need a business owner present. PCI DSS 12.10.1 expects the incident response plan to cover roles, communication with payment brands and acquirers, and containment, so those people should review playbooks before they go live. Request a RACI-style list of who approves each playbook in the written scope.

How do Shuffle app runs affect licensing and cost planning?

Shuffle licenses its paid tiers on app runs, which means actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Shuffle says all features are available in the open-source edition, while paid tiers differ in feature limits, scaling and support, and since v2.1.1 those limits are actively enforced. For planning, model how many actions your alert volume will trigger each month, because enrichment-heavy playbooks run more actions per alert. Confirm current terms with Shuffle directly, since pricing details can change.

Does automating incident response change the PCI DSS assessment scope?

Automation does not remove systems from scope, and it does not replace the assessment. PCI DSS applies to entities that store, process or transmit cardholder data or could affect the security of the cardholder data environment, and the SOAR platform itself can become a system that touches that environment because it holds credentials and connects to payment tools. Treat the Shuffle server, its OpenSearch store and its worker nodes as in-scope components until your QSA or assessor decides otherwise. A Qualified Security Assessor or the entity's own assessment process determines scope, and PCI SSC accepts only ROC or SAQ documentation with an Attestation of Compliance, not certificates. Ask your partner to document the data flows and credential storage so the assessor can review them.

Who supports the automation after go-live, and what needs upkeep?

Support after launch has three parts: keeping integrations working as connected tools change, upgrading Shuffle and its components, and reviewing playbooks at the cadence your incident response plan requires. PCI DSS 12.10.2 requires the plan to be reviewed and tested at least once every 12 months, and 12.10.3 requires designated personnel available 24/7, so playbooks need an owner who can respond outside business hours. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask whether the quote includes a retainer and what response expectations it sets.

How DeployOpen scopes and delivers PCI DSS response automation

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For PCI DSS incident response, that means a written scope covering your alert sources, playbooks and evidence records, delivered and handed over in your environment, with the compliance evidence prepared for your assessor rather than an audit opinion from us.

How we scope

Agree in writing which alert sources feed Shuffle, such as intrusion detection, change detection and payment page monitoring.
Map each playbook to the 12.10 sub-requirements it supports, and confirm with your QSA which evidence they expect.
Confirm the systems, cloud accounts or air-gapped networks where Shuffle, Orborus workers and OpenSearch will run.

How we build

Build playbooks with approval gates for actions that touch payment systems, such as isolating a host or disabling an account.
Configure credential storage with AES-256 encryption, and document the SHUFFLE_ENCRYPTION_MODIFIER secret and its backup procedure.
Test each workflow against replayed or simulated alerts before it runs against production sources.

How we hand over

Document each playbook, its triggers, its approval steps and the audit trail it writes to case records.
Deliver runbooks for the 24/7 on-call path so designated personnel know how alerts reach them and how to act.
Provide the incident response plan artifacts and test records your team needs for the annual 12-month review.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Confirm with DeployOpen during scoping which upgrade and patch cadence your team will own after handover.

Security automation for PCI DSS incident response