Service Provider Due Diligence

PCI DSS 4.0.1 Requirement 12.8.3 requires you to have an established, repeatable process to perform due diligence on third-party service providers (TPSPs) before you engage them, so you can demonstrate informed risk decisions for any TPSP that can affect cardholder data security. Operationalize it by gating onboarding on documented security review, approvals, and retained evidence. ¹

Key takeaways:

• You need a documented, pre-engagement due diligence process for TPSPs, not ad hoc questionnaires. ¹
• “Pass/fail” is not the goal; documented decisions, exceptions, and follow-ups are what assessors test. ¹
• Scope matters: prioritize TPSPs whose people, processes, or systems can affect the cardholder data environment (CDE). ¹

“Service provider due diligence” under PCI DSS is an operating requirement, not a paperwork exercise. You need to show your assessor that you have a defined method to evaluate TPSPs before contracting, and that the method is actually used in procurement and onboarding. The fastest path is to build a single intake-and-approval workflow that (1) identifies whether a third party is a TPSP relevant to PCI scope, (2) applies risk-based diligence depth, and (3) blocks purchasing until the diligence outcome is documented and approved. ¹

This requirement tends to fail in practice for two reasons. First, teams treat “TPSP due diligence” as an annual spreadsheet exercise rather than a pre-engagement control. Second, evidence is scattered across email, ticketing, shared drives, and procurement tools, so the organization cannot prove the diligence happened prior to engagement, or cannot tie diligence to the specific service and scope. Your goal is clean traceability: third party → service → CDE impact → diligence performed → decision → contract actions → stored evidence. ¹

If you run Daydream (or any GRC system), configure it to enforce a “no approval, no onboarding” rule and to retain the artifact trail in one place. That single design choice eliminates most audit hangups.

Regulatory text

Requirement statement (excerpt): “An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.” ¹

What the operator must do: maintain a documented process that is actually followed to evaluate a TPSP’s ability to protect cardholder data (and systems impacting it) before you sign, connect, or send data. The process must produce evidence of the review and the decision. ¹

Practical interpretation: “Established process” means assessors expect more than a one-off questionnaire. They look for defined steps, clear ownership, approval gates, and repeatability across TPSPs. “Proper due diligence” means your review is appropriate to the risk and service being provided, and it occurs prior to engagement, not after the contract is signed or the integration is live. ¹

Plain-English interpretation (what you’re being asked to prove)

You must be able to prove two things:

1. You screen TPSPs before you engage them. If a third party can touch card data, access CDE systems, host components, manage security tooling, or otherwise affect CDE security, you cannot onboard them with “we’ll review later.” ¹

2. You can show your work. The assessor needs a trail: what you reviewed, what you decided, who approved, and what you did about gaps (contract terms, remediation plan, exception with compensating controls, or rejection). ¹

Who it applies to (entity and operational context)

Entities: Merchants and service providers validating against PCI DSS 4.0.1. ²

Operational context (the trigger): any third party service provider (TPSP) whose people, processes, or systems can affect the security of the cardholder data environment. This typically includes:

• Hosting, cloud infrastructure, managed platforms where CDE components run
• Payment service providers and processors
• Managed security providers (MSSPs), SOC providers, EDR/MDR operators with privileged access
• IT managed services with admin access to in-scope systems
• Support vendors with remote access pathways into environments impacting the CDE
  This is a scoping and dependency question first, then a diligence-depth question. ¹

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

Step 1: Define “TPSP” for your environment and create an intake gate

Create a short intake form (ticket, workflow, or GRC intake) that must be completed before procurement can proceed. Minimum fields:

• Legal entity name, service description, and business owner
• Data types handled (cardholder data, authentication data) and system access level
• Whether the service touches or can affect the CDE (yes/no/unknown + rationale)
• Intended go-live date and integration method (API, VPN, SSO, remote support)
  Your gating rule: if “can affect CDE” is yes/unknown, diligence is mandatory before signature or access. ¹

Step 2: Classify the TPSP and right-size diligence depth

