What happens if you are not PCI DSS compliant, and who imposes it
The PCI Security Standards Council does not penalize businesses that fall short of PCI DSS. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Those programs can bring monetary or operational consequences, so a letter from an acquiring bank or a clause in a card acceptance contract is usually the first place the pressure appears. If you hold such a letter, read it for the brand or acquirer that issued it and the deadline it sets, then confirm with that party exactly what it expects.
The consequences depend on who your acquirer and brands are, and on your merchant or service provider level. Visa, for example, may escalate a merchant that suffers a data compromise to a higher validation level, and a merchant that meets Level 1 criteria in any region is treated as a global Level 1. Your organization owns its controls and carries the responsibility for them. An independent Qualified Security Assessor or Approved Scanning Vendor issues the validation evidence, and a partner can help prepare systems and records but cannot issue that validation. Ask your acquirer which level applies to you and which validation method it accepts before you plan the work.
If you suspect a breach of account data, do not contact the PCI SSC. The council imposes no financial or operational penalties on businesses that are breached, including those that were previously found compliant, and it directs them to the payment brands. Follow the brand-specific procedures to notify the affected brands and also notify law enforcement. Questions about fines after a breach, including whether a hosting provider is liable, go to the card brands or acquiring banks. Many organizations therefore keep a PCI Forensic Investigator on retainer so an investigation can start quickly, provided the PFI's independence requirements remain satisfied, and confirm the brand notification steps in their incident response plan now.
Which consequences the organization can face
PCI DSS consequences rarely come from the PCI Security Standards Council itself. They come from the payment brands, the acquiring bank and the evidence your organization can or cannot produce after an incident. The cards below separate each consequence by who imposes it and what record affects it.
Brand monetary consequences
Each payment brand runs its own compliance program and may levy fines on the acquiring bank, which passes them to the merchant or service provider under its contract. The PCI SSC does not set or collect these amounts. Check your acquirer agreement for how fines are assigned and whether they cover assessment or forensic costs. Keep your current Attestation of Compliance on file, because brands weigh the validation record when they decide.
Operational restrictions on processing
Brands can restrict or suspend an entity's ability to accept or process card transactions when non-compliance or a compromise creates unacceptable risk. These restrictions are imposed through brand and acquirer channels, not by the PCI SSC. Ask your acquirer which operational actions the brands can require and how long a restriction can last. Your validation records and remediation evidence determine how quickly you can show the restriction is no longer needed.
Escalation after a data compromise
After an account data compromise, Visa may escalate a merchant to a higher validation level, which usually means more demanding assessment and reporting. The decision belongs to the brand, and it can follow a breach even when the merchant was previously compliant. Prepare the incident record, forensic findings and remediation plan early, since these documents shape how the brand classifies the merchant.
Global Level 1 treatment
Visa treats a merchant that meets Level 1 criteria in any region as a global Level 1 merchant. An organization that operates in several countries cannot keep a lower level in one region while avoiding the stricter validation elsewhere. Confirm with Visa and your acquirers how your transaction volume in each region is counted before you assume a lower level applies to your whole business.
Revalidation and recurring evidence
After a compromise or lapse, the brands and acquirer may require a new assessment rather than accepting the prior report. The new validation must cover the current scope, including systems added since the last cycle. Ask your QSA how an assessment would treat requirements that were not in place before the incident, and keep quarterly scan and annual testing records current so the new report starts from strong evidence.
Contractual exposure to acquirers
Your merchant agreement or processing contract with the acquiring bank sets how PCI DSS failures are handled, including fines passed through, indemnity, and termination rights. The PCI SSC directs questions about liability and hosting provider fines to the brands and acquiring banks. Review these clauses with counsel before an incident, and confirm which provider contracts allocate PCI responsibilities to your hosting or managed service vendors.
How escalation to a higher validation level works
After a card data compromise, the most direct operational consequence is often a change in the merchant's validation level, and that decision belongs to the payment brand, not the PCI SSC. Visa may escalate a merchant that suffers a data compromise to a higher validation level, and a merchant that meets Level 1 criteria in any region is treated as a global Level 1. For the escalated merchant, the level determines what must be submitted to show compliance, so a move from a lighter validation path to a Level 1 path can change who must assess the environment and how often. Confirm with your acquirer and the relevant brand which level applies to you and the date by which the new submission is due.
Levels are assigned by transaction volume under each brand's rules, and the merchant and service provider level guide in this series explains how that assignment works and what each level must submit. Read that guide before a breach occurs so you know your current level, the validation documents attached to it, and the lead time your acquirer expects. Ask your acquirer in writing how an escalation would be communicated, whether it can be contested, and whether your existing ROC or SAQ would count toward the new level. Those answers determine how much budget and assessor time a sudden escalation would require.
Because the escalation sits with the brand, the PCI SSC cannot reverse or waive it, and a business should not treat its prior compliance record as a shield. Plan for the worst case now by identifying which assessor could be engaged at short notice, how your team would supply evidence of the affected systems, and which independent QSA or consultant you would use for the new assessment. Keep the roles clear: your organization owns its controls, an implementation partner can prepare systems and evidence, and only the independent assessor issues the report that the brand accepts.
What to do when you suspect a card data breach
The sequence routes a suspected account data compromise to the people who can act on it: the affected payment brands and acquirer, law enforcement, and the incident response plan you should already have in place. Each step produces a record you can show later.
Do not contact the PCI SSC
The first rule is to keep the PCI Security Standards Council out of the breach response. The Council does not impose financial or operational penalties after a suspected compromise and directs organizations to their payment brands for next steps. Your output here is an internal note recording that the incident is being routed through brand and acquirer channels, with the time it was identified and the person who made the decision.
Activate the incident response plan
Requirement 12.10.1 expects a documented incident response plan covering roles, communication, containment, business recovery, data backup, legal reporting analysis, coverage of critical components and payment brand procedures. Assign an incident lead, open an incident record and confirm which roles are on call. The output is a named roster and an incident log that shows who was told what and when.
Contain the suspected compromise
Containment means limiting further exposure of account data while preserving evidence. Typical actions include isolating affected systems, revoking credentials that may be exposed, and blocking the paths that were used. Your technical team should record each action, the system it touched and the person who approved it, so that an investigator can reconstruct the timeline. The output is a containment log and a list of systems still under review.
Notify the affected payment brands and acquirer
Follow each brand's own incident procedures to report the suspected compromise to the payment brands whose cards may be involved, and notify your acquiring bank or processor. The brand and acquirer decide what happens next, including whether a forensic investigation is required. Keep a copy of every notice, the contact who received it and the reference number they gave you. The output is a notification record for each brand and acquirer.
Notify law enforcement
Report the suspected breach to law enforcement, as the Council's guidance on suspected compromises directs. Your legal or incident lead should make the report and record the agency, the reporting contact and any case reference. Do not let the report delay containment or brand notification. The output is a documented law enforcement report and a reference number kept with the incident file.
Engage a forensic investigator if the brand requires one
Where a payment brand requires a forensic investigation, it will typically direct you to an approved investigator. If you already hold a PCI Forensic Investigator on retainer, that firm can respond faster, provided its independence requirements remain satisfied. Confirm the engagement terms, scope and access arrangements with your brand and acquirer before work starts. The output is a signed engagement and an investigator who reports to the brand as the brand specifies.
Ask the brand about next steps and liability
Put the questions about fines, validation level changes, liability and whether a hosting or service provider is responsible to the payment brands or your acquirer, not to the PCI SSC. Ask what they expect from you, what they will assess and what written decision you will receive. Your legal and finance leads should review the answers. The output is a written list of brand requirements, deadlines the brand sets, and open liability questions with the person responsible for each.
Should you keep a PCI forensic investigator on retainer?
Organizations that cannot afford to wait for an investigator to be scoped and contracted after a suspected account data compromise often consider a retainer. An entity may keep a PCI Forensic Investigator (PFI) on retainer so the PFI can respond quickly to an incident, provided the PFI Program independence requirements in section 2.3 of the PFI Qualification Requirements stay satisfied. The retainer buys access and readiness, not a finding. Its value depends on how fast your team can hand over systems, logs and staff.
- Speed of engagement: A retainer shortens the time to first contact, but the investigator still needs access to affected systems and records before work can start.
- Independence limits: Confirm with the PFI and the PFI Qualification Requirements that the retainer does not compromise the investigator's independence.
- Recurring fee: A retainer usually carries a standing fee whether or not an incident occurs. Ask what it covers and what is billed separately.
- Evidence readiness: Pre-agree log sources, retention periods and access paths so the PFI can start without delay.
- Brand coordination: Confirm how the PFI will work with the payment brands and acquirer you notify during an incident.
Before signing, ask the PFI for the retainer terms in writing, including response expectations, what triggers a call-out and how independence is documented.
Some organizations never expect to need a forensic investigator on standby and only need one after a suspected compromise. In that case, a retainer adds a recurring cost for limited benefit. Engaging a PFI on a case-by-case basis still requires the organization to notify the affected payment brands and law enforcement first, following brand-specific procedures. The investigator's work then follows the brand's direction rather than a pre-agreed plan.
- Pay per engagement: Costs are tied to the work performed, which suits low-risk environments with stable infrastructure.
- Procurement lead time: Without a standing contract, procurement and scoping can take longer during an incident, so know who signs off.
- Brand direction: Payment brands may direct which investigator is used, so confirm the brand's current process before relying on your own choice.
- Internal preparation: Keep an up-to-date contact list, network diagrams and a documented incident response plan that Requirement 12.10.1 describes.
- Re-evaluation trigger: Revisit the decision after significant changes to the cardholder data environment, new payment channels or a new acquirer.
Ask your acquirer or payment brand whether an investigator must be chosen from a specific list, and confirm the notification steps before any incident occurs.
Organizations that rely on a hosting or processing provider need to determine who holds the relationship with the investigator and who bears the consequences. The PCI SSC directs questions about post-breach liability, including whether a hosting provider is liable for fines, to the payment card brands or acquiring banks. A retainer may be arranged by the merchant, the provider or both, but the contract should state who engages the PFI, who pays and who receives the report. Shared responsibility for evidence must be written down before an incident.
- Contract allocation: Specify in the service agreement who calls the investigator and who pays for the engagement.
- Access to provider logs: Confirm the provider will release logs and environment access to the investigator on a set timeline.
- Shared responsibility matrix: Map which controls the provider operates and which the customer owns, so evidence requests go to the right party.
- Single or multiple retainers: Decide whether one investigator covers both parties, and whether that arrangement preserves the independence the PFI Program requires.
- Liability questions: Route fine and liability questions to your acquirer or the payment brands, not to the PCI SSC.
Request the provider's incident response clauses and responsibility matrix before deciding whether a retainer is needed at all.
How to reduce exposure before a breach or assessment finding
Brand programs and acquirers judge a merchant or service provider on evidence it can produce quickly. The cards below cover the decisions and checks that determine how well an organization can respond to an assessment finding or a suspected card data compromise. DeployOpen prepares systems, controls and evidence, but only an independent QSA or the SAQ process produces a valid AOC, and bringing in a partner does not guarantee any outcome.
Confirm the validation path and level
Start by confirming which validation method applies to your organization and which level the card brands have assigned to you. Brands can escalate an organization after a data compromise, so the level you hold today may not be the level you will be measured against tomorrow. Ask your acquirer in writing which Report on Compliance or Self-Assessment Questionnaire it expects, and record the answer with the scope it assumes. A wrong path discovered during an incident is far harder to correct than one found in planning.
Keep a current, valid AOC
Keep a signed Attestation of Compliance for the current cycle, issued either by an independent Qualified Security Assessor for a ROC or completed by your own authorized staff for an SAQ. Certificates, vendor badges and compliance logos are not accepted as validation, so do not present them to an acquirer as proof. Check the expiry and scope statement on the AOC against your current environment, because a valid AOC for last year's architecture may not cover today's systems.
Close gaps against v4.0.1
Review your controls against PCI DSS v4.0.1, the only active version, and pay particular attention to requirements that became mandatory on 31 March 2025 after being best practices. Many organizations marked these as not applicable in earlier cycles, and assessors now expect evidence for them. Build a gap register with an owner, a remediation date and evidence for each open item. DeployOpen can prepare technical controls and evidence for these gaps under a written scope, but the organization owns the decisions and the assessor determines the result.
Rehearse the incident response plan
Requirement 12.10.1 expects a documented incident response plan that names roles, communication steps for payment brands and acquirers, containment, business recovery, data backup, legal reporting analysis and procedures for each brand. A plan that exists only as a document often fails during a live incident because contact lists are stale and nobody knows who calls the acquirer. Run a tabletop exercise at least once a year, time the notification steps, and confirm that the brand-specific procedures in the plan match what your acquirer currently requires.
Pre-arrange forensic support
Decide before an incident who will investigate it. Some organizations keep a PCI Forensic Investigator on retainer so that a qualified firm can respond quickly, provided the PFI independence requirements stay satisfied. Confirm in writing which forensic firm you would call, how fast it can mobilize, and whether the same firm is also your QSA or consultant, because that overlap can break independence rules. Your retainer scope should name the systems it will examine.
Confirm acquirer contract obligations
Read your merchant agreement or processing contract for the duties it places on you after a suspected compromise, including notification deadlines, cooperation with brand investigations, and who pays for assessments or fines. The PCI SSC directs questions about post-breach penalties and whether a hosting provider is liable for fines to the card brands or your acquiring bank, so those parties are the ones who answer. Ask your acquirer and any hosting or managed service provider to confirm these obligations in writing, and map them to your incident plan.
Who pays for each consequence and who decides
This table shows, for each type of consequence after a PCI DSS compliance failure or card data breach, who imposes it, who typically pays under acquirer contracts, whether it is one-time or recurring, and what reduces it. The PCI SSC is not the decision maker in any row, so confirm payment responsibilities with your acquirer and payment brand contracts before relying on any allocation shown here.
| Consequence | Who imposes or decides | Who usually pays (confirm with acquirer) | One-time or recurring, and what reduces it |
|---|---|---|---|
| Brand compliance program fines or fees | Individual payment brands through their own compliance programs | Usually passed through the acquirer to the merchant or service provider under the merchant agreement | Often recurring while non-compliance continues. Reduced by timely validation and documented remediation |
| Validation level escalation | Payment brands, such as Visa's rule that a merchant may be escalated after a data compromise | The merchant or service provider, through higher validation costs such as a Report on Compliance | Recurring at the higher level until the brand accepts the lower level. Reduced by accurate level assignment and clean prior validation |
| Breach investigation costs | Payment brands direct the investigation, often through a PCI Forensic Investigator | Typically the entity that suffered the compromise, subject to acquirer and brand terms | One-time per incident. Reduced by a tested incident response plan and a pre-agreed forensic investigator |
| Forensic investigator retainers | The entity chooses to contract a PFI, subject to PFI independence rules | The entity that holds the retainer | Recurring retainer fee plus incident work. Reduced by sizing the retainer to actual needs and confirming independence terms |
| Remediation of gaps and rebuilt systems | The entity's own management, guided by brand and acquirer requirements | The entity, including internal staff time, tooling and any consultant or QSA work | One-time for the fix, often recurring for ongoing evidence. Reduced by closing gaps before assessment and keeping evidence current |
| Legal exposure and notifications | Regulators, courts, law enforcement and contractual counterparties, depending on jurisdiction | The entity, unless contracts or insurance shift costs. Ask counsel and insurers to confirm coverage | One-time per incident, with possible ongoing claims. Reduced by prompt notification procedures and documented legal reporting analysis |
Frequently asked questions about PCI DSS non-compliance
Does the PCI SSC fine us if we are not PCI DSS compliant?
No. The PCI Security Standards Council does not run compliance programs or penalize businesses that fall short of PCI DSS. Consequences come from the individual payment brands, which decide which entities must validate and may run their own compliance programs. Those programs can bring monetary or operational consequences, such as fees or restrictions on processing. Your acquirer and the card brands you accept are the parties that set the terms you actually face, so review your merchant or service agreement to see which brand programs apply to you. The PCI SSC's position is set out in PCI SSC FAQ 1015.
Can we be fined after a breach if we were compliant at the time?
The PCI SSC itself imposes no financial or operational penalties on a business that is breached or suspected of an account data compromise, including a business that was previously found compliant. The PCI SSC directs such businesses to contact their individual payment brands about next steps. Whether a brand assesses costs after a compromise depends on that brand's rules and your contracts, so the answer is not determined by your compliance status alone. Ask your acquirer which brand procedures apply and how they treat a validated organization. The relevant guidance is in PCI SSC FAQ 1019.
Should we call the PCI SSC after a suspected card data breach?
No. The PCI SSC asks businesses that suspect an account data breach not to contact it. Instead, follow the brand-specific procedures to notify the affected payment brands, and notify law enforcement. Your acquirer can tell you which brands are affected and what their notification steps require. Prepare these steps before an incident by including payment brand and acquirer communication in your incident response plan, which Requirement 12.10.1 expects to cover roles, communication strategies, containment, recovery and legal reporting analysis. See PCI SSC FAQ 1009 for the official direction.
Is our hosting provider liable for PCI DSS fines?
The PCI SSC does not decide liability. It states that questions about compliance requirements and penalties after a breach, including whether a hosting provider is liable for fines, go to the payment card brands or acquiring banks. In practice, liability is set by the contracts between you, your hosting provider and your acquirer, and by each brand's rules. Review the responsibility matrix and the security terms in your hosting agreement, and confirm which party is responsible for which controls within the cardholder data environment. Ask your hosting provider for its own PCI DSS validation documents, and ask your acquirer how it treats fines passed through a provider. The PCI SSC's answer is in PCI SSC FAQ 1037.
Can a consultant or partner take responsibility for our PCI DSS compliance?
No outside party can take over your compliance obligation. Your organization owns its controls and its validation. A consultant or implementation partner can prepare systems, controls and evidence, and a Qualified Security Assessor or the appropriate validation body issues the Report on Compliance or assessment result that the brands accept. DeployOpen works in this preparatory role and does not issue audit reports, attestations or certifications. Contract accordingly: a written scope should state what the partner delivers, what your team retains, and who signs the Attestation of Compliance. Independence rules also limit what a consultant may do for an entity it later assesses.
What should we confirm with our acquirer first?
Confirm three things before you plan any remediation or respond to an incident: your validation level and required validation method, which payment brand procedures apply to you, and what the acquirer expects you to submit and by when. Ask the acquirer whether a compliance program or escalation applies to your merchant or service provider profile, and what it would do after a suspected compromise. Also ask who you must notify, in what order, and whether a forensic investigator must be engaged. Get the answers in writing, since they determine what you owe and to whom. The acquirer is your primary source for the brand rules that apply to your business.
How DeployOpen works on this
DeployOpen helps organizations get ready for the assessments that determine their standing with payment brands. We plan, build and document the systems and evidence an independent assessor will review, while the organization keeps ownership of its controls and the assessor issues the validation. Nothing in this work is a report, attestation or certificate.
How we scope
- We confirm the cardholder data environment, connected systems and security-impacting components in the written scope before any work starts.
- Scope, deliverables and timelines are agreed in writing, and most engagements are fixed-scope.
- We document which validation path your organization expects to use and which assessor will review the results.
How we build
- We plan, implement and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
- We configure logging, access controls, backups and monitoring so the technical evidence can be produced on demand.
- We test the controls we build, including security testing of applications, APIs and infrastructure where the agreed scope includes it.
How we hand over
- We document system configurations, data flows, policies and procedures in the form your assessor and internal owners need.
- We deliver a written record of what was tested, what was fixed and what remains open, so gaps are visible before the assessment.
- Your organization keeps the controls, the evidence and the decision on whether to submit results to payment brands.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- We can help keep recurring activities and evidence current between assessment cycles, as set out in the scope.
- Questions about breach response, forensic investigator retainers or brand obligations are referred to your payment brands, acquirer or qualified advisers, and we confirm that boundary in writing.
