12.10 Security incident response: requirements and evidence

What PCI DSS 12.10 asks for and why assessors focus on it

If you must prove that your organization has an incident response plan that works, you need more than a document. Requirement 12.10 expects a written plan, proof that it is tested at least every 12 months, named people who can act at any hour, a defined way to handle alerts from security monitoring, and evidence that each incident changes the plan. It also requires a procedure for stored primary account number (PAN) found where it should not be. Assessors treat these as five linked obligations plus that procedure, and they test each one against records from real events and exercises rather than against the text of the plan alone.

A plan on its own does not satisfy the requirement because an assessor will ask how the team behaves when something goes wrong. They look for who declares an incident, who notifies the payment brands and acquirer, how containment and business recovery are sequenced, and whether backups and legal reporting analysis are part of the same flow. They will compare the plan with the alert feeds, on-call rota and tooling you actually run. A plan that names a role nobody holds, a notification path that depends on a departed employee, or a playbook that ignores your cloud accounts will fail even if it reads well. The difficulty is keeping the document, the staffing and the tooling in step as systems and people change.

Before your next assessment, confirm three things: that your test records show the plan was exercised within the last 12 months, that your on-call roster covers every hour with named backups, and that a stored-PAN finding has a documented route from discovery to containment. Ask your QSA which evidence they expect for the lessons-learned loop and for the training frequency your targeted risk analysis sets. Confirm the exact wording of each sub-requirement against the current standard in the PCI SSC standard library rather than relying on summaries, including the 31 March 2025 effective dates for the newer items.

Which systems, teams and third parties 12.10 covers

Requirement 12.10 applies to the parts of the business that can detect, contain and report a payment security incident. The decisions below set who must be on the plan, who must answer at 2 a.m., and which outside parties must be notified. Start from the scope confirmed under Requirement 12.5, then check each group against it.

Cardholder data environment and critical components

The incident response plan must cover the systems in the cardholder data environment and the components that could affect its security. Confirm the list against the current scope inventory, not an older network diagram. Include identity providers, logging platforms, backup systems and jump hosts, because an attacker who reaches them can reach stored account data. Ask the assessor how they will test whether the plan names each critical component and a response path for it.

Security operations and on-call staff

Requirement 12.10.3 requires designated personnel who are available around the clock to respond to incidents. For a merchant, this is often a small internal rota backed by an outsourced monitoring provider. For a service provider, the rota usually covers customer-facing incidents too, so the number of people on call and their escalation paths grow with the customer base. Write down named roles, backups and handover rules, and test that the phone numbers and paging tools still work.

Payment brand and acquirer contacts

The plan must describe how the entity notifies payment brands and its acquirer, and it must include the payment brand procedures that apply to the entity. Service providers and merchants have different contact chains and different reporting triggers, so the contact list belongs in the plan itself. Verify each contact route against the current agreements, because a contact who has changed roles is a common gap found during testing.

Third parties whose alerts reach you

Hosting providers, managed security services, payment gateways and software vendors can generate alerts or incidents that land on your team. Map which third parties send you telemetry, which ones can make changes to in-scope systems, and how each one reports a breach to you. Their notice periods and contact paths belong in the plan. Confirm that each agreement and responsibility matrix under Requirement 12.8 names who acts first.

Service provider duties beyond the merchant scope

A service provider's incident scope is wider. Its customers depend on its response, so the plan must reach customer notification, the payment brands the provider serves and the people who can speak for the provider to customers. Illustratively, a hosted payment platform with many merchant customers needs a response path that reaches every affected customer, while a single merchant with one payment page needs a shorter chain. Confirm which contacts sit inside your organization and which sit with customers or partners.

Stored PAN found outside expected locations

Requirement 12.10.7 requires procedures for stored account data found where it should not be, such as in logs, tickets, email or backups. Scope this to every system where cardholder data could turn up, including support tools and analytics platforms that receive exported records. Name the owner who decides whether the finding is an incident, and confirm that the cleanup steps reach the systems where stray data was discovered.

What the incident response plan must contain

Who must be named in an incident response plan and how are they reached?

The plan must name the roles, their responsibilities and the communication strategy used during an incident, including how the payment brands and acquirers are notified. A useful version lists named functions (incident commander, forensics lead, legal, communications, card operations) with primary and backup contacts, and a notification matrix that states who calls whom, through which channel, and within what time window for each payment brand and acquirer. A generic version lists job titles without contacts, omits the acquirer and brand notification step, and assumes someone will remember to call. Test the contact list at each review, because stale phone numbers are a common failure. Confirm the exact notification obligations with your acquirer and each payment brand's incident procedures, since those parties define them.