Use a simple tiering model you can defend in an assessment:

• High impact: stores/processes/transmits account data, hosts CDE components, or has privileged access into CDE-impacting systems.
• Moderate impact: supports security/availability of CDE systems without direct card data handling, or has limited, controlled access.
• Low impact: no access to CDE or CDE-impacting systems; document rationale and stop.
  The requirement does not demand a specific tier model, but “proper due diligence” is easier to defend when the depth matches the risk. ¹

Step 3: Run pre-engagement due diligence using defined review criteria

Document your review criteria so it’s repeatable. A pragmatic set that maps to PCI expectations:

• Security governance: security policy, ownership, incident response contact path
• Access controls: MFA/SSO support, privileged access handling, joiner/mover/leaver controls
• Network/security architecture: segmentation approach, remote access method, encryption in transit
• Vulnerability management: patching approach, scanning cadence, remediation tracking
• Logging and monitoring: audit logs for admin actions, retention approach, alerting
• Data handling: data minimization, storage locations, backup protections, key management assumptions
• Subprocessors: whether they use additional third parties that could affect CDE security
  Evidence can come from questionnaires, attestations, independent reports, architecture diagrams, or policy excerpts. The key is consistency and pre-engagement timing. ¹

Step 4: Document the decision and required follow-ups

Record one of these outcomes:

• Approved: residual risk acceptable; note any required contract clauses or configuration prerequisites.
• Approved with conditions: required remediation tasks, deadlines, or compensating controls owned by someone specific.
• Exception: approved despite unmet criteria; document rationale, risk acceptance authority, and mitigation plan.
• Rejected: document why, to show the process is real.
  Assessors often probe exceptions. Treat them as first-class objects with evidence. ¹

Step 5: Tie diligence to contracting and onboarding

Make diligence outputs actionable:

• Contract addendum requirements (security obligations, breach notification contacts, right-to-audit language where appropriate)
• Access provisioning requirements (MFA, IP allowlists, time-bound access, ticket-based support access)
• Integration controls (tokenization, no storage of sensitive auth data, approved connectivity paths)
  You are not required to implement a specific contract clause set in 12.8.3, but you must show the due diligence led to informed engagement decisions. ¹

Step 6: Centralize evidence and make it assessor-ready

Store artifacts per TPSP in a single system of record. Daydream is a natural fit because it can enforce the intake gate, capture approvals, attach evidence, and produce an assessor-ready trail without chasing email threads.

Required evidence and artifacts to retain

Keep a package per TPSP that is easy to sample during assessment:

• TPSP inventory entry with service description and CDE impact determination ¹
• Due diligence checklist/questionnaire used and completed ¹
• Supporting evidence (reports, policy excerpts, diagrams, answers) ¹
• Risk rating/tiering rationale (why this depth was “proper”) ¹
• Approval record (names/roles, date, decision) showing it happened pre-engagement ¹
• Exceptions and risk acceptance documentation (if any), plus compensating controls ¹
• Follow-up tracking for conditions/remediation items and closure evidence ¹

Common exam/audit questions and hangups

Expect your QSA/internal audit to ask:

• “Show me the established process document and the workflow steps.” ¹
• “Prove this diligence occurred before contract signature or access was granted.” ¹
• “How do you decide which third parties are TPSPs affecting the CDE?” ¹
• “Pick a sample of recently onboarded TPSPs and walk through the evidence trail.” ¹
• “Where are exceptions documented, and who can accept risk?” ¹

Hangups that slow assessments:

• Procurement executed before security review; you end up documenting diligence retroactively.
• No consistent criteria; each business unit uses different questions and thresholds.
• Evidence is missing, stale, or not tied to the exact service in scope. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating all third parties the same.
   Fix: make “TPSP affecting the CDE” a specific classification with a defensible rationale and tiered diligence depth. ¹

2. Mistake: diligence happens after engagement.
   Fix: enforce a hard gate in procurement/onboarding. No PO, no contract signature, no access until the diligence task is complete or formally excepted. ¹

