Service Provider Inventory

PCI DSS 4.0.1 Requirement 12.8.1 requires you to maintain a current inventory of all third-party service providers (TPSPs) that either receive account data or could affect the security of account data, and to document what service each provider performs (PCI DSS v4.0.1 Requirement 12.8.1). To operationalize it, define inclusion criteria tied to PCI scope, assign ownership, build a centralized register with required fields, and run a recurring reconciliation and review workflow with retained evidence.

Key takeaways:

• Inventory must include TPSPs that touch account data and TPSPs that can impact its security, even if they never see card data (PCI DSS v4.0.1 Requirement 12.8.1).
• Auditors will test completeness and currency; you need a repeatable method to discover, approve, update, and offboard providers, not just a spreadsheet.
• Evidence matters: retain the change history, review sign-offs, and the sources you used to validate completeness.

“Service provider inventory” sounds simple until you hit the two hard parts assessors test: completeness and defensibility. PCI DSS 4.0.1 Requirement 12.8.1 is not asking for a list of “vendors.” It is asking for a list of third-party service providers (TPSPs) specifically tied to account data and the systems that protect it (PCI DSS v4.0.1 Requirement 12.8.1). That pulls in obvious providers like payment gateways and card personalization, but also less obvious ones like managed firewall services, e-commerce hosting, call center platforms, support tools, and cloud providers that host or administer systems within scope.

For a CCO, GRC lead, or Compliance Officer, the goal is operational speed: you need a register that maps cleanly to PCI scoping, can be updated as the business buys tools, and produces audit-ready evidence without a quarterly scramble. This page gives you requirement-level guidance: how to define what belongs in the inventory, how to build the workflow around it, what artifacts to retain, and what tends to fail in PCI assessments. Where automation helps, tools like Daydream can keep intake, approvals, and review evidence in one place so your inventory stays current without relying on memory.

Regulatory text

PCI DSS 4.0.1 Requirement 12.8.1 states: “A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description of each of the services provided.” (PCI DSS v4.0.1 Requirement 12.8.1)

Operator interpretation: you must (1) identify every TPSP that either receives account data or can impact the security of account data, (2) record each TPSP in an inventory, and (3) include a description of what the TPSP does. “Maintained” implies the list is kept current through an operating process, not assembled once before an assessment (PCI DSS v4.0.1 Requirement 12.8.1).

Plain-English interpretation (what the requirement really expects)

You need a living register of third parties that matter to PCI. The register must answer, quickly and consistently:

• Who are the TPSPs?
• Why are they in scope? (account data shared vs. security impact)
• What service do they provide? (enough detail to support scoping and downstream due diligence)

A strong implementation ties the inventory to procurement and IT change so new TPSPs cannot be introduced without being captured, described, and assigned an owner.

Who it applies to

Entities: Merchants, service providers, and payment processors that store, process, or transmit account data (PCI DSS v4.0.1 Requirement 12.8.1).
Operational context: Any environment where third parties provide services connected to payment processing, cardholder data environment (CDE) components, or the security controls protecting account data (PCI DSS v4.0.1 Requirement 12.8.1).

Practical scope: what must be included

Include TPSPs in either category below (PCI DSS v4.0.1 Requirement 12.8.1):

Category	Include when	Examples (illustrative)
Account data is shared	Provider receives, stores, transmits, processes, or can access account data on your behalf	Payment gateway, tokenization provider, chargeback processor, call center handling card payments
Could affect security of account data	Provider’s service can change, administer, host, monitor, or materially influence systems, identities, or controls that protect account data	Cloud hosting for CDE systems, managed security services, outsourced IT admin, WAF/CDN in front of payment pages

A common audit failure is listing only “payment vendors” and missing infrastructure and admin providers that influence CDE security.

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

Step 1: Define inclusion criteria and decision rules

Create a one-page standard that answers:

• What “TPSP” means for your program.
• The two inclusion triggers: account data shared and security impact (PCI DSS v4.0.1 Requirement 12.8.1).
• How you decide borderline cases (example: “If the third party can administer, configure, or host a system in PCI scope, include them.”).
• Who can approve exceptions and how exceptions are documented.