What containment steps should an incident response plan document?

The plan must describe how the team stops an incident from spreading and protects the cardholder data environment while investigation continues. A useful version gives decision criteria for isolating a host, disabling an account, blocking a network path or taking a payment system offline, and states who has authority to make that call at night. It also says how containment preserves volatile evidence, so that isolation does not wipe memory or logs needed for forensics. A generic version says "contain the threat" with no decision owner, no preapproved actions and no guidance on evidence, which leads to delays while people seek approval during an outage.

How should business recovery appear in a payment incident response plan?

The plan must cover how systems and payment services return to normal operation after containment, and how that return is verified. A useful version sets recovery priorities for payment-critical services, names the approver who authorizes restoration, and requires a check that restored systems are clean and still meet the configuration and access standards before they rejoin the cardholder data environment. It also links recovery to the disaster recovery site where one exists. A generic version treats recovery as an IT task, with no priorities, no validation step and no link to the business owners who decide when a payment channel can reopen.

What does the plan need to say about data backup during an incident?

The plan must describe how backups are used and protected during an incident, including preserving copies needed for investigation and restoring data without reintroducing compromise. A useful version identifies which backups hold cardholder data, how they are protected from alteration, who may access them during an investigation, and how a restore is checked against a known clean point. It also covers the risk that backups themselves contain stored account data that falls under other requirements. A generic version says backups exist but does not say where they are, whether they are immutable, or how a restore is validated before use.

How does legal reporting analysis fit into the incident response plan?

The plan must include a step where the team analyzes whether the incident triggers legal, regulatory or contractual reporting duties. A useful version assigns this analysis to counsel with a fixed checkpoint early in the response, lists the reporting regimes that may apply to the organization (such as breach notification laws and contractual terms with acquirers), and records the decision and its basis in the incident file. Counsel should confirm which regimes apply to the organization's jurisdictions and customers. A generic version assumes legal will be told later, so notification clocks start without anyone tracking them.

Which critical components must the incident response plan cover?

The plan must address incidents affecting each critical component in the environment, including the systems that store, process or transmit account data and the security controls that protect them. A useful version maps those components from the scope inventory, names the playbook or responsible owner for each class (for example, payment application, card data store, network security device, identity provider) and states how each is isolated and recovered. A generic version describes a single process for all systems, so an incident on an identity provider or firewall receives no more specific handling than a workstation infection.

What payment brand procedures should an incident response plan include?

The plan must include the specific procedures each payment brand requires after a suspected account data compromise, such as preserving evidence, engaging an approved investigator and following brand-defined reporting steps. A useful version lists each brand the organization accepts, the brand's current incident procedure document, the contact route and the internal owner who keeps that document current. Confirm the procedures directly with each brand or your acquirer, because they set and change them. A generic version relies on memory of brand rules, which tends to miss mandatory investigator engagement and evidence preservation steps.

What procedure applies when stored card numbers turn up in unexpected places?

Requirement 12.10.7 expects a documented procedure for the case where stored primary account number data is found where it should not be, such as a log file, a support ticket or a file share. A useful version defines the trigger, the immediate steps to stop further exposure, a decision on whether the data is secured, deleted or moved into the cardholder data environment, and a check that the scope and the data-discovery process are updated. It also states who is told and whether the event counts as a security incident with full response. A generic version treats the discovery as a data cleanup ticket, which leaves the root cause and the other copies unexamined. Confirm the procedure with your assessor, since they test whether it is actually followed.

How often must incident response training happen, and who sets the frequency?

Requirement 12.10.4.1 requires that the frequency of incident response training be set by a targeted risk analysis, rather than a fixed calendar choice. A useful version records the risk analysis that justifies the chosen frequency, covers the roles named in the plan, and tests training against realistic scenarios such as a card skimming alert or a lost laptop with cardholder data. The training record shows who attended and what each person did. A generic version uses an annual slideshow chosen without analysis, which an assessor will question because the frequency was not derived from risk. Your risk analysis, which is documented under the targeted risk analysis requirement, is the source of the number.

How a QSA tests the incident response plan

