Shared Responsibility and Third-Party Risk: Service Providers, Sub‑processors, and ICT Vendors

1. Why Third-Party Risk Matters in PCI DSS

In PCI DSS, you cannot outsource responsibility, only some of the work.

From the perspective of today (early 2026):

• PCI DSS 4.0 has been in effect since 2022 and fully replaces 3.2.1.
• PCI DSS 4.0.1 (released 2024) is the latest maintenance update; it does not change the core idea: the merchant (or service provider) that accepts card payments remains ultimately responsible, even when using third parties.

Key idea:

If your company stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), or you can impact the security of the cardholder data environment (CDE), then:

• You are in PCI scope, and
• Your vendors and sub‑processors that touch or can affect the CDE are also in scope.

This module connects that idea to:

• Service providers under PCI DSS
• Shared responsibility in cloud and managed services
• Contracts (DPAs, security addenda, flow‑down clauses) that manage third‑party PCI risk.

Keep in mind:

• Outsourcing to a “PCI compliant” provider does not remove your own PCI obligations.
• PCI DSS is not a law, but contracts, card‑brand rules, and sometimes regulators treat it like a de facto standard of care.

2. Who Counts as a PCI DSS Service Provider?

PCI SSC defines a service provider (under PCI DSS 4.0/4.0.1) broadly. It is:

> A business entity, other than a payment brand or acquiring bank, that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity, or that can impact the security of that data or the CDE.

For ICT companies, you are likely a PCI service provider if you:

• Host or store card data (e.g., IaaS, PaaS, SaaS platforms that contain CHD)
• Provide managed security services for systems in the CDE (e.g., MSSP, SOC monitoring, managed firewalls)
• Provide payment gateways, tokenization, or fraud tools that see PANs
• Provide remote administration of in‑scope systems (e.g., database admin, OS patching, network management)

You are probably not a PCI service provider if you:

• Provide services that cannot reasonably impact the CDE (e.g., generic HR system, marketing website with no payment function)
• Provide hardware only, with no management, no remote access, and no CHD present (though your products can still influence PCI controls at the customer).

Nuance:

Even if you never see CHD directly, if you can affect the security of systems that store/process/transmit CHD (for example, you manage the hypervisor or network for a CDE), PCI DSS will still treat you as a service provider in scope.

3. Classify These ICT Vendors

For each scenario, decide: PCI service provider in scope? Yes or No? Then compare with the explanation.

1. Cloud IaaS provider that hosts virtual machines where a merchant runs its e‑commerce application and database containing CHD. The provider manages hypervisors and physical network.

• Your answer: Yes / No
• Explanation: This is Yes. Even if the cloud provider never sees raw CHD, it controls infrastructure that can impact the CDE.

1. Email marketing platform used only for newsletters, with no payment links or CHD imported.

• Your answer: Yes / No
• Explanation: Typically No, because it does not process, store, transmit CHD and cannot reasonably impact the CDE (assuming no deep integration or access).

1. Payment gateway / PSP that receives card data directly from the merchant’s checkout page via API and creates tokens.

• Your answer: Yes / No
• Explanation: Clearly Yes. It processes and transmits CHD on behalf of the merchant.

1. Managed security service provider (MSSP) monitoring logs and managing firewalls for a segment that includes the CDE.

• Your answer: Yes / No
• Explanation: Yes. It can affect security controls protecting the CDE.

1. Printer maintenance company that occasionally services office printers, but never touches systems in the CDE and has no network access.

• Your answer: Yes / No
• Explanation: Usually No, if there is truly no access to CDE systems or networks.

Reflect: In your own environment (or a hypothetical one), which vendors would clearly be PCI service providers, and which would not?

4. Shared Responsibility: You Can Share Tasks, Not Accountability

In PCI DSS, shared responsibility is similar in spirit to cloud security shared responsibility models:

• Customer (merchant / service provider): Ultimately responsible for ensuring that all applicable PCI DSS requirements are met for their CDE.
• Third‑Party Service Provider (TPSP): Responsible for the PCI DSS controls it has contractually agreed to manage, and for maintaining its own compliance where in scope.

