Definition

SAQ D for Service Providers is the most comprehensive self-assessment questionnaire under PCI DSS v4.0, covering all 12 requirements and applicable to any service provider that stores, processes, or transmits cardholder data on behalf of a merchant or other service provider. It contains approximately 329 control questions and requires an annual AoC signed by a company officer. Service providers that share responsibility for a merchant's PCI DSS compliance must also maintain an accurate Responsibility Matrix (Requirement 12.9.2).

Why it matters

The pressure on PCI DSS v4.0 programmes is shifting in specific, observable ways:

• Visa's Global Registry of Service Providers mandates SAQ D AoC submission annually; de-listing for non-compliance triggers acquirer fines of USD 5,000–25,000/month passed to the service provider.
• QSAs performing merchant RoCs must obtain and review the AoC of every in-scope service provider per Requirement 12.8.4; an expired AoC blocks the merchant's RoC completion.
• Requirement 12.9.2 obliges service providers to provide a documented Responsibility Matrix to each merchant customer; absence of this document is a top-three SAQ D finding in GCC cloud-hosting providers.
• UAE-based payment gateways are subject to CBUAE Payment Systems Regulation 2021 Article 10(3), which incorporates PCI DSS SAQ D AoC as a licensing evidence requirement.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• SAQ D completed workbook — each control question with Yes/No/NA answer, tester initials, and evidence reference number
• Responsibility Matrix (per Requirement 12.9.2) — control ID, service provider vs. merchant ownership, shared-responsibility split percentage
• ASV scan reports (per Requirement 11.3.2) — scan date, pass/fail status, CVSS scores for all external-facing IPs in scope
• Penetration test report (per Requirement 11.4.3) — scope, methodology (PTES/OWASP), tester qualification, findings and remediation dates
• QSA review sign-off email — attestation that sampling was performed, evidence reviewed, and no open P1 findings at AoC issuance

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: Compliance Manager runs a pre-assessment gap walkthrough using the PCI SSC SAQ D v4.0 template, tagging each 'No' answer with control owner and estimated remediation effort in days.
• Day 31–60: IT Security Lead schedules and completes external ASV scan (using Qualys PCI, Tenable.io, or Trustwave) and internal vulnerability scan; remediates all CVSS ≥4.0 findings.
• Day 61–90: Legal drafts or updates Responsibility Matrix for top-20 merchant customers; sends for counter-signature and stores in GRC platform (e.g., OneTrust, Archer).
• Day 90+: QSA performs evidence sampling across the 12 requirements; service provider submits completed SAQ D and AoC to acquiring bank and Visa/Mastercard registry.
• Ongoing: Re-run ASV scans quarterly per Requirement 11.3.2; review and re-issue Responsibility Matrix whenever service catalogue changes.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• SAQ D gap closure rate — target 100% of 'No' answers remediated or risk-accepted before AoC submission
• ASV scan pass rate — target 100% pass (zero CVSS ≥4.0 unmitigated findings) within 30 days of initial scan
• Responsibility Matrix coverage — target 100% of merchant customers with a countersigned matrix within 60 days
• AoC renewal lead time — completed and submitted ≥30 days before expiry date each year
• QSA sample exceptions — target zero repeat findings from prior-year SAQ D assessment

The working checklist

Use this list during your next PCI DSS v4.0 review cycle. The phrasing is intentionally observable — every item is something a reviewer can sample for, not an aspiration.

• Verify: CDE diagrams that don't match what segmentation testing finds.
• Verify: ASV scans with carried-over false positives that were never re-validated.
• Verify: missing TRAs for requirements that allow them (e.g., 11.3.1.1, 5.3.2.1).
• Verify: shared admin accounts that survive into production.
• Verify: logging that records the event but not the actor.
• Verify: network and dataflow diagrams.

Pitfalls we keep seeing

Across MAST Consulting Group's PCI DSS v4.0 portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: ASV scans with carried-over false positives that were never re-validated. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: missing TRAs for requirements that allow them (e.g., 11.3.1.1, 5.3.2.1). What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: shared admin accounts that survive into production. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: logging that records the event but not the actor. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on PCI DSS v4.0 engagements because the integrations are cheap and the evidence is defensible:

• network segmentation testing tools — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• FIM (Tripwire, OSSEC, Wazuh) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• SIEM (Splunk, Sentinel, Chronicle) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs PCI DSS v4.0 programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this checklist is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for PCI DSS v4.0 programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.