This table compares what a Qualified Security Assessor (QSA) typically tests for each part of Requirement 12.10, what evidence they request, and where organizations most often fall short. Assessors sample records from the assessment period, so dated records of tests, alerts and plan changes carry more weight than documents written after the fact.

Area	Test approach and evidence requested	Common findings
Written plan and review	Read the current plan for roles, communication (including payment brands and acquirers), containment, recovery, backup and legal reporting. Request version history and review dates.	Plan exists but omits payment brand procedures or has no record of review in the last 12 months.
Yearly test	Ask for the test plan, scenario, participants and results of a tabletop or live exercise, with dates and follow-up actions.	Test dated more than 12 months ago, or a discussion with no documented outcomes.
24/7 personnel and escalation	Review the on-call roster, escalation paths and contact records. Ask staff to walk through an after-hours call.	Roster lists people who have left, or escalation depends on one individual.
Alert intake to incident records	Trace sample alerts from SIEM or monitoring tools into tickets or cases, then to triage notes and closure.	Alerts are reviewed but no incident record or triage decision is kept.
Lessons learned updates	Request post-incident reviews and the plan changes they produced, with dates and approvals.	Reviews are written but the plan is never changed.
Incident response training	Check training records, content and the frequency set by the targeted risk analysis for responders.	Training frequency is undefined or responders are missing from records.
Stored PAN response	Ask for the procedure for PAN found where it is not expected, plus records of any such finds and the response.	Procedure is missing, or it does not say how to remove or secure the data and record the event.

How to implement 12.10 in the order assessors expect

This sequence builds the incident response capability in the order an assessor will test it, so each step produces the evidence the next step depends on. The result is a named owner, a staffed alert path, a tested plan and a documented improvement loop.

Name the incident response owner and roles
Start by appointing one accountable owner for the incident response plan and assigning named roles for incident commander, technical responders, communications, legal and payment brand liaison. Each role needs a deputy so that coverage holds when someone is absent. Confirm that the owner has authority to pull in engineering, executive and external resources during an event. The output is a signed roles sheet that lists each person, their responsibilities and their backup. The step is complete when every role in the plan maps to a named individual.
Map alert sources and build the 24/7 on-call rota
List every security monitoring source that can raise an alert against the cardholder data environment, including the SIEM, endpoint detection, intrusion detection, file integrity monitoring and cloud security tooling. For each source, record who receives the alert, through which channel and at what hours. Build an on-call rota that covers all hours with designated personnel, and confirm that escalation works when the primary responder does not answer. The output is an alert source register and a published rota. Ask your team to test one alert from each source end to end before you consider the step done.
Write the plan with payment brand and acquirer notification paths
Draft the incident response plan to cover the elements the requirement lists, including roles and communication strategies, containment, business recovery, data backup, legal reporting analysis and procedures for each payment brand. Document the notification path to acquirers and payment brands, including who makes each call, the contact details and the information each party expects. Confirm the exact notification obligations in your merchant or service provider agreements and with each payment brand, because the standard does not set them for you. The output is an approved plan and a notification matrix.
Define containment, recovery and backup procedures
Write runbooks for the common incident types that affect the cardholder data environment, such as compromised credentials, malware on a payment system and unauthorized network access. Each runbook should state containment actions, evidence preservation steps, recovery criteria and how backups are used to restore systems. Check that backup scope covers the critical components identified in your scope documentation and that restoration has been tried, not only assumed. The output is a set of runbooks linked from the plan, with each one assigned to a named owner.
Build the stored PAN procedure with a clear owner
Create a dedicated procedure for the case where stored primary account number data turns up somewhere it is not expected, such as a log file, a support ticket, a shared drive or a developer environment. Name one owner who decides on containment, removal, root cause analysis and whether the data flow needs to be re-scoped. Link the procedure to your data discovery tooling and to the scope validation process so that findings feed back into the scope. The output is a short procedure, a finding record template and a worked example labeled as illustrative. The step is complete when a test finding can be traced from detection to closure.
Schedule the yearly test and set training frequency
Set a calendar entry for the plan review and test at least once every 12 months, and choose a test type that exercises the plan, such as a tabletop exercise or a simulated incident. Record who attended, what scenario was used, which gaps appeared and who owns each fix. Separately, use a targeted risk analysis to set how often each role receives incident response training, and document the reasoning. The output is a test report, an attendance record and a training schedule. An assessor will look for evidence from the most recent test, so keep it current.
Set the lessons-learned loop
After each real incident and each test, hold a structured review that records what happened, what worked, what failed and what changes are needed. Track each action to closure with an owner and a due date, then feed updates back into the plan, runbooks, alert rules and training. Ask your team to confirm that the plan changes after each review, because an assessor will compare the plan version history against the review records. The output is a lessons-learned register with closed actions and a dated plan revision log.

