The argument
Map TPSP Responsibility Without the Hand-Wave
A useful TPSP responsibility map begins with the exact service consumed, then connects provider, customer, and shared activities to customer-side configuration, contractual commitments, validation coverage, evidence availability, exceptions, and ongoing monitoring.
The field pattern
A provider offers hosting, managed network controls, identity integration, logging, backup, and support. The contract names the product family. The current AOC covers several services. The customer configures accounts, rules, retention, and access. The assessment narrative assigns entire requirements to the provider because no one has decomposed the service into actual activities.
Why it matters
PCI SSC guidance requires customers to manage and oversee TPSP relationships, identify which requirements apply to each party, and monitor TPSP compliance status. If a TPSP performs activities that meet requirements for the customer, the implementation and evidence for those services affect the customer’s assessment.
The goal is not to force every service into a simplistic provider-or-customer box. Shared responsibility is common. The useful artifact makes the seam visible: who configures, who operates, who monitors, who retains evidence, who handles failures, and what happens when service coverage changes.
Questions that expose the Wack
- What exact provider service and deployment model is the customer using?
- Which activities are provider-performed, customer-performed, or shared—and at what configuration boundary?
- What evidence demonstrates each relied-upon activity, and when will it be available?
- Who detects and resolves a gap when the contract, service, validation coverage, or implementation changes?