PCI DSS 4.0/4.0.1 emphasizes that:

• Using a TPSP can reduce your scope (fewer systems you directly control), but
• It does not eliminate your PCI obligations.

Critical points for merchants and ICT vendors:

• You must understand and document the shared responsibility model: Which controls are handled by you, and which by the TPSP?
• You must monitor your TPSPs (e.g., get their Attestation of Compliance (AOC), review reports, verify they are performing agreed controls).
• If a TPSP fails a control, card brands and acquirers still look to the merchant and, where applicable, to the primary service provider.

Think of it like this diagram (text‑based):

```text

[Customer] ---------------------------

• Own policies

• Application security

• User access

• Some network controls

[Service Provider] -------------------

• Data center / cloud infra

• Some network / platform controls

• Certain logging & monitoring

Both sides must be secure for overall PCI compliance.

```

5. Cloud & Managed Services: Concrete Shared Responsibility Examples

Example 1: Public Cloud IaaS

A merchant runs its card‑processing application on a large public cloud.

Cloud provider typically responsible for:

• Physical security of data centers
• Hypervisor security
• Core network infrastructure
• Some logging of infrastructure events

Merchant responsible for:

• OS hardening and patching of its VMs (unless using managed OS)
• Application security (code, APIs, config)
• Database security and encryption keys (unless using provider KMS with shared model)
• Access control and IAM for its accounts
• PCI‑specific documentation and evidence (policies, risk assessments)

Contract impact:

• Merchant should ensure the cloud provider acknowledges PCI responsibilities (even if they don’t sign a full PCI addendum, they should at least publish PCI compliance documentation).
• Shared responsibility matrix should be explicit (e.g., in a security addendum or reference architecture).

---

Example 2: Managed Payment Page (Hosted Payment Page)

A SaaS PSP hosts the payment page; the merchant’s website redirects customers to the PSP.

PSP responsible for:

• Capturing and transmitting CHD
• Tokenization (if provided)
• Securing the payment page and its backend

Merchant responsible for:

• Ensuring their own website does not capture CHD before redirect
• Securing the integration (e.g., avoiding malicious scripts that could skim card data)
• Validating that the PSP is PCI DSS compliant and monitoring that status

Result:

• Merchant’s PCI scope is reduced (they may qualify for simpler SAQ types), but they still must validate their PSP and secure their own environment.

6. Quick Check: Does Outsourcing Remove Your PCI Duties?

Test your understanding of the core principle.

7. TPSP Obligations & Monitoring Under PCI DSS 4.0/4.0.1

PCI DSS 4.0/4.0.1 includes specific expectations for Third‑Party Service Providers (TPSPs) and the entities that use them.

Typical TPSP obligations (high level):

• Maintain PCI DSS compliance for in‑scope services and environments.
• Provide evidence of compliance (e.g., AOC, relevant parts of the ROC, or SAQ D‑Service Provider) to customers or their acquirers.
• Clearly document which PCI requirements they cover (e.g., via a Responsibility Matrix or “Shared Responsibility Model”).
• Support customer assessments (within reasonable limits) – e.g., security questionnaires, limited audits, or third‑party assurance reports (SOC 2, ISO/IEC 27001).

Customer (merchant or higher‑tier service provider) monitoring duties:

• Due diligence before onboarding the TPSP (e.g., check AOC, reputation, technical capabilities).
• Ongoing monitoring, such as:
• Annual confirmation of PCI DSS compliance status
• Reviewing updated AOCs or certifications
• Following up on known incidents or major changes
• Documenting that monitoring (e.g., vendor risk management records).

In practice, these duties are implemented through contracts:

• Security addenda
• PCI‑specific clauses in MSAs
• Vendor risk management procedures and SLAs.

8. Contract Walkthrough: Assigning PCI Responsibilities

Imagine you are drafting a contract between:

• Company A: An online merchant
• Company B: A cloud‑based payment gateway (PCI DSS‑validated service provider)

Your task: For each item, decide who should be responsible, or if it should be shared. Then compare with the suggested allocation.

