The best way to prepare for a Qualified Security Assessor (QSA) assessment is to organize your evidence by PCI DSS requirement before fieldwork starts. That means current policies and procedures, system configurations, records showing each control operated throughout the assessment period, and the right people ready for interviews and walkthroughs. Fix gaps early enough that the fix has a track record.
This year's assessments bring extra pressure. PCI DSS v4.0 was retired on December 31, 2024, so v4.0.1 is now the only active version. The future-dated requirements became mandatory on March 31, 2025, which makes this the first assessment cycle where many organizations are tested on all of them.
What changed for PCI DSS assessments in 2025?
Until March 31, 2025, dozens of new v4.0 requirements were best practice. Assessors could note them, but they didn't affect your compliance result. Now they do.
Some of the ones we see catch organizations out:
- 8.4.2: multi-factor authentication for access into the cardholder data environment (CDE), no longer limited to administrators and remote access
- 10.4.1.1: automated mechanisms for audit log review
- 11.3.1.2: internal vulnerability scans performed using authenticated scanning
- 12.3.1: targeted risk analyses for every requirement where you choose the frequency
- 6.4.3 and 11.6.1: management of payment page scripts and change and tamper detection on payment pages, for entities whose validation includes them
If any of these went live close to the deadline, expect your QSA to look closely at how long they've been operating and how you know they work.
What types of evidence does a QSA look at?
PCI DSS testing procedures are written around a few verbs: examine, observe and interview. Most requirements need more than one type of evidence, and the strongest findings show that documentation, configuration and practice all agree.
| Evidence type | What it shows | Examples |
|---|---|---|
| Documentation | What you say you do | Policies, procedures, standards, network and data-flow diagrams, risk analyses |
| Configurations and system settings | How systems are actually set up | Firewall rule sets, password and MFA settings, logging configuration, encryption settings |
| Records | That a control ran over time | Change tickets, access reviews, scan reports, log review alerts, training records |
| Interviews | That people understand and follow the process | Conversations with administrators, developers, security staff and managers |
| Observations | The control working in front of the assessor | Live walkthroughs of a system, a physical site visit, watching a process being performed |
How sampling works
Assessors don't need to examine every server, store or change ticket. The standard allows sampling when an entity has standardized, centrally managed processes and controls, and the sample must represent every type of system component, location and business function in scope.
The QSA chooses the sample and documents why it's representative. Your job is to have consistent controls across the population, and a complete inventory so the QSA can select from it. If one group of systems is configured differently, expect it to be sampled separately.
How does the ROC Template reporting work?
The QSA documents the assessment in the Report on Compliance (ROC) Template. The Council released the template for v4.0.1 in August 2024, with a streamlined layout designed to address assessor feedback on the length of the v4.0 version.
For each requirement, the assessor records one of four findings:
- In Place: the expected testing was performed and all elements of the requirement were met
- Not Applicable: the requirement doesn't apply to your environment, which the assessor must confirm through testing and explain
- Not Tested: the requirement wasn't included in the assessment, which makes it a partial assessment
- Not in Place: some or all elements of the requirement weren't met
The assessor also notes whether a compensating control or the customized approach was used, and describes how each finding was validated. Evidence is listed in the report with reference numbers, and each finding cites the items it relies on. An earlier "In Place with Remediation" option was removed from the v4.0 reporting documents in late 2022, so there's no special status for something fixed mid-assessment.
The practical consequence is traceability. Every finding needs identifiable evidence behind it, and the easier you make it to reference each item, the smoother the reporting goes.
How should you organize evidence?
A tidy evidence repository saves more assessment time than almost anything else. What works well for most organizations:
- Mirror the standard's structure. Create a folder for each of the 12 principal requirements, with subfolders for sub-requirements where the evidence volume justifies it.
- Keep an evidence index. A spreadsheet listing requirement number, evidence item, owner, date collected and file location lets you and the QSA see coverage at a glance.
- Use consistent file names. Include the requirement number, a short description and the date, so any file makes sense out of context.
- Make screenshots self-explanatory. Show the system name or hostname and a date or timestamp. A settings screen that could belong to any server proves very little.
- Protect what you share. Mask PAN and remove secrets such as passwords and keys before evidence leaves your environment. Use a shared repository with access control rather than email attachments.
- Assign owners. Each requirement should have a named person responsible for its evidence, usually the same person who owns the control.
- Reuse last year's request list. If you've been assessed before, the prior request list is the best starting point, adjusted for requirements that became mandatory this year.
Why do roles and responsibilities documents matter?
Each of requirements 1 through 12 opens with a sub-requirement ending in .1.2, which requires that roles and responsibilities for that requirement's activities are documented, assigned and understood. The "understood" part is tested through interviews, so a document nobody has read won't hold up.
A single responsibility matrix covering all 12 requirements often works best. For each activity, name the role that performs it, the role accountable for it, and any third party involved. Include outsourced activities, since requirement 12.8.5 expects you to know which requirements each service provider manages and which you manage yourself.
Keep the matrix current. Reorganizations and staff changes are the most common reason these documents drift out of date.
How do you prepare targeted risk analyses?
Requirement 12.3.1 requires a targeted risk analysis for each requirement that lets you choose how often it's performed. Examples include periodic malware scans (5.3.2.1), review of application and system account access (7.2.5.1), log review for other system components (10.4.2.1) and the frequency of incident response training (12.10.4.1).
Each analysis must document:
- The assets being protected
- The threats the requirement protects against
- Factors that contribute to likelihood or impact
- The resulting frequency, with justification
- A review at least once every 12 months, with an updated analysis when needed
Write one analysis per requirement and show your reasoning, not only the conclusion. If you use the customized approach for any requirement, requirement 12.3.2 calls for a separate targeted risk analysis for each customized control, alongside the controls matrix the QSA will need to derive its own testing procedures.
Why should you remediate before fieldwork?
Many controls are judged on their history, not their current state. Network security control configurations must be reviewed at least every six months under 1.2.7, user accounts and access privileges at least every six months under 7.2.4, and internal and external vulnerability scans run at least every three months under 11.3.1 and 11.3.2. A control switched on the week before fieldwork can't show that history.
Run a gap assessment well before fieldwork, with enough lead time to fix problems and let the fixes produce records. Pay particular attention to requirements that became mandatory on March 31, 2025, and talk to your QSA early about what operating history they'll expect for those.
Keep evidence of each fix, such as the change ticket, the new configuration and the first records it produced. That tells the story of what changed and when.
How do you collect service provider AOCs?
Your third-party service providers are part of your assessment. Requirement 12.8.1 requires a list of them with a description of the services each provides, and 12.8.4 requires you to monitor their PCI DSS compliance status at least once every 12 months. The usual evidence is each provider's Attestation of Compliance (AOC).
When reviewing an AOC, check that:
- The services it covers match the services you actually use
- The assessment date is recent enough to satisfy your 12-month monitoring cycle
- It shows which requirements the provider is responsible for, so you can confirm your 12.8.5 responsibility split
- Any requirements marked Not in Place are understood, along with how they affect you
Start requesting AOCs early. Requirement 12.9.2 obliges service providers to support customer requests for their compliance status and responsibility information, but they still need time to respond.
Frequently asked questions
Will screenshots be enough, or will the QSA want live demonstrations?
That's the assessor's call and it often varies by requirement. Screenshots help with preparation and the evidence index, but expect some live walkthroughs, particularly for configurations and processes the QSA needs to observe.
How far back does evidence need to go?
It should cover the assessment period. For recurring activities, show each occurrence in that period, such as every quarterly scan or every six-monthly review. Discuss newly mandatory requirements with your QSA up front.
What happens if a requirement isn't in place when fieldwork starts?
Tell your QSA as soon as you know. Depending on timing and whether the fix can be validated, the finding may end up Not in Place, which affects your compliance status. A clear remediation record and early conversation give you the most options.
Should we send evidence before fieldwork?
Yes, where your QSA asks for it. Many assessors issue a document request ahead of fieldwork so they can review policies and diagrams in advance and spend onsite time on interviews and observation.
Key takeaways
- Assess against v4.0.1, with every future-dated requirement now in scope.
- Build an evidence repository organized by requirement, with an index, owners and consistent naming.
- Expect each finding to rest on documented, configured and observed evidence that agrees.
- Keep roles and responsibilities documents current and make sure the people named in them know their part.
- Write a targeted risk analysis for every requirement where you set the frequency.
- Fix gaps early enough to produce operating history, and gather service provider AOCs before fieldwork begins.