Scoping checklist
Scoping Checklist: PCI DSS
Before a PCI DSS scoping call, have four things ready: whether you are a merchant or a service provider and the level your acquiring bank has confirmed, every channel through which you take card payments, where card data flows in your environment, and the third parties that handle it for you. Bring the question of whether you validate with a Self-Assessment Questionnaire or a Report on Compliance, because it shapes the whole project. A Qualified Security Assessor performs a Report on Compliance; SecureRoot is not a QSA and signs neither document. No card numbers, credentials, keys or personal data are needed at scoping.
About this help article
Written by SecureRoot Risk Advisory LLP.
Start here
Who you are in the card chain
- Merchant, service provider, or both. A SaaS platform or payment company that handles card data for others is usually a service provider.
- Your merchant or service provider level, confirmed in writing with your acquiring bank or the card brand, not guessed. The payment brands decide what validation is required, and your acquirer tells you.
- What your acquirer or customer has actually asked for, and by when.
- Any previous Attestation of Compliance, and the date it expires.
Channels
Every way you take card payments
- E-commerce: a hosted payment page, an iframe from your payment provider, or a form or API on your own servers that receives card numbers.
- In-app payments in a mobile application.
- Card terminals in shops, offices or with field staff.
- Payments taken by phone or mail, including call centres.
- Recurring billing, saved cards and payment links sent by email or chat.
Card data flows
Where card data goes
- For each channel: where card numbers enter, which systems receive, process or transmit them, and where they leave.
- Whether anything stores card numbers. Under the RBI's card-on-file tokenisation rules most Indian merchants should not, but say if you are unsure.
- Places numbers leak without anyone intending it: logs, backups, exports, legacy database tables, support tools and call recordings.
- Roughly how many systems and locations touch card data, and whether network segmentation separates them from the rest. Say whether that segmentation has been tested, because untested segmentation does not reduce scope.
- A data flow diagram if you have one. If you do not, a description in words is enough; drawing it is part of scoping.
Third parties
Processors and other providers
- Your payment gateway or payment aggregator, and how your systems connect to it.
- Hosting and cloud providers for any system in the card data path.
- Outsourced call centres, tokenisation providers, and third-party scripts loaded on your payment pages.
- Whether you hold a current Attestation of Compliance from each provider that handles card data for you.
SAQ or ROC
The validation question
Bring this as a question, not an answer. Most smaller merchants validate with a Self-Assessment Questionnaire, completed and signed by your own organisation, and the SAQ type depends on how card data flows. Larger merchants and most service providers need a Report on Compliance, completed by a Qualified Security Assessor, and some acquirers ask for QSA involvement below that threshold.
SecureRoot is not a QSA and signs neither the Report on Compliance nor the Attestation of Compliance. It scopes, runs the gap assessment, supports remediation and prepares the evidence and your team for the SAQ or the assessor. The PCI Security Standards Council publishes a searchable list of QSA companies.
Testing so far
Scans and tests already in place
- Whether quarterly external scans by an Approved Scanning Vendor and quarterly internal scans are running, and the date of the last passing scan.
- The date of your last penetration test of the card data environment, and whether segmentation was tested.
- Dates and status are enough at this stage. Reports can wait.
Keep back
What is not needed at scoping
- No card numbers, sample transactions or cardholder data of any kind.
- No passwords, credentials, API keys, encryption keys or certificates.
- No logs, database extracts or exports, which may themselves contain card data or personal data.
Next
What happens after the call
SecureRoot publishes no price for PCI DSS work, because a short SAQ behind a hosted payment page and a Report on Compliance are different jobs. It scopes first, then quotes a fixed price in writing. The QSA's own fee, ASV scans and any tooling sit outside that fee. A first validation usually takes three to five months, and what stretches it is remediation rather than assessment.
Scope boundaries
What this does not cover
- Scoping does not decide your level or validation path; your acquiring bank and the payment brands do.
- SecureRoot is not a QSA. A Report on Compliance comes from a QSA, and an SAQ is signed by your own organisation.
- No preparation guarantees a compliant assessment; the assessor or your own signed SAQ records the result.
Primary Sources
Where the Figures on This Page Come From
Figures and requirements above are taken from the sources below, linked to the primary text wherever one exists rather than to a summary of it.
- Merchant resources: Self-Assessment Questionnaires and validation
PCI Security Standards Council · Link checked 2026-11-13
- Qualified Security Assessors (QSA) list
PCI Security Standards Council · Link checked 2026-11-13
- PCI DSS v4.0.1 and the Self-Assessment Questionnaires (official document library)
PCI Security Standards Council · Link checked 2026-11-13
Related
Services and help that go with this
- PCI DSS scope reduction and SAQ types
Which SAQ fits which payment design.
- PCI DSS compliance services
What SecureRoot does, phase by phase.
- PCI DSS penetration testing
The testing the standard requires.
- Independent assessor involvement
Where the QSA's work starts and ours stops.
- Evidence handling
How evidence is handled once work starts.
Scope your PCI DSS work
Send SecureRoot the answers above. We will book a scoping call, map the card data flows with you and quote a fixed price in writing.