Output: “Service Provider Inventory Standard” (short, enforceable).

Step 2: Assign ownership and RACI

Set clear accountability so the list stays current:

• Inventory owner (Accountable): usually GRC or Security Compliance.
• Data stewards (Responsible): Procurement/Vendor Management, IT, Security, Finance/AP (for spend discovery), and Business system owners.
• Approvers (Consulted): CISO (security-impact classification), Payment Ops (account data sharing classification).
• Users (Informed): Internal audit, QSA support team, Legal.

Audit reality: if no one owns updates, “maintained” becomes “rebuilt annually,” and that is hard to defend.

Step 3: Build the inventory with minimum required fields

The requirement explicitly demands a list and a description of services (PCI DSS v4.0.1 Requirement 12.8.1). In practice, you should include fields that make the list usable in scoping and due diligence.

Recommended inventory fields (practical minimum):

• Legal entity name; DBA if relevant
• Service description (plain language)
• Category: “account data shared” or “security impact” (or both) (PCI DSS v4.0.1 Requirement 12.8.1)
• Business owner (internal)
• Technical owner (internal)
• Systems/processes supported (link to CDE/system inventory)
• Data elements involved (if account data shared)
• Access model: hosted/SaaS, managed service, support access, subcontractors (if known)
• Status: active / in onboarding / terminated
• Contract start and renewal dates (helps keep it current; also drives revalidation)

If you manage this in Daydream, structure the register so each TPSP record links to intake, approvals, reviews, and supporting documents. That linkage becomes your evidence pack without manual stitching.

Step 4: Establish your discovery and reconciliation mechanisms

An assessor will ask: “How do you know this list is complete?” You need repeatable discovery sources. Common sources:

• Procurement and contract repository (purchase orders, SOWs)
• Accounts payable spend reports (catches “shadow” renewals)
• SSO / identity provider app catalog
• Cloud marketplaces and tenant billing exports
• Network/security tooling lists (MSSPs, monitoring agents)
• Payment architecture diagrams and data flow diagrams (for account data sharing)

Control design tip: document which sources you check and how often you reconcile. Keep the reconciliation output.

Step 5: Implement an intake gate for new TPSPs

Require a TPSP inventory check at onboarding:

• New third party request includes: service description, system/data touchpoints, and whether account data is shared or security controls are impacted (PCI DSS v4.0.1 Requirement 12.8.1).
• Approval criteria: who signs off when either trigger is true.
• Provisioning: create TPSP record before contract signature or before technical integration (pick a rule and enforce it).
• Revocation triggers: termination, system retirement, switching providers, or no longer impacting account data/security.

This aligns directly with the recommended operational control approach of defining approval criteria, provisioning steps, review cadence, and revocation triggers for the inventory.

Step 6: Run periodic reviews and offboarding hygiene

“Maintained” lives or dies on review:

• Review the full inventory for accuracy, duplicates, and terminated providers.
• Confirm internal owners still exist and systems listed are current.
• Confirm classification is still correct (account data shared vs. security impact).
• Ensure terminated providers are marked terminated and any access paths are removed.

Retain the review output and sign-off evidence. This matches the expectation to retain review results and exception records as part of a defensible program.

Required evidence and artifacts to retain

Keep artifacts that prove (a) the list exists, (b) it is complete enough to defend, and (c) it is kept current:

1. Current TPSP inventory export (dated; includes service descriptions) (PCI DSS v4.0.1 Requirement 12.8.1)
2. Inventory procedure/standard defining inclusion criteria and update workflow
3. Discovery/reconciliation evidence: spend pulls, app catalog exports, procurement extracts, and your reconciliation notes
4. Change history: who added/edited/terminated TPSPs and why
5. Review sign-offs: meeting minutes, tickets, or GRC attestations
6. Exceptions: documented rationale, approver, and expiration/reevaluation trigger

Common exam/audit questions and hangups

Expect these questions from assessors and internal audit:

