Under PCI DSS, whether you're classified as a "merchant" or a "service provider" isn't a branding choice — it determines which requirements apply to you, what your acquiring bank expects from you, and how deep your assessment needs to go. A merchant that accepts, transmits, or stores cardholder data to sell goods or services faces one set of obligations. A service provider — an entity that processes, stores, or transmits cardholder data on behalf of another organization, or that could impact the security of that data — faces a stricter set, including Requirement 12.8 and 12.9 obligations around managing its own downstream vendors. Getting this classification wrong cascades into wrong SAQ types, missed sub-requirements, and audit findings that surface late.
This post breaks down the actual PCI DSS definitions, why they matter operationally, and how two different categories of tooling — Vanta's compliance automation platform and Safeguard's software supply chain security platform — address different parts of the resulting workload.
What Does PCI DSS Actually Mean by "Merchant" and "Service Provider"?
The PCI Security Standards Council defines these terms functionally, not by industry:
- Merchant: an entity that accepts payment cards as payment for goods or services. A merchant's PCI DSS obligations are scoped around the systems that accept, process, or transmit cardholder data at the point of sale or checkout — regardless of transaction volume, though volume determines merchant level (1 through 4) and assessment type (SAQ vs. Report on Compliance).
- Service provider: an entity that is not a payment brand, but is directly involved in processing, storing, or transmitting cardholder data on behalf of another entity — or that provides services that could affect the security of cardholder data, even without directly touching it. This includes payment gateways, hosting providers, managed security providers, and, notably, software vendors whose applications touch the cardholder data environment (CDE).
The important nuance: an organization can be both. A SaaS company selling subscriptions (merchant, for its own transactions) that also processes payments for its customers (service provider, for theirs) inherits both sets of obligations simultaneously. This dual classification is common and frequently underestimated during scoping.
Why Does the Distinction Change What Requirement 6 and Requirement 12.8 Demand?
This is where the definitions stop being administrative and start being technical.
Requirement 6 (develop and maintain secure systems and software) applies to both merchants and service providers, but service providers whose software is embedded in a customer's CDE carry a higher bar — their code, dependencies, and build pipeline become part of someone else's audit scope. Requirement 6.3 (identifying and managing vulnerabilities in bespoke and custom software) and 6.4.3 (managing scripts on payment pages) are exactly the kind of controls that get inherited downstream: if a service provider ships a vulnerable dependency or an unreviewed third-party script, every merchant using that service inherits the exposure.
Requirement 12.8 applies specifically to service providers and merchants who share cardholder data with third parties: maintaining a list of service providers, monitoring their PCI DSS compliance status at least annually, and — as of PCI DSS 4.0 — documenting which requirements are managed by the provider versus the customer via a formal responsibility matrix. Requirement 12.9 requires service providers to acknowledge in writing that they are responsible for the security of cardholder data they possess.
In practice, this means a service provider's own software supply chain — its dependencies, build artifacts, and CI/CD pipeline — is not just an internal engineering concern. It's an inherited compliance obligation for every merchant downstream.
Where Does Compliance Automation Fit — and Where Does It Stop?
Vanta is a trust management platform: it automates evidence collection for compliance frameworks (SOC 2, ISO 27001, HIPAA, PCI DSS, and others) by connecting to cloud infrastructure, HR systems, identity providers, and ticketing tools, then continuously monitoring configuration state against control requirements. For PCI DSS specifically, this kind of platform is well suited to tracking organizational and infrastructure-level controls: access reviews, policy attestations, vendor risk questionnaires, and cloud configuration checks that map to requirements like 7 (access control), 8 (authentication), and 9 (physical security posture as reflected in cloud settings).
What this category of tool is not built to do — and doesn't claim to do as its core function — is generate or verify the software-level artifacts that Requirement 6 and 12.8 increasingly require for service providers: a verifiable software bill of materials (SBOM) for the applications actually touching the CDE, dependency-level vulnerability data tied to specific build artifacts, and provenance attestations proving that what was tested is what was deployed. Evidence collection about whether a scan happened is a different problem than producing the scan and the artifact record in the first place.
Where Is Safeguard's Approach Different — Software Supply Chain Evidence, Not Just Policy Evidence?
Safeguard is built around software supply chain security: SBOM generation, dependency and container vulnerability scanning, SAST/DAST integrated into CI/CD, and build provenance tracking. This maps directly onto the technical half of PCI DSS obligations that fall on service providers:
- Requirement 6.3.2 (maintain an inventory of bespoke/custom software and third-party components to identify and address vulnerabilities) is, in concrete terms, an SBOM requirement. Safeguard generates and maintains that inventory automatically as part of the build pipeline rather than as a point-in-time questionnaire response.
- Requirement 11.3 (internal and external vulnerability scanning) and the underlying need to prioritize remediation by exploitability — not just CVSS score — is handled through Safeguard's dependency and container scanning, which ties findings to the actual artifact shipped, not a generic asset inventory.
- Requirement 12.8.2/12.9 documentation, where a service provider must be able to show which controls it owns, is easier to substantiate when the underlying evidence (scan results, SBOMs, build attestations) is generated automatically and tied to specific releases rather than assembled manually before an assessment.
The concrete, verifiable difference between the two approaches: Vanta's public positioning centers on multi-framework GRC evidence automation across the broader organization, while Safeguard's product surface is specifically software supply chain artifacts — SBOMs, dependency scan results, and build provenance — mapped to the requirements that reference them. These are complementary layers, not identical ones, and organizations classified as PCI DSS service providers typically need both: organizational control evidence and software-level artifact evidence.
Do You Need Both a GRC Platform and a Supply Chain Security Platform?
For most organizations that qualify as PCI DSS service providers — not just merchants — the honest answer is yes, and this is worth stating plainly rather than papering over. A GRC/compliance automation platform is well suited to the organizational and infrastructure control layer: policies, access reviews, vendor questionnaires, and continuous monitoring of cloud configuration. It is not designed to be the source of truth for what's actually running in your CDE at the code and dependency level.
That second layer — proving what software components are in production, whether they carry known vulnerabilities, and whether the build that shipped matches the build that was tested — is where a dedicated software supply chain security tool does work that a general compliance platform doesn't natively perform. Trying to satisfy Requirement 6.3.2 or defend a 12.8 responsibility matrix using manually-updated spreadsheets, rather than generated SBOMs and scan data, is a common gap that shows up in QSA findings for service providers specifically, because their scope includes code shipped to other organizations.
How Safeguard Helps
Safeguard is built for exactly the technical half of the service provider obligation that PCI DSS 4.0 sharpened: proving, with artifact-level evidence, what software is in your CDE-facing pipeline and how it's secured.
- Automated SBOM generation for every build, giving you the component inventory Requirement 6.3.2 requires without manual tracking.
- Dependency and container vulnerability scanning integrated into CI/CD, so findings are tied to the specific artifact and release rather than a periodic point-in-time scan.
- Build provenance and attestation, supporting the kind of evidence a merchant or acquiring bank can ask a service provider to produce under a 12.8 responsibility matrix.
- SAST/DAST integration mapped to Requirement 6.2 and 6.3 secure development obligations, catching issues before they reach production.
If your organization is classified as a PCI DSS service provider — or is dual-classified as both merchant and service provider — pairing organizational compliance automation with Safeguard's software supply chain evidence closes the gap between "we have a policy" and "we can prove what's actually running." Talk to Safeguard about mapping your existing pipeline to the specific Requirement 6 and 12.8 controls your acquiring bank or QSA will ask about next.