Service Provider Responsibility Documentation

PCI DSS 4.0.1 Requirement 12.8.5 requires you to keep current documentation that shows, for each third-party service provider (TPSP), which PCI DSS requirements the TPSP manages, which you manage, and which are shared (PCI DSS v4.0.1 Requirement 12.8.5). To operationalize it quickly, build a TPSP-by-requirement responsibility matrix, tie it to contracts and SLAs, and keep evidence that the split is understood, approved, and reviewed.

Key takeaways:

• Maintain a living responsibility matrix per TPSP mapping PCI DSS requirements to “TPSP / Entity / Shared” (PCI DSS v4.0.1 Requirement 12.8.5).
• Align the matrix to contract language, service descriptions, and your PCI scope so it survives audits and staff turnover.
• Treat “shared” as a control design problem: define exact handoffs, evidence, and failure modes.

“Service provider responsibility documentation requirement” sounds like paperwork, but assessors treat it as a control boundary test. If you cannot show who owns which PCI DSS requirements for each TPSP, you create silent gaps: monitoring no one reviews, logging no one retains, access no one approves, and incident actions no one triggers. Requirement 12.8.5 is explicit: maintain information about which PCI DSS requirements are managed by each TPSP, which are managed by you, and which are shared (PCI DSS v4.0.1 Requirement 12.8.5).

This is not limited to “big” outsourcing. It shows up whenever cardholder data environment (CDE) security depends on a third party: managed firewalls, cloud hosting, payment gateways, managed detection and response, call centers, e-commerce platforms, or support tools that can touch PAN. Your goal is simple: an assessor should be able to pick any in-scope TPSP and any relevant PCI DSS requirement, then see a clear owner and a clear evidence path. The fastest way to get there is a responsibility matrix paired with contract hooks and an evidence register.

Regulatory text

Requirement text (excerpt): “Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.” (PCI DSS v4.0.1 Requirement 12.8.5)

What the operator must do

You must maintain up-to-date documentation that, for each TPSP that affects your PCI DSS scope, maps PCI DSS requirement responsibilities across three categories:

• Managed by the TPSP
• Managed by your organization
• Shared (both parties perform parts of the control)

“Maintain” means the documentation exists, is current, and is available for assessment. In practice, assessors will test whether the document matches reality: service descriptions, contracts, and how your team actually operates.

Plain-English interpretation

Keep a written, reviewable record of the security responsibilities you and each TPSP have for PCI DSS. For every relevant requirement, you must be able to answer: “Who does the work, who keeps the evidence, and what is the handoff?” If a responsibility is shared, define the split at the task/evidence level, not at the vague “we both do security” level.

Who it applies to (entity and operational context)

Entities: Merchants, service providers, and payment processors that rely on TPSPs for any function that can impact PCI security controls (PCI DSS v4.0.1 Requirement 12.8.5).

Operational context where this becomes mandatory fast:

• You outsource any CDE security operations (firewalls, IDS/IPS, EDR/MDR, vulnerability scanning, patching).
• You host in cloud/shared infrastructure where the provider owns parts of physical, hypervisor, or platform controls.
• A payment service/provider processes, transmits, or can access PAN, SAD, or systems in scope.
• A third party provides managed authentication, remote support, or admin access into in-scope systems.

Common trigger: Your PCI scope depends on the TPSP’s control performance. If their failure would break your compliance posture, you need responsibility documentation.

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

1) Build the inventory of in-scope TPSPs

Create a list of TPSPs that:

• Store, process, or transmit account data on your behalf, or
• Can impact security of the CDE (for example, administrative access, hosting, network security services)

For each TPSP, capture: service name, business owner, technical owner, systems touched, data types, and whether they have administrative access paths.

2) Define the “PCI-relevant service boundary” per TPSP

Write a short service boundary statement per TPSP that answers:

• What exactly are they providing?
• What systems/components are included?
• What is explicitly out of scope?

This prevents the matrix from becoming a theoretical exercise disconnected from the real service.

3) Create a responsibility matrix (your primary artifact)

Create a matrix with:

• Rows: PCI DSS requirements (at least those relevant to the service)
• Columns: TPSP, Entity, Shared
• Additional fields (strongly recommended): control activity, evidence owner, evidence location, review frequency, escalation/incident trigger, contract reference

Keep it simple enough to maintain, detailed enough to audit.

Practical mapping rules

• Mark TPSP only when they fully perform the control activity and can provide evidence on request.
• Mark Entity when you fully perform the control activity, even if it runs on their platform.
• Mark Shared when there is a handoff (for example: TPSP produces logs; you review them. TPSP patches base OS; you patch applications).

4) Tie the matrix to contracts, SLAs, and service descriptions

Assessors will ask where responsibilities are formalized. For each TPSP, link matrix entries to:

• Contract clauses or addenda describing security duties
• SLAs (availability alone is not enough; focus on security deliverables)
• Right-to-audit or evidence provision language
• Incident notification responsibilities and timelines (document the expectation even if your contract uses different terms)

If contract updates are slow, issue a security responsibilities addendum or written statement of work (SOW) that both parties acknowledge.

5) Operationalize “shared” controls with a RACI-style split

For each “shared” requirement, define:

• Who performs the activity
• Who reviews/approves it
• What evidence is produced
• Where evidence lives
• What happens when evidence is missing or late

Example: If the TPSP retains security logs and you must review alerts, spell out the alert delivery mechanism, retention expectations, and your review workflow.

6) Implement an evidence intake and retention process

Define a repeatable process to collect and retain:

