PCI DSS Gap Assessment: What It Covers and How to Prepare in 2026

If your acquiring bank has flagged you for compliance validation, your enterprise customer has asked for an Attestation of Compliance, or you are migrating a legacy v3.2.1 programme to PCI DSS v4.0.1 and not sure how far behind you are a gap assessment is almost certainly your starting point.

A PCI DSS gap assessment is not the audit. It is the diagnostic exercise that tells you, before any QSA arrives or any SAQ is signed, exactly where your environment sits against the standard, what is missing, what is partially implemented, and what it will realistically take to reach compliant status. Done well, it removes every surprise from the formal validation that follows. Done poorly or skipped entirely it is the single most common reason organisations fail their first PCI DSS assessment, blow through their compliance deadline, or pay for the same audit twice.

This guide explains exactly what a PCI DSS gap assessment covers, how the process works in practice, what the deliverable should contain, the gaps assessors are finding most often under PCI DSS v4.0.1 in 2026, and how to prepare so the engagement runs in weeks rather than months.

1. What Is a PCI DSS Gap Assessment?
2. Gap Assessment vs Pre-Assessment vs Internal Audit vs ROC
3. Who Needs a PCI DSS Gap Assessment?
4. What a Gap Assessment Actually Covers
5. The 7 Stages of a PCI DSS Gap Assessment
6. What Your Gap Assessment Report Should Contain
7. The Most Common Gaps Found Under PCI DSS v4.0.1 in 2026
8. How to Prepare for Your Gap Assessment
9. How Long It Takes and What It Costs
10. How SecurityWall Conducts PCI DSS Gap Assessments

What a PCI DSS Gap Assessment Is — and What It Costs to Skip One

A PCI DSS gap assessment is the structured diagnostic that compares your current security posture against PCI DSS v4.0.1 requirements before you commit to a formal validation pathway. It identifies missing controls, partial implementations, and missing evidence and produces a remediation roadmap your team can actually execute against, with realistic timelines and effort estimates.

What it is not: a substitute for validation. The gap assessment does not produce an Attestation of Compliance. It does not satisfy any reporting obligation. What it produces is the artefact that lets a CISO, CFO, or board approve a remediation budget without guessing and that lets you walk into your formal QSA assessment or SAQ completion with no surprises.

Skipping the gap assessment to save weeks at the start almost always costs months at the end. The pattern we see consistently:

• First-pass QSA assessments fail. The QSA identifies findings the organisation could have remediated in advance. The validation cycle pauses, sometimes for a full quarter, while remediation catches up.
• Acquiring bank deadlines slip. Acquirers issue compliance deadlines with limited tolerance. Missed deadlines trigger non-compliance fines, increased transaction reserves, or in severe cases, withdrawal of card processing privileges.
• Enterprise customers lose patience. B2B customers asking for your AoC do not accept "we are working on it" indefinitely. Lost deals attributable to missing PCI compliance are now common in payments-adjacent SaaS, fintech, and e-commerce platforms.
• Remediation cost escalates under pressure. Controls implemented under audit-deadline pressure routinely cost two to three times what the same controls cost when implemented to a planned schedule.

The gap assessment is the cheapest part of the entire PCI DSS journey. It is also the part that determines how the rest of the journey runs.

Gap Assessment vs Pre-Assessment vs Internal Audit vs ROC

The terminology around PCI DSS readiness work is genuinely confusing, and several different exercises are routinely confused with one another. Understanding the difference matters because each produces a different deliverable, has a different cost, and serves a different purpose.

The two terms most commonly conflated are "gap assessment" and "pre-assessment." In practice:

• A gap assessment is conducted at the start of the journey, when the organisation does not yet know where it stands. Findings are typically heavy.
• A pre-assessment is conducted at the end of the remediation programme, immediately before the formal QSA engagement. Findings should be light anything significant identified at this stage indicates the remediation programme has not finished.

It is entirely valid and common in larger programmes to commission a gap assessment from one firm and the formal ROC from a separate QSA, to preserve independence. PCI SSC rules allow QSAs to conduct gap assessments and the formal ROC for the same client, but some governance frameworks prefer separation of advisory and assessment roles.

Who Needs a PCI DSS Gap Assessment?

A gap assessment is the recommended starting point for any organisation in one of the following situations:

1. First-time PCI DSS validation. Your acquiring bank, payment processor, or enterprise customer has notified you that compliance validation is required. You have never been through PCI DSS before, and you do not know which SAQ applies, what your CDE actually contains, or how close your existing security posture is to the standard. The gap assessment establishes the baseline.

