Preparing for a PCI DSS assessment
Preparation for a Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 assessment runs in a fixed order: confirm scope and card data flows, map requirements to tests, run gap tests, remediate, repeat penetration tests, retest fixes, and assemble evidence. The result is a traceability matrix, a gap report, retest records, and a test evidence pack for the assessor.
The situation: an assessment date is set
An acquirer, a payment brand, or an enterprise customer sets a date for a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ) with its Attestation of Compliance (AOC). PCI DSS v4.0.1 (PCI Security Standards Council document library, checked on 2026-09-16) leaves the decision on who validates, and how, to "organizations that manage compliance programs (such as payment brands and acquirers)". Requirement 12.8.4 has every entity monitor the compliance status of its third-party service providers at least once every 12 months, so customers ask their service providers for that evidence.
The date lands on a CTO, a compliance lead, and a QA lead at a payment acquiring, POS, card issuing, neobank, or spend management company. Some face a first assessment after a first enterprise contract. Others face an annual reassessment after a rebuilt checkout or a processor migration, and account data now passes through systems that the last assessment did not see. A significant change also triggers a new penetration test under requirements 11.4.2 and 11.4.3 and a new scope confirmation under 12.5.2.
The requirements, the testable items, and the common findings are on the PCI DSS testing requirements page.
What happens when the date arrives without preparation
- A fix planned for the next sprint is not in place. Section 12 of PCI DSS v4.0.1 states that requirements "are not considered to be in place if controls are not yet implemented or are scheduled to be completed at a future date." The entity then performs remediation "if required" and provides an updated report, and the assessor reassesses the open items. The AOC that the acquirer or customer is waiting for arrives later.
- A missed recurring test cannot be compensated. Appendix B allows compensating controls only for a legitimate and documented technical or business constraint. Criterion 6 states that a compensating control "cannot address a requirement that was missed in the past". A quarter without an external vulnerability scan stays a gap. For the initial assessment only, the applicability notes of requirement 11.3.2 accept fewer than four passing scans if the most recent scan passed, a documented procedure requires scans every three months, and rescans show the vulnerabilities corrected.
- A compensating control needs its own test results. Appendix B sets six criteria for each control, including the intent and rigor of the original requirement and going above and beyond other PCI DSS requirements. The Compensating Controls Worksheet in Appendix C asks the entity to "define how the compensating controls were validated and tested". The assessor validates each control at every annual assessment.
- A penetration test finding closed without a retest stays open. Requirement 11.4.4 requires exploitable vulnerabilities to be corrected and penetration testing to be repeated to verify the corrections.
- A service provider without its own AOC joins its customers' assessments. PCI DSS v4.0.1 states that a third-party service provider that does not undergo an annual assessment "must undergo assessments upon request of their customers and/or participate in each of its customers' PCI DSS assessments".
- Card brand consequences flow through members and their contracts. The Visa Core Rules and Visa Product and Service Rules (edition of 18 April 2026, checked on 2026-09-16) require a Visa member to report and verify its merchants' PCI DSS status to Visa at least every six months (section 12.5.1.2, which does not apply in Chile). A member deemed non-compliant with the Account Information Security Program is subject to a non-compliance assessment set out in the AIS Program Guide (section 12.5.1.1). Section 1.9.4.1 requires the member's contracts with merchants and agents to set the liabilities for failure to meet Visa standards.
What needs to be done, in order
- Confirm scope and map card data flows. Requirement 12.5.2 has the entity identify data flows for authorisation, capture, settlement, chargebacks, and refunds, per acceptance channel, and every location where account data is stored, processed, or transmitted, including backups. Output: a payment flow map and an in-scope system inventory.
- Search for card data outside the defined scope. Run test transactions with published test card numbers, then search logs, queues, analytics exports, backups, and pre-production data stores for those primary account numbers (PANs) and card verification codes. Output: search results per data store, with test transaction IDs.
- Map each in-scope requirement to a test. Link requirements such as 3.3.1, 3.4.1, 6.4.3, 7.2.2, and 11.4.4 to test cases, and mark requirements with no test. Output: a requirement-to-test traceability matrix.
- Run a PCI DSS gap assessment with tests. Execute the mapped tests against the defined approach testing procedures, before the assessor does. Output: a gap report with an owner and a fix date per gap.
- Remediate, and document constraints. Engineering fixes each gap. Where a legitimate constraint blocks a fix, the compliance lead drafts the Appendix C worksheet with test results for each proposed control, and the assessor decides on sufficiency. Output: a remediation log and draft worksheets.
- Test the remediated build. Run penetration tests on application and network layers, plus segmentation tests where segmentation reduces scope. Output: a penetration test report and a segmentation test report.
- Complete the scan cycle. An Approved Scanning Vendor (ASV) runs external scans and rescans, and the entity runs internal scans. Output: passing ASV scan reports and internal scan results.
- Retest every corrected finding. Repeat the same test case on a build that contains the fix. Output: retest evidence linked to the original finding.
- Assemble the evidence and hand over. Collect dated test records per requirement. Output: a test evidence pack per audit scope.
Timeline and scope
Durations below are typical engineering estimates for one payment product with one acquirer connection, not measured results.
| Phase | Duration (estimate) | Roles | Output |
|---|---|---|---|
| Scope and data discovery (steps 1 and 2) | 1 to 3 weeks | Compliance lead, payment engineer, QA engineer | Payment flow map and data store search results |
| Requirement mapping (step 3) | 1 to 2 weeks | QA lead, compliance lead | Requirement-to-test traceability matrix |
| Gap testing (step 4) | 2 to 4 weeks | QA engineers, security tester | Gap report with owners and fix dates |
| Remediation (step 5) | 2 to 8 weeks | Client engineering, compliance lead | Remediation log and draft compensating control worksheets |
| Penetration tests and scans (steps 6 and 7) | 2 to 4 weeks | Security tester, ASV | Penetration test report and passing ASV scan reports |
| Retest and evidence (steps 8 and 9) | 1 to 2 weeks | QA engineers, compliance lead | Retest evidence and test evidence pack |
Plan backward from the fieldwork date and give remediation the most slack, because it depends on code changes outside the test team. Scope grows with each payment flow and acceptance channel that 12.5.2 lists, each pre-production environment that the card data search covers, and each third-party service provider whose status 12.8.4 asks the entity to monitor. A service provider confirms scope every six months under 12.5.2.1 and, if it uses segmentation, tests segmentation controls every six months under 11.4.6. A first assessment can rely on the initial-assessment note in 11.3.2; a reassessment needs passing scans for every three-month period in the last 12 months.
How we help before the assessment
The payment flow testing service delivers the payment flow map with every state, transition, and failure path for step 1. The data privacy and test data management service delivers the personal and cardholder data flow map and masking and synthetic test data sets for step 2.
The audit and certification test evidence service delivers the requirement-to-test traceability matrix for step 3, the gap report before the assessment for step 4, retest evidence after remediation for step 8, and the test evidence pack per audit scope for step 9.
The security testing service delivers the web, API, and mobile penetration test report for step 6, findings with severity, reproduction steps, and retest results, and PCI DSS requirement 11 test evidence.
Our output is input to the assessment. The Qualified Security Assessor (QSA) completes the ROC and decides whether a compensating control is sufficient, and the ASV runs the external scans. FintechAssuranceLabs has PCI DSS service provider level 2 status, verified via A2SECURE and valid until 2030.
Questions
What happens if you fail PCI compliance?
What are PCI DSS compensating controls?
What is PCI DSS assessment scope?
Scope your PCI DSS assessment preparation
Send the assessment date, the validation type your acquirer or customer asks for, and your payment flows, and we return a preparation plan with the phases and deliverables.