What a Gap Analysis Is and Is Not
A PCI DSS gap analysis is a pre-assessment exercise that identifies the delta between an entity's current control environment and the requirements of the standard. It is not an assessment. It does not produce a Report on Compliance (ROC) or an Attestation of Compliance (AOC). Its output is a prioritised remediation roadmap, not compliance certification.
This distinction matters because it defines what you are obligated to report. During a gap analysis, findings that would be reportable in a formal assessment are instead framed as remediation items. The client can fix them before the formal assessment begins — which is the purpose of the exercise.
Scope note: A gap analysis is only meaningful if the cardholder data environment has been correctly scoped before you begin. Starting a gap analysis against an incorrectly scoped environment produces a gap report that references the wrong systems. Confirm scope — specifically the CDE boundary and all connected components — before commencing the analysis.
Pre-assessment vs post-assessment gap analysis
There are two contexts in which QSAs conduct gap analyses:
Pre-assessment: Conducted before the formal assessment begins. The goal is to find critical gaps early so the client has time to remediate before the assessment window. This protects the client from a failed assessment and protects the QSA's assessment timeline from being disrupted by major findings that require extended remediation.
Version migration: Conducted when an entity is transitioning from PCI DSS 3.2.1 to 4.0.1. The goal is to identify which new 4.0.1 requirements are not yet met and to build a remediation programme. As of 31 March 2025, all assessments must be conducted against 4.0.1.
The Five Phases of an AWS Gap Analysis
Using AWS Security Hub for the Initial Control Sweep
AWS Security Hub's PCI DSS standard provides automated checks across a significant portion of the 12 requirements. Enable it across all in-scope accounts and regions before the engagement begins. The output gives you a baseline findings list that covers:
| Requirement area | Security Hub coverage | Requires manual testing |
|---|---|---|
| Network controls (Req 1) | Security group rules, VPC flow logs enabled, unrestricted ingress | NACLs, Transit Gateway routing, Direct Connect segmentation |
| Account hardening (Req 2) | Default VPC deletion, unused credentials, root account MFA | Application default settings, vendor-supplied defaults at app layer |
| Data protection (Req 3) | S3 encryption, RDS encryption, EBS encryption at rest | Application-level encryption, SAD retention, truncation at code level |
| Transmission encryption (Req 4) | Load balancer HTTPS listeners, CloudFront TLS policy | Cipher suite specifics required for 4.0.1 Req 12.3.3 |
| Access control (Req 7 + 8) | Root account usage, MFA for console, unused IAM credentials | Least privilege review, shared accounts, role separation |
| Logging and monitoring (Req 10) | CloudTrail enabled, S3 logging, VPC flow logs | Log review procedures, alert response, log integrity |
| Vulnerability management (Req 6) | Inspector findings, patch status via SSM | Application-level SAST/DAST results, change management process |
| Security testing (Req 11) | AWS Config rules for basic posture | Penetration test results, ASV scan results, IDS/IPS coverage |
Important: Security Hub findings are not a gap analysis. They are a starting point. Security Hub will report on AWS-native controls but will not assess application-level controls, procedural controls, or the quality of policies and procedures. A gap analysis that relies solely on Security Hub output will miss significant findings.
Common AWS Gaps by Requirement (4.0.1)
The following are the gaps most commonly found in AWS-hosted payment environments during gap analysis engagements. Click each requirement to expand the findings.
Evidence to Collect Before the Engagement
Requesting this evidence before the engagement begins eliminates the most common cause of engagement delays — waiting for artefacts during the analysis:
How to Document Gap Findings for the ROC
Gap findings should be documented in a format that maps directly to the formal assessment report structure. This reduces rework when the formal assessment begins and gives the client a clear view of what the finding will look like in the ROC if not remediated.
Each finding should include:
| Field | Description | Example |
|---|---|---|
| Requirement | The specific sub-requirement number | PCI DSS 4.0.1 Req 3.3.1 |
| Finding title | A specific, actionable title | CVV retained in DynamoDB transaction table after authorisation |
| Evidence reviewed | What you looked at | DynamoDB table schema, application code (Lambda handler), CloudWatch Logs sample |
| Gap description | Why the evidence does not satisfy the requirement | The cvv field is present in the transaction record 48 hours post-authorisation. Req 3.3.1 prohibits any SAD retention after authorisation is complete. |
| Risk rating | Critical / High / Medium / Low | Critical |
| Remediation | Specific action required | Remove cvv field from transaction write path in Lambda handler. Implement pre-write validation to reject records containing SAD. |
| Effort estimate | Development + testing effort | Medium (2–3 days development, 1 day QA) |
| Dependencies | What must be completed first | None — independent remediation item |
Time saving: Gap findings documented in this format can be directly imported into the formal ROC template when the assessment begins. Remediated findings become Compliant. Unremediated findings become Not in Place. The documentation investment at gap analysis stage pays for itself in assessment efficiency.
Interactive assessment
Apply this in your assessment
This assessment maps directly to the controls in this article. Use it to generate gap evidence, cardholder data flow diagrams, or scoping documentation for a PCI DSS assessment — free with a Sync Your Cloud account.