Service Provider Written Agreements

PCI DSS requires you to maintain written agreements with every third-party service provider (TPSP) that you share account data with, or that could affect the security of cardholder data. Operationally, you must (1) identify in-scope TPSPs, (2) ensure contract language assigns security responsibilities, and (3) retain signed agreements and evidence that the agreements cover the TPSP’s impact on your cardholder data environment (CDE). ¹

Key takeaways:

• Maintain written agreements for all TPSPs that touch account data or can impact cardholder data security. ¹
• Treat this as a scoping control: missed TPSPs become missed attack paths and missed assessor test points.
• Evidence must be retrievable fast: a signed agreement plus an inventory-to-contract mapping is the difference between “we do this” and “we can prove it.”

“Service provider written agreements” sounds like a legal admin task, but PCI DSS treats it as a control that underpins CDE security ownership. Requirement 12.8.2 is narrow and testable: you must maintain written agreements with all TPSPs with which account data is shared or that could affect the security of cardholder data. ¹

For a Compliance Officer, CCO, or GRC lead, the operational challenge is rarely drafting a contract from scratch. The challenge is coverage and proof: knowing which third parties are in scope, confirming the right security obligations are actually in the executed paper, and being able to produce it quickly during assessment. A single “shadow” provider (a chat widget, logging tool, managed firewall, call center, cloud hosting, payment plug-in) can invalidate your story about scope and control ownership.

This page translates the requirement into an execution playbook: who must comply, how to build the TPSP inventory tied to cardholder data flows, what contract terms to insist on, what artifacts to retain, and what assessors typically challenge. References are limited to the PCI SSC materials provided. ²

Requirement overview (PCI DSS 12.8.2)

Plain-English interpretation: If a third party receives account data from you, or can influence the confidentiality, integrity, or availability of cardholder data through systems/services they provide, you must have and maintain a written agreement with that provider. The agreement is your documented mechanism to assign security responsibilities and set enforceable expectations. ¹

Why assessors care: This requirement is an audit anchor for third-party risk in PCI. If the provider relationship exists without an agreement, you cannot credibly show responsibility boundaries for the portion of your environment that provider touches. That turns into findings, scope confusion, and remediation churn.

Regulatory text

PCI DSS 4.0.1 Requirement 12.8.2 states: “Written agreements with TPSPs are maintained as follows: written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of cardholder data.” ¹

What the operator must do: Maintain executed written agreements for every in-scope TPSP, and be able to demonstrate completeness (you did not miss any) and relevance (the agreement corresponds to the TPSP services that interact with account data or affect its security). ¹

Who it applies to

Entity scope

• Merchants and service providers that store, process, or transmit account data.
• Payment processors and other payment ecosystem organizations that use TPSPs in ways that touch account data or the security of cardholder data. ¹

Operational context (what “could affect security” means in practice)

Treat a TPSP as in scope for 12.8.2 if any of the following are true:

• They store/process/transmit account data for you (direct access).
• They provide infrastructure, platforms, security tooling, or administration that can change or expose the CDE (indirect but material influence).
• Their people have privileged access into systems that connect to the CDE (managed services, support, SRE, SOC, etc.).

Common “missed TPSPs” list (use as a scoping checklist):

• Cloud hosting and managed databases
• Managed firewalls/WAF/CDN
• Customer support/call-center tooling where PAN may be discussed or recorded
• Managed endpoint detection/remote support tools
• Log aggregation/SIEM that ingests CDE logs
• E-commerce plugins and payment page components

What you actually need to do (step-by-step)

Step 1: Build the in-scope TPSP population

1. Start with data flow and architecture inputs. Pull cardholder data flow diagrams, payment acceptance channels, and the CDE network diagram.
2. Enumerate third parties by function, not by procurement category. Include IT, Security, Marketing web tags, Support operations, and Finance payment operations.
3. Decide in-scope criteria based on the requirement text. Mark a TPSP “in scope” if account data is shared or the service could affect cardholder data security. ¹
4. Create a TPSP register with fields assessors will test. Minimum fields:
   • Legal entity name
   • Service description
   • Relationship owner (internal)
   • CDE impact statement (“shares account data” / “affects security”)
   • Systems touched and access type (API, admin, network, hosting)
   • Contract identifier + effective date + renewal date
   • Location of executed agreement (repository link)