• TPSP attestations or reports you rely on
• Artifacts the TPSP must provide (tickets, logs, access lists, change records, incident reports)
• Your internal reviews of TPSP-provided evidence (sign-offs, meeting minutes, risk acceptances)

Make evidence discoverable. A shared drive with consistent naming can work if ownership and access are controlled.

7) Set a review and change trigger

Update the matrix when:

• The TPSP changes the service (new components, new regions, new subcontractors)
• Your PCI scope changes
• There is an incident, control failure, or material audit finding

Also review on a set cadence appropriate to how often the service changes.

Required evidence and artifacts to retain

Minimum evidence set that typically satisfies 12.8.5 (PCI DSS v4.0.1 Requirement 12.8.5):

• TPSP responsibility matrix per TPSP (dated, versioned)
• Service boundary statement (what the TPSP does that affects PCI scope)
• Contract/SOW/security addendum references mapped to the matrix
• Named control owners on your side (business + technical)
• Shared-control procedures showing handoffs and evidence expectations
• Evidence register showing what you collect from the TPSP and where it is stored
• Review/approval records (internal sign-off that the matrix is accurate and accepted)

If you use Daydream to manage third-party risk and compliance evidence, store the matrix and mapped artifacts per TPSP record so assessors can trace “requirement → owner → evidence” without hunting across tools.

Common exam/audit questions and hangups

Expect questions like:

• “Show me, for this TPSP, which PCI DSS requirements they manage vs you manage.” (PCI DSS v4.0.1 Requirement 12.8.5)
• “Where is this split documented in the contract or SOW?”
• “For shared responsibilities, show the exact handoff and proof both sides perform their part.”
• “How do you keep this updated when the service changes?”
• “Which TPSPs are in scope, and how did you decide?”

Hangups that cause delays:

• A matrix exists, but it’s generic and not tied to the actual service.
• “Shared” is used as a dumping ground without operational detail.
• Evidence is scattered; no one can quickly produce it during the assessment window.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating the TPSP’s compliance package as your responsibility map.
   Fix: Keep your own matrix. TPSP documents can support it, but 12.8.5 is about your maintained information (PCI DSS v4.0.1 Requirement 12.8.5).

2. Mistake: Mapping at too high a level (“TPSP handles security”).
   Fix: Break shared controls into tasks and evidence. If you cannot describe the handoff, you do not yet have a control boundary.

3. Mistake: Forgetting fourth parties (TPSP subcontractors).
   Fix: At minimum, record when a TPSP uses another provider for an in-scope function and reflect who provides evidence to you.

4. Mistake: No change management trigger.
   Fix: Add a contractual notice requirement for material service changes and tie it to an internal update task for the matrix.

5. Mistake: Ownership ambiguity inside your company.
   Fix: Assign an internal control owner per TPSP relationship who is accountable for keeping the matrix current and collecting evidence.

Risk implications (why assessors care)

Responsibility documentation is a control-gap detector. If a requirement is unassigned, you have a compliance break waiting to surface during an incident or assessment. Shared controls are the highest risk because failures hide in handoffs (for example, the TPSP generates logs but nobody reviews them; you assume they patch, they assume you patch). A clean 12.8.5 implementation reduces the chance that your PCI program depends on assumptions.

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Identify in-scope TPSPs and confirm service boundaries.
• Draft a responsibility matrix for the highest-impact TPSPs first (those with CDE hosting, admin access, or payment processing).
• Get internal owners assigned and recorded.
• Gather existing contracts/SOWs and map key clauses to matrix entries.

Next 60 days (make it real, not theoretical)

• For every “shared” requirement, document handoffs, evidence, and escalation paths.
• Create an evidence register and start collecting artifacts from TPSPs you rely on.
• Fill contract gaps with addenda or written confirmations where feasible.

By 90 days (operate it as a program)

• Put the matrix under version control and add a formal review/approval step.
• Add change triggers tied to procurement, architecture, and third-party change notices.
• Run a tabletop audit: pick a TPSP and walk an assessor-style trace from requirement to evidence.

Frequently Asked Questions

Does PCI DSS 12.8.5 require a specific template or format?

No specific template is required, but the documentation must clearly show which PCI DSS requirements are managed by the TPSP, by you, or shared (PCI DSS v4.0.1 Requirement 12.8.5). A matrix format is the fastest to audit.

What counts as “shared” responsibility in practice?

Shared means both parties have control tasks that must happen for the requirement to be met. Document the split at the activity and evidence level, such as “TPSP retains logs; entity reviews alerts and documents follow-up.”

Do we need this for every third party, or only TPSPs in PCI scope?

Focus on TPSPs that store, process, transmit account data, or can affect the security of the CDE. If the third party cannot impact PCI controls, keep them in your broader third-party inventory but do not over-scope the PCI matrix.

Our TPSP refuses to change contract language. Can we still comply?

You can still maintain the responsibility documentation required by 12.8.5 (PCI DSS v4.0.1 Requirement 12.8.5). If contract terms do not support evidence access or clear duties, treat it as a risk and document compensating governance (written acknowledgments, operational evidence sharing, or alternative providers over time).

How detailed does the responsibility mapping need to be?

Detailed enough that an assessor can pick a relevant PCI DSS requirement and see a single accountable party (or a precise shared split) and where evidence comes from. If you cannot explain the handoff in a few sentences, the mapping is too vague.

How do we keep this from becoming shelfware?

Tie updates to real triggers: procurement intake, architectural changes, TPSP release notes, and incident response. Store the matrix with the TPSP record (for example, in Daydream) alongside the evidence register so reviews happen as part of normal third-party oversight.