1. Maintaining PCI DSS compliance for the payment gateway infrastructure

• Your answer: Merchant / Gateway / Shared
• Suggested: Gateway (Company B), with the merchant obligated to verify this.

1. Ensuring that the merchant website does not collect card data before redirecting to the gateway

• Your answer: Merchant / Gateway / Shared
• Suggested: Merchant (Company A), because that is their environment.

1. Incident notification if the gateway detects a breach affecting transaction data

• Your answer: Merchant / Gateway / Shared
• Suggested: Gateway must notify; both must cooperate and notify acquirers/brands/regulators as required.

1. Providing annual evidence of PCI DSS compliance (AOC) to the merchant

• Your answer: Merchant / Gateway / Shared
• Suggested: Gateway provides; Merchant is responsible for requesting and reviewing.

1. Maintaining secure integration (API keys, webhooks, TLS settings)

• Your answer: Merchant / Gateway / Shared
• Suggested: Shared. Gateway provides secure options and documentation; merchant configures and uses them correctly.

Reflect: How would you capture these allocations in a responsibility matrix attached to the contract?

9. Legal Tools: DPAs, Security Addenda, and Flow‑Down Clauses

To manage PCI‑related third‑party risk, ICT contracts typically use three main mechanisms:

1. Data Processing Agreements (DPAs)

• Required under laws like EU/EEA GDPR, UK GDPR, and similar frameworks when processing personal data.
• For card data, DPAs:
• Define roles: controller vs. processor (or joint controllers)
• Set rules for sub‑processors (who the service provider may use)
• Specify security measures, often referencing PCI DSS as a baseline

2. Security Addenda / Information Security Schedules

• Attachments to the main contract or DPA that:
• Explicitly require the vendor to maintain PCI DSS compliance for in‑scope services
• Reference PCI DSS 4.0/4.0.1 and other frameworks (e.g., ISO/IEC 27001)
• Define incident response, reporting timelines, and cooperation duties
• Include a shared responsibility matrix listing which PCI controls are handled by whom

3. Flow‑Down Clauses

• When you are a service provider and use sub‑processors or sub‑vendors (e.g., underlying cloud, SMS provider, logging platform):
• Your contract with your customer requires you to meet PCI DSS.
• Flow‑down clauses ensure that your sub‑processors are bound to equivalent PCI and security obligations.

Flow‑down clauses usually cover:

• Requirement to maintain PCI DSS compliance where applicable
• Right to obtain evidence of compliance (AOC, certifications)
• Breach notification obligations
• Sub‑processing rules (e.g., prior approval or notification, list of sub‑processors)

This way, PCI obligations are propagated down the chain: from card brands → acquirers → merchants → service providers → sub‑processors.

10. Quiz: Identifying Key Contract Clauses

Choose the most appropriate clause to manage this risk.

11. Flashcards: Core Terms & Concepts

Flip through these cards to reinforce key ideas.

12. Mini Drafting Exercise: Build a PCI Clause

Try drafting a short PCI‑related clause for a contract between a merchant and a PCI service provider. Use this simple pattern:

1. Obligation to maintain PCI DSS compliance
2. Evidence of compliance
3. Incident notification

Write your own version, then compare with the sample.

Your draft (mentally or on paper):

• …

Sample clause (for study, not legal advice):

> Service Provider shall maintain compliance with the Payment Card Industry Data Security Standard (PCI DSS), version 4.0 or any successor version mandated by the Card Brands, for all Services that store, process, transmit, or can impact the security of cardholder data. Upon Customer’s reasonable request, Service Provider shall provide current evidence of such compliance, including its Attestation of Compliance (AOC) and any relevant summary of its Report on Compliance (ROC). Service Provider shall notify Customer without undue delay, and in any event within [X] hours, upon becoming aware of any actual or suspected Security Incident affecting cardholder data or systems within the scope of the Services, and shall cooperate with Customer, its acquirer, and the Card Brands in any required investigation or remediation.

Reflect: How would you adapt this clause if you are the service provider and you rely on sub‑processors? Which parts would you turn into flow‑down obligations?