Evidence that passes 12.10 and how to keep it current

An assessor testing 12.10 wants to see a plan that exists, has been exercised, and has changed based on what happened. The six artifacts below connect those points, and each needs a named owner who refreshes it between assessments, not in the weeks before one.

Dated and approved incident response plan

The plan must show its current version, approval date, and a change history that links each revision to a review or an incident. Confirm that the plan covers the 12.10.1 elements: roles, payment brand and acquirer notification, containment, recovery, backup, legal reporting analysis, and critical component coverage. Keep the plan in a wiki with version control, so the assessor can compare any two versions. The security lead owns the content, and the approver signs off at least once every 12 months.

Yearly test reports with fixes

Each annual test, whether a tabletop or a simulated incident, needs a written report with the scenario, participants, timings, gaps found, and the tracked fix for each gap. Assessors check that the test was run within the last 12 months and that findings were closed or accepted with a documented decision. Test reports should name who ran the exercise and who was on the call. The incident response lead owns the exercise schedule, and the CISO reviews the findings.

On-call roster and escalation records

The 12.10.3 requirement expects designated personnel available around the clock, so the roster must show named primary and backup responders for every period, with contact methods tested. Keep a log of escalation paths and any handoffs that actually occurred. Assessors often ask for a sample of rota changes against leave and staff turnover. Human resources and the security operations lead share ownership: one updates the roster on every joiner, leaver, or role change.

Alert-to-incident ticket samples

Assessors test 12.10.5 by picking alerts from security monitoring tools and tracing them to a triage decision and, where relevant, an incident record. Keep tickets that show the alert source, timestamp, analyst, classification, and closure reason, including alerts closed as false positives. A case management tool such as DFIR-IRIS can hold these records with an audit trail. The security operations manager owns the sample set and checks monthly that every monitored alert source still feeds the process.

Post-incident reviews and plan changes

Each significant incident should produce a review with root cause, what worked, what failed, and the specific change made to the plan, runbooks, or tooling. The 12.10.6 expectation is that the plan evolves from these lessons, so assessors look for a link between a review finding and a dated revision. Reviews should be closed within a set internal target that the organization documents. The incident response lead owns each review, and the plan owner records the resulting change.

Stored PAN discovery procedure and find records

Under 12.10.7, the procedure must say what happens when cardholder data turns up somewhere it should not be, such as a log file, a shared drive, or a support ticket. Keep a register of past finds with the location, the containment action, the deletion or re-encryption evidence, and the root cause fix. If no finds have occurred, record the scans that searched for them and their results. The data protection lead owns the register, and the system owners confirm each closure.

What meeting 12.10 costs in money and effort

This table compares the main cost components of meeting Requirement 12.10, who is paid for each one, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, because open-source tooling usually removes license spend but not the staffing and testing effort that the requirement demands. No figures are given here, so ask each provider for the scope behind every line.

Cost component	One-time or recurring	What drives it	How to reduce it
Tooling and licenses for case management and automation	Recurring if commercial; low or none for self-hosted open source	Number of users, alert sources, and whether vendor support or hosting is bought; hosting and backup run in your own environment	Choose self-hosted open-source case management and workflow tools, then price only hosting, backup and any support contract
Engineering time to build workflows and integrations	One-time build, then recurring maintenance	Number of SIEM, EDR, ticketing and firewall connections; how many alert types need playbooks; changes to log formats	Start with the highest-volume alert types, document each playbook once, and reuse templates across incident types
Staffing for 24/7 coverage (internal rota or outsourced monitoring)	Recurring, usually the largest line	Hours of coverage required, named personnel for each shift, escalation depth, and whether contractors or a managed monitoring provider cover off-hours	Confirm which alerts need human response at night, tune alerts to cut false positives, and check that outsourced staff have documented access to your playbooks
Yearly incident response plan test, including facilitation	Recurring every 12 months	Scope of the tabletop or live exercise, number of teams involved, whether an outside facilitator runs it, and how many scenarios cover payment brand and acquirer notification	Run the test against the plan you already maintain, rotate scenarios across years, and keep the facilitator brief fixed in writing
Training for incident response personnel	Recurring, with frequency set by your targeted risk analysis	Number of responders, role changes, new tools, and the training frequency your risk analysis supports	Fold training into exercises and tool drills, and record attendance in the same place as the test evidence
Evidence upkeep (plan versions, lessons learned, stored PAN procedure records)	Recurring, with a one-time setup of the repository	Number of incidents, review cycles, and how many documents must show version history and approvals	Keep the plan, playbooks and post-incident reviews in one versioned wiki or knowledge base so each change is recorded once
External review or assessor sampling	Recurring at each assessment	Assessor sample size, number of incidents and tests sampled, and whether a QSA or independent reviewer needs to see live records	Prepare a single evidence index before the assessment, and ask the assessor which artifacts they will sample

