Scope
Who it applies to.
PCI DSS applies to any entity that stores, processes, or transmits cardholder data or sensitive authentication data — and to any entity whose systems could affect the security of the cardholder data environment (CDE). That covers merchants, processors, acquirers, issuers, and service providers alike. The Council itself sets no validation thresholds: the individual payment brands and your acquiring bank assign merchant levels, generally scaled to annual transaction volume, and those levels decide whether you self-assess or undergo an independent assessment.
- Maintain a service-provider inventory (Req. 12.8.1)
- Requirement 12.8.1 expects a current list of every third-party service provider (TPSP) you share account data with, or that could affect the security of that data, together with a description of the service each one performs. That list is the foundation for the rest of Requirement 12.8 — you cannot diligence, contract with, or monitor a provider you have never written down.
- Written agreements & acknowledgement (Req. 12.8.2)
- Requirement 12.8.2 expects written agreements with those providers, including each provider’s acknowledgement that it is responsible for the security of account data it holds or handles on your behalf, or that it could otherwise affect. The Council is clear that a provider’s Attestation of Compliance is not a substitute: evidence of their compliance does not satisfy the agreement obligation.
- Due diligence and ongoing monitoring (Req. 12.8.3 & 12.8.4)
- Requirement 12.8.3 expects a defined engagement process with proper due diligence before you take a provider on. Requirement 12.8.4 expects a program that checks each provider’s PCI DSS compliance status at least once every 12 months, so that a lapse actually surfaces and you can decide whether the change in status warrants a change in the relationship.
- Responsibility matrix (Req. 12.8.5 & 12.9)
- Requirement 12.8.5 expects documentation of which PCI DSS requirements each provider manages, which you manage, and which are shared between you. Requirement 12.9 is the mirror image on the provider side: providers acknowledge that responsibility to customers in writing (12.9.1) and, on request, supply the status and responsibility information their customers need for 12.8.4 and 12.8.5 (12.9.2).
- Scope reduction through segmentation (Req. 11.4.5)
- Segmentation is not itself mandatory, but isolating the cardholder data environment from the rest of your network is the main lever for shrinking what an assessment covers. Where you rely on it, Requirement 11.4.5 expects penetration testing of those segmentation controls at least once every 12 months and after any change to them, confirming the CDE stays isolated from out-of-scope systems.
- Annual validation — ROC, SAQ, AOC
- Validation is normally annual. Larger entities produce a Report on Compliance (ROC); eligible smaller ones complete a Self-Assessment Questionnaire (SAQ) matched to how they accept payments — SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC, or D. Either route ends in an Attestation of Compliance (AOC). SAQ D for Service Providers is the only SAQ open to SAQ-eligible service providers.
The vendor & sub-processor obligation
What it puts on you.
PCI DSS requires you to manage third-party service providers (TPSPs) that can affect cardholder data security: maintain a list, get written acknowledgements, and monitor their compliance status — one obligation per provider in scope.
How self-hosting addresses it
Remove the third party, remove the burden.
Reducing or removing the outside parties that touch cardholder data shrinks the service-provider population you must track and contractually bind under PCI DSS.
How FileFerret applies
PCI DSS scope follows cardholder data, and an on-premises appliance does not remove that scope — it changes who sits inside it. Running document search inside your own network means no outside provider joins the Requirement 12.8 population for those files. Any system that touches or could affect cardholder data stays in your own CDE and must still be assessed. See how it’s built →
Full, current text is maintained at the official source: PCI DSS — PCI Security Standards Council.
Enforcement
Who enforces it, and how.
PCI DSS is not a law, and the PCI Security Standards Council does not enforce it. The Council writes and maintains the standard; the individual payment brands run their own compliance programs, and the obligation reaches you contractually, through the merchant agreement you sign with an acquiring bank. Penalties follow the same chain: a card brand assesses a fine against the acquirer, and the acquirer passes it down to the merchant. Some states do reference the standard in statute — Nevada requires businesses that accept payment cards to comply with it.
Common questions
Questions firms ask.
Does using a PCI DSS compliant provider make us compliant?
No. The Council is explicit that engaging a compliant third-party service provider neither makes you compliant nor removes your own responsibility. Their attestation is evidence you collect under Requirement 12.8.4, not a replacement for your own validation. You still have to scope your environment, hold the written agreements Requirement 12.8.2 calls for, and document who owns which requirement under 12.8.5.
How do you actually reduce PCI DSS scope?
Scope covers the cardholder data environment plus any system that could affect its security, so reduction means both storing less and connecting less. Not retaining cardholder data at all is the strongest move; segmenting the CDE from the rest of the network is next. If you claim segmentation, Requirement 11.4.5 expects annual penetration testing to demonstrate those controls genuinely isolate the CDE.
Which version applies now, and what changed on 31 March 2025?
PCI DSS v4.0.1 is the current version; v4.0 was retired at the end of 2024 and v3.2.1 in March 2024. Of the 64 new requirements introduced in v4.0, 51 were future-dated as best practices and became mandatory on 31 March 2025. Assessments from that date forward treat them as full requirements, so the phase-in period has closed.