2. Migration from PCI DSS v3.2.1 to v4.0.1. Your last assessment was conducted under v3.2.1, which retired on March 31, 2024. Your next assessment must be against v4.0.1, with all 64 previously future-dated requirements now mandatory. Even organisations that were comfortably compliant under v3.2.1 commonly identify substantial gaps when reassessed against v4.0.1 particularly around payment page script management (Requirement 6.4.3 and 11.6.1), authenticated internal vulnerability scanning (Requirement 11.3.1.2), Targeted Risk Analyses, and expanded MFA coverage.

3. Service provider seeking initial compliance. Your customers are asking for your AoC because they need it for their own PCI DSS validation. Service providers face a more rigorous standard including the Service Provider variant of SAQ D (370 questions) or a full ROC and the gap assessment scopes the effort accordingly.

4. Significant infrastructure or business changes. Cloud migration, acquisition or divestiture, payment platform replacement, new product line that handles cardholder data, or a major change to network architecture. Any of these can render previous compliance evidence stale and warrant a fresh gap analysis.

5. Failed prior assessment or breach. If you have failed a recent QSA assessment, received a non-compliant scan attestation, or experienced a payment card data breach, a gap assessment defines the remediation programme. Following a confirmed cardholder data breach, merchants are typically elevated to Level 1 status by the card brands, requiring a full ROC regardless of transaction volume.

6. Pre-procurement diligence. Acquirers and investors increasingly require a third-party gap assessment as part of cybersecurity diligence on payment-handling targets. A clean gap assessment report can materially affect deal terms.

If none of these describe your situation and you are simply maintaining an existing programme between annual validations, what you need is internal audit activity not a gap assessment.

What a Gap Assessment Actually Covers

A PCI DSS gap assessment evaluates every applicable requirement of PCI DSS v4.0.1 all 12 high-level requirements and their underlying sub-requirements across the full Cardholder Data Environment and any connected systems that could affect its security.

The work falls into five evidence streams that are evaluated in parallel:

1. Scope Analysis and CDE Definition

Before any control can be assessed, the scope of PCI DSS must be defined. The CDE includes any system component that stores, processes, or transmits cardholder data, plus any system that is connected to or could affect the security of those components.

The gap assessment validates:

• The current scope diagram against actual data flows
• Whether claimed network segmentation genuinely isolates the CDE
• Whether systems claimed as out-of-scope can actually reach in-scope systems
• Whether all locations where cardholder data exists have been identified including unintended locations such as developer log files, support tickets, email, backup systems, and shadow IT

Scope errors are the single most consequential finding in any gap assessment. A system mistakenly excluded from scope is an audit failure waiting to happen. Conversely, an over-scoped environment imposes unnecessary controls and cost.

2. Documentation Review

PCI DSS v4.0.1 requires defined, documented, and approved policies, standards, and procedures across nearly every domain. The gap assessment reviews:

• Information security policy (Requirement 12)
• Network security control policy (Requirement 1)
• Access control policy (Requirement 7)
• Change management procedures
• Incident response plan (Requirement 12.10)
• Vulnerability management procedures (Requirements 6 and 11)
• Encryption and key management policy (Requirement 3)
• Targeted Risk Analyses for any "periodic" frequency requirements
• Roles and responsibilities documentation explicit under most v4.0 requirements

A common finding under v4.0.1 is that policies exist but have not been updated to reflect the new requirements, particularly around payment page script management and customised approach implementations.

3. Technical Control Sampling

The assessor samples technical controls across the CDE to verify they are implemented as documented. This is not a full audit sampling is targeted at high-risk areas and known v4.0.1 hot spots:

• Firewall and network security configuration
• Authentication and MFA enforcement at the CDE perimeter and within
• Encryption of cardholder data at rest and in transit
• Logging and monitoring coverage
• Patch management currency
• Vulnerability scanning evidence (ASV and authenticated internal)
• Penetration testing evidence and methodology documentation

Sampling depth is calibrated to environment size. A small SAQ A-EP environment may be sampled across 5–10 systems; a Level 1 ROC-bound environment may sample 50 or more.

4. Stakeholder Interviews

Gap assessments are not paper exercises. The assessor interviews:

• The CISO or security lead (governance, policy, programme oversight)
• Network and infrastructure teams (Requirements 1, 2, 11)
• Application development teams (Requirement 6)
• Operations and DevOps (Requirements 5, 10, 11)
• Identity and access management owners (Requirements 7, 8)
• Vendor management (Requirements 12.8, 12.9)
• Incident response and SOC (Requirements 10, 12.10)
• Payment operations (scope, data flows)

Interviews surface the controls that are practiced but not documented, and the documents that exist but are not practiced both are gaps under PCI DSS, but they require different remediation paths.

5. Evidence Inventory

The output of the technical and documentation review is consolidated into an evidence inventory: a structured list of every artefact required at formal validation, marked as available, partial, or missing. This inventory becomes the foundation of the remediation roadmap and, ultimately, the QSA's evidence package.

The 7 Stages of a PCI DSS Gap Assessment

A well-run gap assessment moves through seven defined stages. Each has a clear input, output, and stakeholder set.

Stage 1: Kickoff and Scope Confirmation

Duration: 1–3 days

The engagement begins with a kickoff meeting that confirms the assessment scope, identifies stakeholders for each control area, agrees on access and evidence-sharing arrangements, and aligns on the validation pathway being targeted (SAQ type or ROC). The merchant level and applicable SAQ are confirmed with reference to the acquiring bank if there is any ambiguity.

A pre-engagement questionnaire typically 30–80 questions covering payment channels, data flows, infrastructure, and existing security programme maturity is issued before kickoff so the assessor arrives with context.

Stage 2: CDE Scoping and Data Flow Analysis

Duration: 3–7 days

The assessor reviews network diagrams, data flow diagrams, asset inventories, and integration architectures to map exactly where cardholder data enters, traverses, and exits the environment. Where diagrams are outdated or absent which is the case roughly two-thirds of the time on first gap assessments this stage includes the work of producing them.

The output is a confirmed CDE diagram with explicit boundaries, segmentation controls, and connected-system relationships clearly identified.

Stage 3: Documentation Review

Duration: 5–10 days

All policies, standards, procedures, Targeted Risk Analyses, and supporting documentation are reviewed against the v4.0.1 requirements. Each document is scored for currency, completeness, approval status, and alignment to the requirement it satisfies.

The deliverable is a documentation matrix mapping each requirement to its controlling document and noting where documents are missing, outdated, or insufficient.

Stage 4: Stakeholder Interviews

Duration: 5–15 days

Structured interviews are conducted across the stakeholder set identified in Stage 1. Each interview follows a requirement-aligned script designed to elicit how controls operate in practice, who is responsible, what evidence exists, and where the interviewee believes the gaps lie.

The interviews surface implementation reality versus documented practice and the deltas between the two are the highest-value findings.

Stage 5: Technical Control Sampling

Duration: 5–15 days

The assessor samples technical controls across the CDE examining firewall rules, IAM configurations, MFA enforcement, encryption settings, logging coverage, patch state, vulnerability scan reports, and prior penetration test results. This stage frequently runs in parallel with stakeholder interviews.

Where prior ASV scan reports or penetration test reports exist, the assessor evaluates whether they meet PCI DSS v4.0.1 evidentiary standards. Reports that were acceptable under v3.2.1 particularly penetration tests without a documented methodology per Requirement 11.4.1 are commonly insufficient under v4.0.

Stage 6: Gap Analysis and Prioritisation

Duration: 3–7 days

All evidence is consolidated into a scored gap register. Each requirement is rated:

• Compliant — control is implemented, documented, evidenced
• Partially Compliant — control exists but has gaps in scope, documentation, evidence, or consistency
• Non-Compliant — control is missing or fundamentally inadequate
• Not Applicable — requirement does not apply to the assessed environment, with justification

Findings are prioritised by risk, remediation effort, and dependency. The roadmap sequences quick wins (low-effort, high-impact items such as documentation updates and Targeted Risk Analyses) ahead of capital-intensive controls (segmentation redesign, MFA platform deployment, log management infrastructure).

Stage 7: Roadmap Delivery and Walkthrough

Duration: 1–3 days

The final deliverable is presented in a structured walkthrough with the project sponsor, security team, and any executives accountable for the compliance programme. The walkthrough covers the executive summary, the highest-risk findings, the recommended remediation sequencing, and the projected timeline to validation readiness.

The roadmap should be specific enough that a project manager can convert it directly into a work breakdown structure without further interpretation.

What Your Gap Assessment Report Should Contain