Open-source tools that produce 12.10 evidence

Requirement 12.10 is tested by documents, records and proof that the plan works in practice. The four tools below cover the case record, the alert intake path, the plan itself and access to it. None of them makes an organization compliant; each produces artifacts that an assessor can sample, and each still needs people, approvals and a tested process behind it.

DFIR-IRIS case records

DFIR-IRIS keeps each incident as one case with its assets, indicators of compromise, tasks and evidence, and it keeps a full audit trail of who changed what. It can triage alerts from SIEM, EDR and REST sources into cases, build a consolidated investigation timeline, and log evidence with SHA-256 verification and chain of custody. Those records support 12.10.1 and the review of response activity after each event. Confirm which SIEM and EDR products connect to your environment, how the audit trail is retained, and who owns case closure and sign-off.

Shuffle response workflows

Shuffle runs event-driven workflows started by a webhook, a schedule or a manual run, and its app nodes can act on tools such as a SIEM, a ticketing system and a firewall without custom code. For 12.10 this is the mechanism that turns a monitoring alert into a documented, repeatable first response and leaves a run history. Shuffle is licensed under AGPL-3.0-only, so review the obligations with counsel before modifying or offering it to others as a network service. Confirm each connector against the versions in your environment and test containment actions in a non-production setting first.

XWiki plan version history

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and it lets reviewers compare any two versions or roll back to an earlier one. Assessors reviewing the incident response plan and its annual review often ask for proof of what was approved and when, and this history provides that trail. The organization still has to define the review cycle, the approver for each revision and the record of each yearly test. Confirm that your approval workflow, not only the wiki history, is accepted as evidence in your assessment.

BookStack role-based access

BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. That lets you separate readers of the incident response plan, such as the wider operations staff, from editors who maintain the runbooks and contact lists. Limiting edit rights to named owners supports the controlled maintenance the plan needs. Confirm that access reviews, contact details for 24/7 responders and payment brand notification procedures are kept current by a named owner, because BookStack will not enforce that on its own.

Who owns 12.10 and what can be outsourced

Your organization owns requirement 12.10 in full. The incident response plan, the people named in it, and every decision made during a real incident belong to you. A partner can help you draft and rehearse, but the accountable owner of the plan must be someone inside your organization who can commit people and resources at 2 a.m.

The plan itself: Your leadership approves the plan, its roles, its communication strategy and its containment and recovery procedures, including notifying payment brands and acquirers.
The 24/7 roster: You name the designated personnel, maintain their contact details, and confirm they can be reached and act at any hour.
Incident decisions: Your staff decide on containment, legal reporting analysis, and when to escalate. These decisions are recorded as part of your evidence.
Payment brand relationship: Your organization maintains the contacts and procedures for payment brand and acquirer notification, and owns those obligations.
Lessons learned: Your team records what went wrong after each event or test and updates the plan.

Before engaging anyone, confirm with your acquirer and payment brands which notification procedures apply to you.

How much work does 12.10 take, and can we do it ourselves?

Can we write the incident response plan ourselves?

Yes, in most organizations the internal security or operations team writes the plan, because the people who will run it need to own it. The plan must name roles, communication steps (including notifying payment brands and acquirers), containment, business recovery, data backup, legal reporting analysis and procedures for each payment brand. Work through the required elements one at a time and check the draft against the sub-requirements in the PCI SSC SAQ D. Outside help is most useful for reviewing the draft against your environment and for running a realistic tabletop, not for writing a generic document. Confirm with your acquirer which payment brand procedures apply to you before you finalize the plan.

What does the yearly incident response test involve?