Operator tip: If your procurement system cannot produce a clean list, build it from accounts payable + SSO app inventory + cloud marketplace subscriptions. Completeness matters more than elegance.

Step 2: Confirm written agreements exist (and are executed)

1. Locate the executed agreement (signed MSA/SOW/order form) for each in-scope TPSP.
2. Verify the agreement covers the actual service in use. A signed MSA without the SOW that defines managed security responsibilities often fails practical testing.
3. Validate the legal entity match. Ensure the contracting entity is the one delivering the service (common issue with parent/subsidiary structures).
4. Record gaps and apply a stopgap. If no agreement exists, create a remediation ticket and interim risk acceptance approved by the right owner, while pushing for execution.

Step 3: Ensure the agreement assigns security responsibilities (contract minimums)

PCI DSS 12.8.2 does not list specific clauses in the excerpt provided, so don’t over-interpret it. What you can operationalize safely: the agreement should clearly define security responsibilities for any area where the TPSP touches account data or can affect the security of cardholder data. ¹

Practical clause checklist (keep it scoped to “responsibilities”):

• Service description and boundaries (what they do / don’t do)
• Access boundaries (what systems/data they may access)
• Security obligations aligned to the service (e.g., secure handling of account data where applicable)
• Notification and cooperation expectations for security incidents that could involve cardholder data
• Right to obtain assurance evidence appropriate to the service risk (for example, compliance attestations or security reports, if your program uses them)

Avoid a common trap: Overstuffing templates with irrelevant “all clauses for all vendors.” Assessors and legal both hate it. Tie obligations to actual CDE impact.

Step 4: Implement governance so agreements stay current

1. Define approval criteria for entering or renewing an in-scope TPSP relationship (who must sign off, what artifacts are required). This matches the best-practice control expectation to define approval criteria and provisioning steps. ¹
2. Embed the check into intake workflows:
   • Procurement intake: flag “touches account data / affects CDE” questions
   • Security architecture review: require TPSP register entry before go-live
   • Change management: new integration triggers TPSP reassessment
3. Set a review cadence for TPSP register completeness and contract validity (renewals, service changes). Define it in your procedure and follow it. ¹
4. Define revocation triggers (termination, service change, non-renewal, unacceptable risk) and ensure access removal is coordinated.

Step 5: Prepare for assessor testing (make evidence one-click)

Assessors typically sample TPSPs. Your goal is to make sampling painless:

• A filtered view: “in-scope TPSPs” with contract links
• For each sampled TPSP: executed agreement + proof it maps to the service and CDE impact statement

Daydream can help here by acting as the system of record for the TPSP register, mapping each third party to the CDE impact rationale and storing pointers to executed agreements so your team can respond to samples quickly without spreadsheet archaeology.

Required evidence and artifacts to retain

Maintain artifacts that prove coverage, execution, and traceability:

Coverage (completeness)

• TPSP register (in-scope flagged) with rationale tied to account data sharing or security impact. ¹
• Source-of-truth inputs: payment data flow diagrams and/or CDE scoping documentation (whatever you already maintain for PCI scoping). ²

Execution (agreements exist)

• Signed MSA/SOW/order form (or equivalent) for each in-scope TPSP. ¹
• Contract metadata: effective date, term, renewal, and repository location.

Traceability (you can prove governance)

• Intake/approval records for new TPSPs and renewals (ticket, workflow approval).
• Review results and exceptions showing authorized decisions and periodic revalidation (aligned to recommended evidence retention). ¹

Common exam/audit questions and hangups

What the assessor asks	What they’re testing	What to show
“List all TPSPs that share account data or can affect cardholder data security.”	Completeness and scoping discipline	TPSP register + scoping rationale per TPSP 1
“Provide written agreements for these sampled TPSPs.”	Agreements exist and are executed	Signed agreement + SOW mapping to service
“How do you ensure new TPSPs don’t bypass this?”	Operationalization	Intake workflow controls, approval criteria, and evidence of use 1
“How do you handle renewals and service changes?”	Ongoing maintenance	Review cadence records; renewal tracking; change triggers

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “TPSP” as only payment processors.
   Fix: Use the broader test: account data shared or could affect cardholder data security, which pulls in cloud, managed security, and support tooling. ¹