• “Show me your TPSP inventory and where each service is described.” (PCI DSS v4.0.1 Requirement 12.8.1)
• “How do you determine whether a third party ‘could affect the security of account data’?” (PCI DSS v4.0.1 Requirement 12.8.1)
• “How do you ensure the list is complete? What sources do you reconcile against?”
• “When was it last reviewed, and who approved the review results?”
• “Pick a TPSP at random. Show me the service description and why it is in scope.”

Hangup: Teams confuse “vendor master list” with “TPSP inventory.” A vendor master is broader; PCI wants the TPSP subset tied to account data and its security (PCI DSS v4.0.1 Requirement 12.8.1).

Frequent implementation mistakes and how to avoid them

1. Mistake: Only listing payment processors.
   Fix: include infrastructure and managed/admin providers that can impact CDE security (PCI DSS v4.0.1 Requirement 12.8.1).

2. Mistake: Descriptions like “IT services” or “cloud.”
   Fix: write descriptions that support scoping, such as “hosts e-commerce application servers in PCI scope” or “managed firewall rule administration for CDE segment.”

3. Mistake: Inventory exists, but no operating process.
   Fix: connect intake to procurement and require a TPSP record before onboarding.

4. Mistake: No evidence of periodic revalidation.
   Fix: retain review outputs, sign-offs, and exception decisions.

5. Mistake: Offboarding not reflected.
   Fix: add a termination workflow and tie it to contract termination and access removal tickets.

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement. Practically, the risk is operational: an incomplete or stale TPSP inventory weakens PCI scoping, leaves “unknown” third parties with access paths into the CDE, and makes it difficult to justify due diligence decisions during assessment testing and remediation follow-up (PCI DSS v4.0.1 Requirement 12.8.1).

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign inventory owner and publish the inclusion criteria (account data shared and/or security impact) (PCI DSS v4.0.1 Requirement 12.8.1).
• Create the inventory schema (fields) and pick the system of record (GRC tool, controlled spreadsheet, or Daydream).
• Pull an initial list from procurement/contracts and payment architecture owners; populate baseline service descriptions.

Days 31–60 (Make it defensible)

• Reconcile against at least two independent sources (for example: AP spend report and SSO app catalog). Document the reconciliation output.
• Add internal owners and map each TPSP to systems/data flows relevant to PCI scope.
• Implement the onboarding gate: update procurement intake or security review intake to require a TPSP inventory record before approval.

Days 61–90 (Make it repeatable)

• Run your first formal review cycle; capture sign-off and track remediation actions (add missing TPSPs, correct descriptions, mark terminations).
• Define and test offboarding triggers with Procurement and IT (termination updates, access removal evidence).
• Package an “assessor-ready” evidence folder: current inventory export, procedures, reconciliation evidence, and review sign-offs.

Frequently Asked Questions

Does the TPSP inventory include third parties that never see card data?

Yes, if the third party could affect the security of account data, they belong in the inventory even without direct data sharing (PCI DSS v4.0.1 Requirement 12.8.1). This commonly includes hosting providers, managed security services, and outsourced administrators.

Can we satisfy the requirement with our vendor master list from Procurement?

Only if you can filter it to the TPSP subset that shares account data or affects its security, and each record includes a service description (PCI DSS v4.0.1 Requirement 12.8.1). Most vendor masters lack PCI scoping rationale and the right level of service detail.

What level of “service description” will pass an assessment?

The description should be specific enough that someone can understand the role in payment processing or CDE security without tribal knowledge. Avoid generic labels; tie it to hosted systems, admin functions, or data flows (PCI DSS v4.0.1 Requirement 12.8.1).

Who should own updates to the inventory?

GRC or Security Compliance typically owns the inventory, but Procurement and IT must feed it through intake and change processes. Pick a single accountable owner who can enforce update rules and run reviews.

How do we prove the list is complete?

Keep evidence of the sources you reconcile against (procurement/contracts, AP spend, SSO catalog, cloud billing exports) and retain the reconciliation output. Assessors look for a method you can repeat, not a one-time claim.

We have many small contractors. Do they count as TPSPs?

If a contractor provides a service that shares account data or can affect the security of account data, they meet the inclusion trigger and should be captured (PCI DSS v4.0.1 Requirement 12.8.1). If they are individuals under a staffing firm, document the contracting model and ensure the service description and security impact are clear.