What a PCI DSS readiness assessment covers before your first validation
A readiness assessment starts by confirming with your acquirer or payment brand whether you must validate, and by which method: a Report on Compliance (ROC) completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire (SAQ). Compliance-accepting entities set the validation and reporting requirements, so that answer decides the rest of the work. Only after it is settled should you test current controls against PCI DSS v4.0.1, including the 51 future-dated requirements that have been mandatory since 31 March 2025. Those requirements include authenticated internal vulnerability scanning, multi-factor authentication for all access into the cardholder data environment (CDE), payment page script controls, and targeted risk analyses, and many organizations still treat them as optional.
The organization owns its controls and the evidence behind them. An implementation partner can prepare systems, configurations, logs and documentation, and a gap review can show where evidence is missing or inconsistent. Only a QSA issuing a ROC, or the entity completing an SAQ and its Attestation of Compliance (AOC), produces validation. A consultant's internal report or certificate does not count. Ask any partner to state in writing which parts of the work they perform and which parts the assessor or your own team owns, because that boundary determines whether later findings can be traced to a clear owner.
The answer varies with the validation path, the size of the scope and how mature your evidence is. An SAQ filer with a small, well-documented environment has a very different gap list from a ROC candidate with shared infrastructure and undocumented data flows. Confirm the validation path first, then size the scope, then sample evidence for each future-dated requirement against what an assessor would ask to see. The gaps you find that depend on periodic activities cannot be backdated, so begin those recurring tasks now and keep their records from the first period.
How a readiness review runs from scope confirmation to evidence sign-off
The sequence moves from confirming which validation method applies to handing the assessor a pre-assessment evidence pack, so each phase produces a written output that the next phase depends on. Organizations own every control and every decision, while any outside partner prepares systems and evidence and an independent QSA later performs the formal assessment.
Confirm the validation method with your acquirer
Start by asking your acquirer or payment brand whether you must validate, and whether the answer is a Report on Compliance or a Self-Assessment Questionnaire, because compliance-accepting entities set the validation and reporting requirements. Your payments or finance lead owns this conversation, and the written answer, including the requested reporting deadline and any required assessor type, is the output. Do not begin gap work until this answer is on file, since the method determines which requirements and templates apply.
Confirm and document the cardholder data environment scope
Define the cardholder data environment, the systems that connect to it, and the systems that can affect its security, then map where account data is stored, processed and transmitted. Your security and architecture teams own the inventory and data-flow diagrams, and they should reconcile them against network segmentation and any outsourced components. The output is a signed scope statement with a documented confirmation method, which Requirement 12.5.2 expects you to repeat every 12 months, separate from any assessor scoping work.
Gap-assess each requirement against v4.0.1
Walk every requirement in scope against PCI DSS v4.0.1 using the template that matches your validation method, and record for each one whether the control is in place, partly in place, or missing. Include the requirements that have been mandatory since 31 March 2025, such as authenticated internal scanning, MFA for all access to the cardholder data environment, payment page script controls and targeted risk analyses. The output is a gap register with an owner and evidence location for every line, and an entry for each control you plan to meet through the customized approach.
Close gaps and document the remediation
Assign each gap to an accountable owner, implement the fix in your own environment, and record the change, the approval and the date it took effect. Where an implementation partner helps with configuration, hardening or tooling, the partner's work is documented as changes you own and approve, not as a certificate. The output is a remediation log showing each closed gap with supporting evidence. Be aware that missed periodic activities cannot be backdated, so any gap in a recurring task should be corrected and performed now.
Run and record periodic activities
Perform the recurring tasks the standard expects, including quarterly internal and external vulnerability scans, penetration testing, access reviews, log reviews and policy reviews, and keep the output of each run in an indexed evidence folder. Confirm with your scanning vendor that the external scans are performed by an approved vendor and that any failed results were corrected and rescanned. The output is a calendar of completed activities with dated records. Where an initial assessment is planned, confirm with your QSA which periods they will examine, since the most recent performance may be sufficient if policy requires the activity to continue.
Assemble the pre-assessment evidence pack
Compile the scope statement, gap register, remediation log, policies, diagrams, inventories and periodic-activity records into one index that maps each requirement to its evidence. Check that every item is dated, attributed to an owner, and matches the environment as it exists today. The output is a pre-assessment evidence pack that you share with the QSA as the starting point of the formal assessment. Note that the pack does not itself validate compliance, and only the assessor's report and your signed attestation do.
Sign off evidence and hand over to the assessor
Have a named executive confirm that the evidence reflects the operating environment, that open items are recorded with owners, and that no consultant who designed or implemented a control is being asked to assess it. The assessor then samples or tests the population independently, and the assessor may use 100 percent of a population or a representative sample, but must cover all variants. The output is an executive sign-off memo and a clean handover record. Only the independent QSA issues the Report on Compliance or the assessment outcome.
Which checks show you are ready for a first assessment
A first PCI DSS assessment is only as smooth as the groundwork behind it. The checks below cover the decisions, scope records, newly mandatory controls and periodic evidence that an assessor will ask about first. Work through them in order, because the validation method determines which evidence you need.
Validation method confirmed in writing
Ask your acquirer or payment brand whether you must validate, and which method applies: a Report on Compliance from a QSA or a Self-Assessment Questionnaire with an Attestation of Compliance. Compliance-accepting entities set the reporting requirements, so a verbal answer is not enough. Keep the written reply with the assessment file, and note any reporting deadline it sets. Everything else in this readiness review depends on that answer.
Scope confirmation documented within 12 months
Requirement 12.5.2 expects your organization to confirm its own PCI DSS scope at least every 12 months, separately from the assessor's scoping work. Check that a dated record exists, that it lists every system that stores, processes or transmits account data or could affect its security, and that it covers connected networks, cloud accounts and third-party access. If the record is older than 12 months or describes a network that has since changed, re-perform the confirmation before the assessor starts.
Future-dated requirements in place
All 51 future-dated requirements from v4.0 have been mandatory since 31 March 2025, so they belong in the readiness review. Check four areas first: authenticated internal vulnerability scanning, multi-factor authentication for all access into the cardholder data environment, controls over scripts on payment pages, and targeted risk analyses where the standard requires them. For each, confirm the control runs, produces records, and is documented in your policies, not only in a project plan.
Most recent ASV scan passed and corrected
For an initial assessment, you do not need four passing quarterly scans if the most recent scan passed, your policy requires quarterly scanning, and every finding was corrected and rescanned. Pull the latest ASV scan report and confirm it shows a passing result with no unresolved failing vulnerabilities. Check that the rescan date follows the remediation date and that the scan was performed by an Approved Scanning Vendor. A failing scan with open items will hold up the assessment.
Periodic activities running and recorded
Periodic activities missed before an assessment cannot be backdated or covered by compensating controls. An assessor can accept an initial assessment when the activity was performed in the most recent period and your policies require it to continue. Build a calendar of daily, weekly, quarterly and annual tasks, and check the records for each: log reviews, access reviews, penetration tests and scope checks. Where a task was missed, complete the corrective action and a successful run before the assessor's testing period starts.
Why missed periodic activities cannot be backdated before an assessment
A first assessment does not require you to have performed every periodic activity across the past year. Under the guidance in PCI SSC FAQ 1485, an activity with a defined timeframe can be accepted if it was performed in the most recent period and your policies require it to continue. That relief is narrow. If a quarterly log review, access review, or scan lapsed in an earlier period, the assessor cannot treat it as having happened. Missed periodic activities cannot be backdated, and compensating controls cannot stand in for them. The assessor can only find the requirement in place after you have taken corrective action and the activity has been performed successfully, as set out in PCI SSC FAQ 1572.
Before you book an assessor, build a register of every periodic task in your environment. For each one, record the requirement it supports, the frequency your policy sets, the owner, the date of the last completed run, and where the evidence sits. Typical entries include quarterly external scans, the 12-month penetration test, access reviews, firewall rule reviews, log reviews, and the annual scope confirmation that Requirement 12.5.2 expects you to perform yourself. Confirm each frequency against your own documented policy, not against memory, because the assessor will test against what you wrote.
Use the register to decide what must be corrected now. Any task whose last completion falls outside its required window is a gap to fix before assessment, not a detail to explain away. Perform the overdue activity, retain the output, and confirm that the next cycle is scheduled and owned. Then ask your QSA, in writing, which periods the assessor will sample and whether the most recent cycle is sufficient for each activity. Settle that question early, because a gap discovered during fieldwork can push the assessment back while you repeat the activity.
Who owns scope, controls, evidence and the attestation
Your organization owns the controls, the scope and the evidence. No outside party can accept that ownership on your behalf, and the attestation you sign states that the controls are in place. Your team decides which systems store, process or transmit account data or could affect their security, and it must confirm that scope on its own schedule as well as through the assessor's work.
- Scope confirmation: Your team documents the cardholder data environment and connected or security-impacting systems, and repeats that confirmation every 12 months as Requirement 12.5.2 expects.
- Policies and standards: Your team writes, approves and reviews the security policies and operating procedures that the requirements call for, and assigns named owners.
- Operating evidence: Your team runs the daily, quarterly and annual activities, such as log reviews, access reviews, scans and penetration tests, and keeps the records.
- Vendor and third-party management: Your team holds the responsibility matrices and service provider attestations for outsourced components.
- Assessor coordination: Your team names an accountable contact who provides documents, system access and interviews on time.
Before you engage anyone, confirm with your acquirer or payment brand which validation method applies and who signs the attestation.
An implementation partner such as DeployOpen can prepare the systems, configuration, documentation and evidence that your team and the assessor will review. The partner works inside your environment and under a written scope. It does not decide whether you are compliant, and it does not issue any report, attestation or certificate.
- System preparation: The partner can harden and configure in-scope components, segment networks and deploy logging, monitoring and file integrity tooling, where the agreed scope includes them.
- Documentation and evidence: The partner can draft network and data-flow diagrams, configuration baselines and procedure write-ups, and collect the records that show controls operating over time.
- Security testing: The partner can run or support vulnerability assessments and penetration tests, but the results belong to your organization and the assessor decides how to rely on them.
- Independence limit: A firm that designed or implemented a control generally should not be the one that assesses it, so the partner must not sign the QSA's conclusions.
- Fixed scope: Confirm deliverables, exclusions and handover of evidence in writing before work starts, and confirm whether any ongoing support is a separate retainer.
Ask the partner to state in writing which artifacts it produces and which decisions remain with your team.
The Qualified Security Assessor, or the self-assessment process for SAQ merchants, tests whether the controls exist and operate as described. A QSA completes a Report on Compliance (ROC) and the Attestation of Compliance (AOC). An SAQ is completed by your organization and signed on the official AOC. Only official PCI SSC templates count as validation evidence.
- Testing approach: Assessors may test a representative sample or 100 percent of a population, and sampling must cover all variants of that population (FAQ 1569).
- Independence boundary: A QSA employee who recommends, designs or implements controls for an entity may not assess those controls. A different QSA employee who was not involved must do so (FAQ 1562).
- Reliance on other reports: A QSA cannot rely on SOC 2 reports alone, but can use their evidence after independently confirming scope, mapping, timing and that controls are in place (FAQ 1567).
- Initial assessment rules: Activities need not have occurred in every period of the year if the most recent period shows them and policies require continuation (FAQ 1485). Missed periodic activities cannot be backdated (FAQ 1572).
- Issuance: Only the QSA company issues the ROC and AOC, and the assessor's findings determine the outcome.
Before engaging a QSA, confirm the firm's listing status and the independence of the team members named for your assessment.
What usually delays a first PCI DSS assessment
Most first assessments stall for reasons that were visible months earlier: a scope nobody has confirmed, an assumption that another report covers the same ground, or evidence that was never written down. The cards below cover the pitfalls we see most often and a specific step to avoid each one.
Unclear scope and stray card data
If the team has not mapped where primary account numbers actually live, the assessor will find them in places nobody listed, such as support tickets, spreadsheets, logs or backup files. Each discovery expands the cardholder data environment and can push back the timeline. Before the assessment, run a documented data discovery across storage, logs and file shares, and record the result alongside the scope confirmation that Requirement 12.5.2 expects you to perform yourself.
Assuming a SOC 2 report covers PCI DSS
A SOC 2 report is useful evidence, but it is not PCI DSS validation, and a QSA cannot rely on SOC 2 or SOC 3 reports on their own. The assessor may use the underlying evidence only after independently confirming scope, control mapping, timing and that the controls are in place. Build a mapping from each SOC 2 control to the PCI DSS requirements it touches, then ask the QSA early which items they will accept and what they will retest.
Treating future-dated requirements as optional
The 51 future-dated requirements from v4.0 have been mandatory since 31 March 2025, and a first assessment must cover them. Teams that kept them as best practices often discover late that authenticated internal scanning, MFA for all access to the cardholder data environment, payment page script controls and targeted risk analyses are not in place. Map every future-dated requirement to an owner and a working control now, and test each one before the assessor does.
Undocumented periodic tasks
Many requirements call for activities on a schedule, such as quarterly scans, reviews and log checks. If those activities happened but left no record, the assessor cannot credit them, and periodic activities missed before an assessment cannot be backdated or covered by compensating controls. Create a recurring task calendar with an owner for each item, store the output in a single evidence repository, and begin the cycle well before the assessment date so that a full set of records exists.
Relying on vendor certificates
Vendor badges, consultant certificates and compliance logos are not recognized as validation. Only the official PCI SSC templates, including the ROC or SAQ with its Attestation of Compliance and the ASV scan attestation, count as evidence. Teams that have already shown a certificate to a customer or acquirer may need to correct that message later. Confirm the required validation method with your acquirer or payment brand first, then plan to produce the official template, not a substitute.
Skipping the validation path check
Teams often start gap work against the full standard before confirming whether they must file a ROC or a particular SAQ. That choice sets the evidence set, the testing depth and who signs the report. Ask your acquirer or payment brand in writing which validation method applies and by when, then size the gap work to that method rather than to the whole standard.
How to use consultants without compromising independence
Helping an organization prepare for a PCI DSS assessment and being the assessor are two different roles, and the rules treat them differently. A consultant may recommend, design or implement controls to get your environment ready. The Qualified Security Assessor (QSA) who judges those controls, however, must be a QSA employee who was not involved in recommending, designing or implementing them, and another QSA employee from the same company who was not involved may perform the assessment (PCI SSC FAQ 1562). Your readiness work and your assessment can therefore come from the same firm, but not from the same people on the same controls. Confirm this with the QSA company before any gap work starts, because a firm that cannot staff a separate assessor for the controls it helped build will need to bring in someone else.
Put the division of work in the written scope document before the first task begins. For each area, name who recommends or builds the control, who owns it inside your organization, and who will assess it, and record the QSA employee's name or role where it is known. Cover the activities that sit outside the assessor's work as well, such as the scope confirmation that Requirement 12.5.2 expects you to perform and document yourself every 12 months, so that no one assumes the consultant or the assessor owns it. Also state which artifacts the consultant may write, such as policies, network diagrams or configuration baselines, and which the organization must approve and sign off on itself. Ambiguity here is the most common way independence is lost.
Ask the QSA company, in writing, what it may and may not do for the same client, including advisory work, gap assessments, tool deployment and managed services, and how it separates those teams internally. Ask whether any employee who worked on your readiness project is proposed for the assessment and how the firm will document that they were not involved in the controls under review. Also ask whether the consultant you hire for preparation is the same firm that will issue your Report on Compliance, and if so, how the two engagements will be tracked. Keep these answers with your evidence, because an assessor who later finds a conflict can require rework or question the results.
Common questions about PCI DSS readiness
Can we do PCI DSS readiness work in-house?
Yes, most organizations can run the readiness work internally, but only if someone owns the gap list and the team has time to close it. Your team owns the controls and the evidence in every case. The work involves confirming scope, mapping each requirement to a system or process, closing technical gaps, and writing policies that match what staff actually do. Internal teams often underestimate the time needed for evidence collection, because assessors test whether activities happened across the period, not only on the day they look. Ask your acquirer or payment brand which validation method applies before you decide how much to build internally, since that choice sets the depth of work. Outside help is most useful for an independent gap review or for technical work your team has not done before. Any partner's role should be written into a scope document before work starts.
What does our team need to provide for a readiness review?
A readiness review needs three things: named owners, system access, and documented evidence. Each requirement should have one accountable person who can explain how the control works and who maintains its records. Reviewers need read access to the cardholder data environment, its network and data-flow diagrams, configuration baselines, logging and access records, and vendor contracts that cover third parties handling account data. Evidence should show that activities were performed on a schedule, such as scan reports, access reviews, log reviews, and penetration test results, along with the tickets that show findings were fixed and retested. Without that trail, an assessor cannot confirm a control was in place during the period. Ask any partner to list the exact artifacts it will request before the review begins, and confirm who inside your organization will approve access to production systems.
Does a readiness review change which validation method we use?
No, a readiness review does not decide your validation method. The choice between a Report on Compliance and a Self-Assessment Questionnaire depends on the validation rules set by your acquirer or the payment brands, and on your business type and channel. A readiness review may show that your environment is larger or more complex than expected, which can make a different method or validation level apply, so it is worth confirming the method before spending on gap work. Ask your acquirer to confirm the required method in writing, and ask the review team to tell you if its findings suggest a change. Only the entity that accepts your compliance, not a consultant, sets that requirement.
Does a vendor certificate or compliance logo count as PCI DSS validation?
No, a vendor certificate or compliance logo does not count as PCI DSS validation. Only official PCI SSC templates are recognized as validation evidence: the Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance, and the ASV scan attestation where scanning applies. Certificates issued by vendors or consultants are not accepted, regardless of how they are worded. A readiness review can produce a useful internal summary, but it is not a substitute for an assessment. When a partner offers a certificate or badge, ask what it covers and whether a QSA or the validating entity will accept it. Your acquirer will tell you what evidence it requires.
How do the future-dated requirements affect a first PCI DSS assessment?
All 51 future-dated requirements from PCI DSS v4.0 have been mandatory since 31 March 2025, so a first assessment must cover them. Before that date they were best practices that could be marked not applicable, so organizations that delayed them now face full testing. Readiness work should check items such as authenticated internal vulnerability scanning, multi-factor authentication for all access to the cardholder data environment, payment page script controls, and targeted risk analyses for requirements that allow them. Some of these depend on processes that need time to run, which means a control may need to exist and operate before an assessor can confirm it. Ask your reviewer which future-dated requirements apply to your environment and how it will test each one.
What should we ask a partner before signing a fixed-scope agreement?
Before signing a fixed-scope agreement, ask the partner to define scope, deliverables, and acceptance criteria in writing. Confirm which requirements and systems are included, what evidence the partner will prepare, and what your team must provide and by when. Ask who performs each task and whether the partner will ever assess controls it helped build, since a QSA employee who designed or implemented a control may not assess it. Ask how the partner will handle periodic activities that were missed, because they cannot be backdated. Ask for the list of deliverables that are not validation evidence, and confirm the partner will not issue a report or certificate. DeployOpen follows this model: it prepares systems, controls, and evidence, while independent assessors issue reports and attestations, and its engagements are fixed-scope with terms agreed before work begins.
Can a readiness review's findings be used by the assessor?
Yes, an assessor can use readiness evidence, but it must test the controls itself and confirm they operated in the assessment period. An assessor may test a representative sample or the full population, and it must cover all variants of the population it samples. Findings from a readiness review are useful for planning, but they do not replace the assessor's testing. If a readiness reviewer also designed a control, the assessor must be independent of that work. Keep your gap list, remediation records, and retest evidence organized so the assessor can trace each finding to its fix.
What DeployOpen prepares and what it hands over
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. For a PCI DSS readiness effort, that work means building or reconfiguring the systems that sit in the cardholder data environment, preparing the configuration baselines, logging and access records an assessor will sample, and organizing the evidence against each requirement in the validation path your acquirer confirmed. Where security testing is in scope, DeployOpen runs it as a separate, documented activity so that the results feed your gap closure rather than substituting for it.
Scope, deliverables and timing are agreed in writing before any work starts. That document should name the systems and environments covered, the requirements being prepared, the evidence format, who on your side approves each deliverable, and what happens if the assessor asks for something outside the agreed list. Most engagements are fixed-scope, so ask for the written scope to state which recurring activities, such as quarterly scans or annual penetration tests, are included as one-time preparation and which would need a separate retainer for ongoing support.
DeployOpen does not issue a Report on Compliance, an Attestation of Compliance or any certificate. Those documents come only from the qualified assessor or the official SAQ process, and the entity owns its controls and its validation decision. Confirm this division of roles in your contract and with your assessor before the work begins, so that the evidence you collect is the evidence the assessor will accept, and so that no one on your team mistakes a preparation deliverable for a validation result.
How DeployOpen scopes, implements and prepares evidence before the assessment
DeployOpen works on PCI DSS readiness as an implementation partner. We prepare the systems, controls and evidence in your own environment so your organization and its independent assessor can review them, while the organization owns its controls and only a QSA issues the Report on Compliance or Attestation of Compliance.
How we scope
- Confirm with your acquirer or payment brand which validation method, ROC or SAQ, applies before any build work starts.
- Document the written scope of systems, networks and third parties that the readiness work covers, agreed before work begins.
- Produce a data-flow and system inventory that supports your own scope confirmation under Requirement 12.5.2 each year.
How we build
- Implement or harden open-source components inside your own cloud accounts, data centers or air-gapped networks to meet the technical requirements in scope.
- Close gaps against v4.0.1, including the future-dated requirements mandatory since 31 March 2025 such as MFA for all CDE access.
- Configure recurring activities such as internal scanning, log review and access reviews so they produce records an assessor can sample.
How we hand over
- Deliver written configuration records, runbooks, policies and evidence packs mapped to each requirement in the agreed scope.
- Test the controls we implemented and document results, so your team and assessor can see what was tested and when.
- Hand over administration of every system to your staff, with documented ownership of each recurring task and evidence source.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the readiness phase ends, if your organization wants it.
- Keep independence clear: where DeployOpen designed or built a control, an independent QSA employee not involved in that work assesses it.
- Give your assessor access to the evidence and walkthroughs they request, while the assessor decides what it proves and issues the report.