The report is the only artefact most stakeholders will see. It must be detailed enough to drive remediation, but accessible enough that an executive can grasp the scope of work in fifteen minutes.

A complete PCI DSS gap assessment report contains the following sections:

Executive Summary. A non-technical overview of compliance posture, the highest-risk findings, the estimated effort to validation, and the recommended validation pathway. Written for a CFO or board audience five pages or fewer.

Scope Statement. A confirmed CDE definition with diagrams (network and data flow), in-scope system inventory, segmentation controls in place, and any scope-reduction opportunities identified.

Methodology. The frameworks and procedures used to conduct the assessment, the sampling approach, the evidence sources reviewed, and the personnel interviewed. This section gives QSAs and internal auditors confidence in the rigour of the work.

Per-Requirement Findings. Every applicable PCI DSS v4.0.1 requirement, with its compliance rating, the evidence evaluated, the specific gap (if any), and the recommended remediation. This is the bulk of the report typically 80–150 pages depending on environment size.

Gap Register. A consolidated, sortable register of every finding with severity rating, remediation effort estimate (low / medium / high), recommended owner, and dependency mapping. This is the artefact that the remediation programme will track against.

Remediation Roadmap. A sequenced plan that converts the gap register into a phased programme typically Phase 1 (foundational, weeks 1–4), Phase 2 (technical controls, weeks 5–16), Phase 3 (validation prep, weeks 17–24). Each phase has explicit entry and exit criteria.

Validation Pathway Recommendation. A confirmed recommendation on the appropriate SAQ type (or ROC requirement), with justification tied to merchant level, payment channels, and CDE characteristics.

Evidence Inventory. A structured catalogue of evidence required at formal validation, marked as currently available, partially available, or to be produced during remediation.

Appendices. Supporting artefacts including the updated CDE diagram, data flow diagrams, third-party service provider list with PCI status, and any Targeted Risk Analyses produced during the assessment.

A report that lacks any of these sections is incomplete. Reports that consist of a colour-coded spreadsheet without a written narrative are insufficient they cannot be used to brief executives, structure a remediation programme, or evidence the assessor's reasoning to a QSA later.

The Most Common Gaps Found Under PCI DSS v4.0.1 in 2026

After a year of v4.0.1 enforcement the future-dated requirements became mandatory on March 31, 2025 the failure patterns are now consistent across the merchant and service provider organisations being assessed in 2026. The table below lists the gaps SecurityWall and our peer assessors are encountering most frequently.

The pattern across these findings is consistent: v4.0 added documentation, evidence, and scope obligations on top of the technical controls that v3.2.1 already required. Organisations that maintained a steady-state v3.2.1 compliance posture frequently find themselves non-compliant under v4.0.1 for administrative rather than technical reasons. This is good news it means the gap is closable without major capital expenditure, but only if the gap assessment surfaces it first.

How to Prepare for Your Gap Assessment

Preparation determines whether the gap assessment runs in five weeks or ten. The single biggest determinant of duration is evidence readiness how quickly the assessor can access the documentation, configuration data, and personnel they need.

Documents to Gather Before Kickoff

Assemble the following into a structured evidence repository (a shared folder, an audit-management platform, or a dedicated SharePoint site) before the engagement begins:

Architecture and scope artefacts

• Network diagrams showing the CDE and connected systems
• Data flow diagrams for every payment channel
• Asset inventory with system owners, OS versions, and patch state
• Cloud account and tenancy inventory
• Wireless network inventory (if any wireless connects to or near the CDE)

Policies, standards, and procedures

• Information security policy (current, board-approved version)
• All sub-policies: access control, encryption, change management, incident response, vendor management
• Security awareness training programme materials
• Acceptable use policy

Evidence of operational controls

• Most recent ASV scan reports and Attestations of Scan Compliance
• Most recent penetration test report and methodology document
• Internal vulnerability scan reports (authenticated)
• Patch management reports
• Logging and monitoring coverage documentation
• IAM access reviews from the last 12 months
• MFA enforcement evidence (configuration screenshots, IdP policy exports)
• Encryption configuration evidence (TLS versions, key management procedures)

Vendor and third-party documentation

• Third-party service provider list with PCI DSS status
• Current AoCs from each PCI-relevant vendor
• Contracts evidencing PCI DSS responsibility allocation
• Cloud shared responsibility matrices

Prior assessment artefacts

• Previous SAQ or ROC (if any)
• Previous gap assessment reports
• Outstanding findings registers and remediation evidence
• Acquiring bank correspondence regarding compliance status