2. Mistake: Having an agreement, but it doesn’t match the service.
   Fix: Store the SOW/order form with the MSA and record which systems/services are covered.

3. Mistake: Agreements exist, but nobody can find them during fieldwork.
   Fix: Centralize contract storage and add repository links in the TPSP register. Run an internal “sample test” before the assessor does.

4. Mistake: Shadow IT introduces TPSPs outside procurement.
   Fix: Add TPSP checks to architecture review and change management gates, not just procurement intake.

5. Mistake: No evidence of governance, only policy statements.
   Fix: Retain approvals, reviews, and exceptions showing decisions were authorized and revalidated. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t build your program around hypothetical fines. The operational risk is still concrete: gaps in written agreements create unclear security ownership, weaken incident response expectations with third parties, and routinely surface as PCI assessment findings that trigger remediation work under time pressure. ¹

Practical 30/60/90-day execution plan

Use staged phases without fixed day counts if your contracting cycle is slow. The objective is to reach “assessor-ready” evidence quickly, then mature governance.

First 30 days (Immediate stabilization)

• Stand up the in-scope TPSP register with owners, CDE impact rationale, and contract links. ¹
• Run a gap assessment: TPSPs with no executed agreement, missing SOWs, or unclear legal entities.
• Implement a temporary intake gate: no new TPSP go-live that touches account data or can affect cardholder data security without Security + Legal approval and a tracked contract status. ¹

Days 31–60 (Close the highest-risk gaps)

• Prioritize contract remediation for TPSPs with direct account data exposure and those with privileged access into CDE-adjacent systems.
• Standardize a contract addendum checklist tied to responsibility assignment for CDE-impacting services. Keep it short and service-specific.
• Pilot an internal assessor-style sampling drill: pick a subset of TPSPs and produce agreements + mappings in one working session.

Days 61–90 (Operationalize and make it durable)

• Formalize approval criteria, provisioning steps, review cadence, and revocation triggers in a procedure owned by GRC and executed by Procurement/Security. ¹
• Integrate register updates into:
  • Procurement intake
  • Architecture/security review
  • Change management
• Implement periodic revalidation evidence (review logs and exceptions) so maintenance is provable, not assumed. ¹

Frequently Asked Questions

Does PCI DSS 12.8.2 apply only if the third party stores or processes PAN?

No. It also applies to TPSPs that “could affect the security of cardholder data,” which captures providers with indirect influence over the CDE. ¹

What counts as a “written agreement” for this requirement?

The requirement calls for written agreements to be maintained; in practice, you should retain executed contracts (MSA/SOW/order form) that govern the TPSP services in scope. Keep them signed and retrievable. ¹

If we have a master agreement but each business unit has separate SOWs, what should we retain?

Retain the executed master plus the specific SOW/order form for the services that share account data or affect CDE security. Assessors will test the document that actually defines the service responsibilities. ¹

How do we handle click-through terms for cloud or SaaS tools?

Capture the executed form of the agreement you accepted (for example, the order confirmation and the terms version in effect) and map it in your TPSP register. The key is proof that an agreement exists and covers the service’s CDE impact. ¹

Do we need to renegotiate every contract to be PCI compliant?

Start by ensuring every in-scope TPSP has an executed agreement and that responsibilities for the in-scope service are documented. Only escalate renegotiation where responsibilities are unclear for services that share account data or affect its security. ¹

What’s the fastest way to prepare for a PCI assessor sample request?

Maintain an in-scope TPSP register with direct links to executed agreements and a one-paragraph CDE impact rationale per provider. Run a periodic sampling drill so you can produce evidence on demand. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ³

Footnotes

1. PCI DSS v4.0.1 Requirement 12.8.2

2. PCI DSS v4.0.1

3. Just Published: PCI DSS v4.0.1