Requirement 12.10.2 requires the plan to be reviewed and tested at least once every 12 months. The effort depends on how many systems, teams and payment brand procedures the plan covers. A tabletop exercise with the people who would act during an incident is the most common format, and it produces the evidence an assessor will ask for: the scenario, attendees, decisions made, gaps found and the plan updates that followed. A live simulation takes more preparation and coordination. Ask any provider to define the test format, the evidence it will produce and who records the outcome before you agree on effort.

Must 24/7 incident response staffing be in-house?

No. Requirement 12.10.3 requires designated personnel to be available around the clock, but it does not state that those people must be employees. Organizations usually choose between an internal on-call rota, an outsourced managed detection and response or incident response retainer, or a mix of both. Whichever model you choose, the named personnel, escalation paths and contact methods must be documented and current. Ask a provider how it staffs after-hours alerts, how quickly it escalates to your team and whether its responders are contractually bound to act on your environment.

How long does preparing for 12.10 take?

It depends on your current maturity. An organization that already has a documented incident response process, a monitoring pipeline and regular exercises has far less to do than one starting from a blank page or with no alert triage. The main drivers are the number of in-scope systems, how many teams must act during an incident, whether monitoring alerts already reach a single queue, and how much evidence of past tests exists. Ask a partner to assess your current state against the 12.10 sub-requirements and to propose a timeline based on that assessment, rather than accepting a generic schedule.

What cost drivers should we ask a partner about?

Cost falls into a few components: plan design and documentation, tabletop or live testing, tooling setup and integration, training for responders, and any retained after-hours response. Most of the design and testing cost is one-time, while the annual test, plan review, training refreshes and any retainer recur. Ask for a quote that separates these items and states who performs each task. Ask also which deliverables are fixed, which tools are licensed or self-hosted, what happens if scope grows, and whether ongoing support is a separate retainer. DeployOpen agrees scope and deliverables in writing before work starts, and a quote follows from that written scope.

Does a self-hosted tool satisfy 12.10 on its own?

No. A tool can support the requirement, but it does not satisfy it alone. DFIR-IRIS, for example, can hold each case as one record of assets, indicators of compromise, tasks and evidence with a full audit trail, and it can triage alerts from SIEM, EDR and REST sources. Shuffle can automate parts of the response workflow. XWiki and BookStack can keep the plan under version control and access controls. However, the organization still needs a written plan with the required elements, named personnel, tested procedures and lessons-learned records. Confirm each tool's capabilities against the current documentation before you rely on it in your evidence.

Can a partner sign our PCI DSS compliance report?

No. A partner can prepare systems, the plan, test records and evidence, but only a Qualified Security Assessor can complete a Report on Compliance, and the Attestation of Compliance is issued through PCI SSC templates by the organization and its assessor. Self-Assessment Questionnaires carry their own attestation. Certificates are not recognized as validation. Ask your QSA early which evidence they will request for 12.10, and whether they expect a tabletop exercise, a live test or both, so the implementation partner prepares for that exact review.

How DeployOpen prepares 12.10 incident response evidence

DeployOpen plans, implements and documents self-hosted open-source platforms that support the 12.10 incident response plan inside your own infrastructure. We prepare the systems, workflows and records an assessor will ask to see, while your organization owns the plan, its roles and its decisions.

How we scope

Agree in writing which systems, teams and alert sources fall inside the 12.10 incident response scope before work starts.
Map the security monitoring tools that feed alerts into the incident response process and confirm who receives them around the clock.
Confirm with your QSA which evidence the assessor expects for each 12.10 sub-requirement, including the stored PAN procedure.

How we build

Configure a case management platform so each incident is one record with assets, indicators, tasks and evidence under an audit trail.
Build automated workflows that triage alerts from the SIEM and ticketing tools into cases, with steps your responders approve.
Set up versioned documentation for the incident response plan so every change shows what changed, when and by whom.

How we hand over

Document the configured platforms, runbooks and roles so your team can operate and audit them without DeployOpen involvement.
Support a tabletop exercise or test of the plan and record the results, lessons learned and resulting plan updates for your files.
Deliver an evidence index that maps each 12.10 sub-requirement to the artifact, owner and location that demonstrates it.

How we support

Offer ongoing support, upgrades and continuous testing under a retainer when your team wants help between yearly plan reviews.
Review the incident response configuration after material changes to systems, monitoring tools or payment flows.
Confirm with your assessor and your payment brands that the evidence meets their expectations, because only independent assessors issue validation reports.