3. Mistake: evidence stored in email or chat.
   Fix: require artifact upload to a system of record (Daydream, GRC repository, or vendor management tool) and link artifacts to the TPSP record. ¹

4. Mistake: “pass” with known gaps and no plan.
   Fix: use “approved with conditions” and track closure. If the business insists, document an exception with named approval authority and compensating controls. ¹

Enforcement context and risk implications (what can go wrong)

No public enforcement cases were provided in your source set, so this section focuses on audit and operational risk.

Weak TPSP due diligence becomes a PCI problem in three predictable ways:

• Scope errors: a TPSP influences the CDE, but you treated them as out of scope, so controls and oversight are missing. ¹
• Assessor sampling failures: you cannot produce evidence for a sample of TPSPs onboarded during the period, or evidence shows review occurred after engagement. ¹
• Unmanaged dependency risk: a TPSP’s access path, logging gaps, or incident handling becomes your incident because it affects the CDE’s security outcomes. ¹

Practical 30/60/90-day execution plan

First 30 days: Stand up the gate and the minimum viable process

• Publish a one-page TPSP due diligence standard: definition, scope trigger, owners, and “no diligence, no onboarding” rule. ¹
• Implement a single intake workflow (procurement ticket, ServiceNow, or Daydream intake) with required fields and approval routing. ¹
• Create a due diligence checklist aligned to your tier model; pilot it on new TPSPs first. ¹

Days 31–60: Normalize evidence, approvals, and exceptions

• Train procurement and business owners on the TPSP trigger and what “prior to engagement” means in practice. ¹
• Centralize artifact storage and naming conventions; require upload for completion. ¹
• Define exception workflow: who can accept risk, what documentation is mandatory, and how compensating controls are recorded. ¹

Days 61–90: Prove operating effectiveness

• Run an internal mini-assessment: sample recent TPSPs and test for timing, completeness, and traceability. ¹
• Fix gaps revealed by sampling (missing approvals, inconsistent tiering, incomplete evidence). ¹
• Operationalize reporting: a live TPSP register view showing status (intake, diligence, approved, exception, follow-ups open). Daydream dashboards can cover this without manual spreadsheets.

Frequently Asked Questions

Does PCI DSS 12.8.3 require a specific due diligence questionnaire or report type?

No specific format is mandated in the provided text; the requirement is an established process and proper due diligence prior to engagement. Use a consistent checklist and evidence set that matches the TPSP’s impact on the CDE. ¹

What counts as “prior to engagement” for a TPSP?

Treat it as before contract signature, purchase order, access provisioning, or data sharing, depending on how your organization engages third parties. The key is you can demonstrate the diligence occurred before the TPSP could affect CDE security. ¹

We use a reseller/partner who subcontracts work. Do we need diligence on the subcontractor?

Your process should identify additional third parties involved in the service delivery if they can affect the CDE. At minimum, document the subcontracting model and how you gain assurance for that dependency as part of “proper due diligence.” ¹

Can we approve a TPSP with gaps if the business insists?

Yes, but treat it as an exception with documented rationale, explicit risk acceptance authority, and tracked compensating controls or remediation actions. Assessors usually focus on whether you made an informed decision and retained evidence. ¹

How do we handle renewals or existing TPSPs that were onboarded years ago?

The requirement focuses on due diligence prior to engagement, but you still need an established process you can demonstrate today. Backfill diligence for in-scope TPSPs where evidence is missing, and make renewals a trigger to re-confirm CDE impact and refresh evidence. ¹

What’s the cleanest way to make this assessor-friendly?

Maintain a single TPSP record per provider with intake, tiering, diligence checklist, approvals, exceptions, and artifacts attached. Tools like Daydream help because they keep timing, approvals, and evidence in one audit trail. ¹

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.3

2. PCI DSS v4.0.1 Requirement 12.8.3; Source: PCI DSS v4.0.1

3. Just Published: PCI DSS v4.0.1