The single most useful preparation step is producing a current network and data flow diagram before the engagement begins. Outdated diagrams add days to scope confirmation.

Stakeholders to Identify and Brief

Confirm by name and contact details the individuals responsible for each control area. The assessor will need 30–90 minutes with each. Stakeholders typically include:

• The CISO or security lead (executive sponsorship and governance)
• Network and infrastructure lead
• Application development lead
• Cloud operations lead
• Identity and access management owner
• SOC or security monitoring lead
• Vulnerability management owner
• Incident response coordinator
• Vendor management or procurement contact
• Payment operations contact
• Internal audit or compliance contact

Brief each stakeholder before the engagement so they understand the scope, the time commitment, and the documentation they will need to provide. Stakeholders blindsided by an interview request rarely give useful interviews.

Access Provisioning

The assessor typically requires read-only access to:

• Configuration management and patch management dashboards
• The vulnerability scanning platform
• Logging and SIEM platforms
• IAM consoles for the CDE perimeter
• Cloud management consoles for in-scope tenancies
• Change management and ticketing systems

Provisioning access in advance prevents the engagement stalling at the technical sampling stage.

Pre-Engagement Checklist

Before kickoff, confirm internally:

• The assessment scope is documented and signed off by executive sponsor
• The applicable validation pathway (SAQ type or ROC) is confirmed with the acquiring bank
• The evidence repository is established and populated with the documents above
• All stakeholders have been notified and confirmed availability
• Read-only access to systems is provisioned or scheduled
• A single point of contact on the merchant side is appointed for the duration of the engagement

Organisations that complete this checklist before kickoff routinely finish gap assessments 30–40% faster than those that do not.

How Long It Takes and What It Costs

Gap assessment duration and cost are driven by three variables: the size and complexity of the CDE, the validation pathway being targeted, and the organisation's evidence readiness at engagement start.

Typical Durations

SAQ A or A-EP environment (e-commerce merchant using a redirect or iframe payment page): 3–5 weeks end to end, with 2–3 weeks of active assessment work.

SAQ D Merchant or larger e-commerce environment: 5–8 weeks end to end, with 3–5 weeks of active work.

Service Provider SAQ D or first-time ROC: 8–12 weeks end to end. Service provider environments are evaluated against more requirements (Service Provider variant of SAQ D contains 370 questions versus 328 for merchants), and the segmentation testing requirement is twice as frequent.

Level 1 ROC environment with cloud infrastructure: 10–16 weeks. Multi-region cloud environments with substantial microservices architecture, several payment channels, and multiple business units routinely take this long.

These are gap assessment durations only. They are separate from and precede the remediation programme and the formal validation that follows.

What Drives Cost Up

• Outdated or absent documentation. Producing diagrams and policies during the gap assessment is expensive. Better to prepare them in advance.
• Multi-region or multi-cloud environments. Each cloud tenancy and each region requires its own scoping analysis.
• Complex integration patterns. Microservices, third-party API integrations, and multiple payment service providers each add scope.
• Distributed teams. Stakeholders across multiple time zones extend interview cycles.
• Greenfield programmes. Organisations with no prior PCI DSS exposure require more contextualisation than those refreshing an existing programme.

What Drives Cost Down

• Recent diagrams and current asset inventory ready at kickoff
• Single point of contact with authority to coordinate stakeholders
• Evidence repository populated and structured before engagement begins
• Existing v3.2.1 compliance posture to refresh against v4.0.1, rather than starting from zero

A gap assessment is the cheapest part of a PCI DSS compliance programme. Skipping it to save days routinely costs weeks at the formal validation stage and a failed QSA assessment that has to be redone costs more than two gap assessments combined.

How SecurityWall Conducts PCI DSS Gap Assessments

SecurityWall conducts PCI DSS v4.0.1 gap assessments for merchants and service providers across all validation levels from SAQ A e-commerce merchants to Level 1 service providers operating multi-region cloud infrastructure. Our gap assessment service is structured to produce a board-approvable remediation roadmap and to set up the formal validation that follows for first-pass success.

Scoped to Your Validation Pathway, Not a Generic Checklist

Before any work begins, we confirm:

• Your applicable SAQ type or ROC requirement, against your merchant level
• Payment channel architecture and CDE characteristics
• Acquiring bank expectations where any ambiguity exists

The assessment is scoped to the requirements that actually apply to your environment so you do not pay for evaluation against controls that do not.

