Evaluating a PCI DSS (Payment Card Industry Data Security Standard) Level 1 service provider gets a lot easier when you start with what auditors expect to see: current proof of compliance, clear scope boundaries, and documented responsibility for each control. This guide walks you through a fast, audit-friendly way to vet providers, helping you reduce risk and avoid last-minute surprises.
Where relevant, we’ll also note what to watch for under PCI DSS 4.0.1 when reviewing provider documentation and responsibilities. Here’s a quick checklist to get started.
Simple PCI Level 1 Provider Vetting Checklist
- Verify a current AOC (and the assessment date)
- Confirm scope matches the exact services you’ll use
- Identify what’s excluded (common gap)
- Get a shared responsibility matrix (who owns which controls)
- Validate evidence access (logs, incident response, support process)
- Confirm segmentation/isolation for your environment
- Document it all for audit readiness
Why a Current AOC Matters
A current PCI DSS Attestation of Compliance (AOC) is the fastest way to confirm a provider has been independently assessed against PCI DSS requirements for a defined scope. It’s a baseline trust signal auditors expect to see early—especially when you’re validating third-party services that touch payment environments.
If a provider can’t provide an AOC (or refuses to discuss it at all), treat that as a risk indicator and adjust due diligence accordingly.
What an AOC Proves and What It Doesn’t
An AOC shows that a qualified third party has validated the provider’s PCI DSS controls for a specific environment and set of services. It does not automatically make your organization compliant—your compliance still depends on how you implement the service, what remains in your scope, and which controls you retain.
AOC Request Process (NDA Expectations)
Most reputable providers will share their AOC after an NDA is in place. That’s normal—AOCs can include sensitive details about environments and controls, and providers often gate access to reduce risk.
- What to do: Request the AOC early in procurement, confirm the NDA path, and note any delays or evasive responses as a potential red flag.
How to Verify Validity
AOCs are typically renewed annually, so “having one” isn’t enough—auditors will look at timeliness and assessment cadence.
Mini-checklist:
- Assessment period/report date
- Expiration/renewal cadence
- Next assessment timing
Confirm Scope Inside the AOC
Scope is where many teams get burned. In the AOC, verify the provider’s assessment actually covers what you’re buying and how you’ll use it.
Look for:
- Service names (the specific products/services you’ll consume)
- Environment type (hosted vs. managed vs. shared infrastructure, regions/data centers where relevant)
- Exclusions (what’s explicitly out of scope—often the source of audit surprises)
Require a Roles & Responsibilities Matrix<
Ask for a Roles & Responsibilities (R&R) matrix (often called a shared responsibility matrix). This prevents audit surprises by mapping which PCI requirements the provider covers vs. what you still own—making evidence collection and control narratives much easier.
Evaluating Providers Without a Current AOC
No current AOC doesn’t automatically mean “no”—but it does mean you need more proof. The goal is to determine whether the provider is on a credible path to PCI DSS compliance, can support your audit needs, and has the technical controls to protect cardholder data in practice.
Ask for Proof They’re on a Real Compliance Path
Start by validating intent and execution. Look for concrete signals that PCI DSS isn’t just a roadmap slide.
- Actively working toward PCI DSS: Ask what standard they’re targeting (and whether they’ve accounted for PCI DSS 4.0.1 requirements where applicable).
- Timeline + milestones: Request a documented plan with owners, dates, and measurable deliverables (e.g., gap assessment complete, control implementation, internal testing, QSA engagement).
- Willingness to support your QSA: Confirm they’ll participate in audit conversations, answer QSA questions, and provide requested evidence in a reasonable timeframe.
Security Controls and Evidence You Should Request
If there’s no AOC, you’re effectively building your own evidence trail. Don’t rely on assurances—ask for documentation and artifacts.
- Third-party vulnerability scans + penetration tests: What’s tested, how often, and how findings are tracked and remediated.
- Incident response plan (documented and tested): Ask when it was last exercised and what “tested” means (tabletop, live simulation, postmortem process).
- Secure, well-documented support procedures: How support access is controlled, logged, and reviewed (especially if support staff can access systems in scope).
- Clear documentation access: Confirm you can obtain policies, diagrams, and evidence quickly (and who approves release).
Data Segregation and Tenancy Model
Tenancy is less about the label and more about the controls. Multi-tenant vs. single-tenant can both be secure—what matters is how isolation is implemented and proven.
Ask for technical isolation details, not just “multi-tenant” as a label. For example:
- How data is logically and/or physically separated
- How segmentation is enforced (network, identity, encryption boundaries)
- How access is restricted, monitored, and audited
- What prevents cross-tenant impact or exposure
That last point matters because tenancy choices can affect audit scope and evidence expectations. A single-tenant environment may reduce complexity in some assessments, but only if isolation and responsibilities are clearly defined and documented.
Other things to consider:
- Security incidents: Have you had a reportable security incident? What remediation was completed, and can you share a post-incident summary (and timeline) under NDA?
- Trust signals: Are there any unresolved public complaints, enforcement actions, or sanctions? If yes, what corrective actions were taken, and when were they closed?
- Customer proof: Can you provide customer references with a similar PCI scope/architecture—and confirm they successfully completed a PCI DSS assessment while using your services?
Why the Roles & Responsibilities Matrix Is Critical
A Roles & Responsibilities (R&R) matrix maps each PCI DSS requirement to the party responsible for implementing, operating, and providing evidence (provider vs. customer).
This is one of the highest-leverage documents you can request because it eliminates ambiguity, speeds up QSA alignment, and prevents “last-mile” audit gaps where each side assumes the other owns a control.
What a Good R&R Matrix Includes
- Requirement/control family (not vague “security is shared” statements)
- Evidence owner (who provides logs, screenshots, policies, tickets, IR artifacts)
- Operational owner (who runs the control day-to-day and validates it’s working)
- Shared controls clearly split (provider config vs. your config responsibilities)
- Support model defined (how evidence requests and QSA questions are handled, with timelines/escalation)
Conclusion
A PCI DSS Level 1 service provider can streamline compliance only when their AOC is current and relevant to your exact services, and you have a clear Roles & Responsibilities (R&R) matrix that prevents gaps at audit time. Use the additional checks—incident history, transparency, and customer references—to confirm the provider can support your QSA efficiently under real-world timelines.
With PCI DSS requirements continuing to evolve, vendor vetting matters more than ever. Doing the diligence up front reduces surprises later—and saves significant time and stress when the audit clock is running.
Looking for a PCI-aligned provider with transparency and real-time visibility? Explore how Scale Computing™ delivers managed network services and how SC//AcuVigil™ supports PCI DSS compliance for multi-site operators. Need to review an AOC or Roles & Responsibilities matrix? Contact Scale Computing™ today.
Frequently Asked Questions
What is PCI DSS Level 1 compliance, and who does it apply to?
PCI DSS Level 1 is the highest validation level, typically for organizations processing 6M+ card transactions annually (or designated Level 1) that require a QSA-led assessment.
Does using a PCI DSS Level 1 service provider automatically make my business PCI compliant?
No—provider compliance covers their scoped services, not your full environment, configs, and processes.
What is a PCI DSS Attestation of Compliance (AOC), and what should it include?
An AOC confirms a PCI assessment for a defined scope and should show dates, in-scope services/environment, and exclusions.
How can I verify whether a provider’s AOC is current and relevant to the services I’ll use?
Verify the report/expiration dates and that the AOC scope lists the exact services and environment you’ll use.
What should I look for in the “in-scope” section of a PCI DSS Level 1 service provider’s AOC?
The specific service names, the assessed environment, and any explicit exclusions.
What is a PCI Roles & Responsibilities (R&R) matrix, and why is it critical for audits?
It maps each PCI requirement to provider vs. customer ownership for operation and evidence—preventing audit gaps.