Conducted by Certified Practitioners with Hands-On PCI Experience

Our gap assessment team holds the credentials QSAs and acquiring banks recognise:

• OSCP and OSWE — practical exploitation and web application testing
• CREST CRT — internationally recognised penetration testing
• CISM and CISSP — governance, risk, and information security management
• Direct experience supporting clients through ROC and SAQ validations under both v3.2.1 and v4.0.1

Technical sampling MFA enforcement, encryption configuration, segmentation effectiveness, vulnerability management currency is conducted by practitioners who routinely identify the same controls under offensive testing engagements, not just from a checklist.

Where SecurityWall has conducted the gap assessment, the materials transfer directly into the subsequent ROC engagement eliminating duplicate work and reducing the formal validation timeline by weeks.

Bundled with Penetration Testing and ASV Scanning

SecurityWall is an Approved Scanning Vendor and delivers all three of the technical testing requirements in PCI DSS as a coordinated programme:

• Gap assessment against PCI DSS v4.0.1
• Annual penetration testing under Requirement 11.4 internal, external, and segmentation testing
• Quarterly external vulnerability scanning under Requirement 11.3.2

Single point of contact across all three. Consistent evidence formatting that maps cleanly across requirements. No inter-vendor coordination overhead.

Attestation Pathway Support

Once remediation is complete, we support the formal validation:

• SAQ-level engagements — gap assessment, remediation, and SAQ completion with reviewed AoC sign-off, delivered as a unified programme
• Level 1 ROC engagements — gap assessment and remediation advisory with coordinated independent QSA partners for the formal ROC, where governance frameworks require advisory-assessment separation

The gap assessment is the start of a relationship that runs through validation and into ongoing compliance maintenance not a transactional report and a handoff.

Related reading:

• What Is PCI DSS Compliance? A Plain-Language Guide for 2026
• PCI DSS Penetration Testing Requirements: What Assessors Check
• How to Choose the Right PCI DSS SAQ for Your Business (coming soon)
• PCI DSS v4.0 Compliance Checklist for E-Commerce Merchants (coming soon)
• PCI DSS v4.0 & v4.0.1: Everything That Changed and What You Must Do by 2026
• PCI DSS Gap Assessment: What It Covers and How to Prepare in 2026

Frequently Asked Questions

How long does a PCI DSS gap assessment take?

3–16 weeks depending on environment size and evidence readiness. Small SAQ A merchants with current documentation finish in around 4 weeks; first-time Level 1 service providers with multi-cloud infrastructure run 10–16 weeks.

Does a gap assessment count as PCI DSS validation?

No. It is a diagnostic that produces a remediation roadmap, not an Attestation of Compliance. Formal validation is achieved through an SAQ (for eligible Levels 2–4) or a QSA-issued ROC (mandatory for Level 1 and most service providers).

Can the same firm do our gap assessment and our ROC?

Yes PCI SSC rules allow it, provided the QSA discloses the prior advisory work in the ROC. Some regulated industries require advisory-assessment separation; SecurityWall conducts the gap assessment and coordinates with independent QSA partners for the ROC where independence is required.

How is a gap assessment different from a SAQ?

The gap assessment identifies what needs fixing. The SAQ is the self-attestation you sign once you have fixed it the validation deliverable submitted to your acquiring bank.

Do we need a gap assessment if we already had one for v3.2.1?

Almost always, yes. v4.0.1 added 64 mandatory requirements as of March 31, 2025 including payment page script management, authenticated internal scanning, Targeted Risk Analyses, and expanded MFA scope. A v4.0.1-aligned gap assessment confirms what carries forward and what does not.

What if our gap assessment reveals we are nowhere near compliant?

That is the most useful outcome it can produce. Discovering gaps during a structured assessment where you have time to remediate is significantly better than discovering them during the formal QSA engagement, where they become findings that delay or fail your validation.

Who needs to be involved on our side?

An executive sponsor (typically the CISO), a single point of contact for day-to-day coordination, and stakeholder representatives from network operations, application development, IAM, vulnerability management, SOC, vendor management, and payment operations. Each stakeholder commits 1–3 hours of interview time.

Can we do the gap assessment ourselves with internal staff?

Possible with ISA-certified staff, but rarely advisable for a first-time assessment. Internal teams familiar with the environment routinely miss gaps an outside assessor catches, and tend to calibrate severity to existing posture. Internal teams are better suited to ongoing maintenance once the programme is established.