PCI-DSS Controls Gap Analysis & Coverage Report

Document Status: Living Document Last Updated: 2025-12-28 Version: 1.2 Owner: Security & Compliance Team Review Cycle: Quarterly

Document Purpose

This living document provides a comprehensive analysis of CloudForge CI's PCI-DSS (Payment Card Industry Data Security Standard) implementation, identifying:

✅ Controls that are fully automated via infrastructure
⚠️ Controls that are partially automated
❌ Controls that require manual implementation
Infrastructure verification and evidence locations
Gap remediation roadmap

Audience: QSAs (Qualified Security Assessors), security teams, compliance officers, and engineering leadership

Framework Version: PCI-DSS v4.0.1

Executive Summary
PCI-DSS Framework Overview
Implementation Architecture
Detailed Control Mapping
Infrastructure Verification
Gap Analysis
Coverage Metrics
Remediation Roadmap
Testing Status
Cardholder Data Environment (CDE) Scope
Maintenance & Updates

Executive Summary

Overall Coverage

CloudForge CI implements PCI-DSS v4.0 controls at the infrastructure level with comprehensive technical safeguards:

Metric	Value	Status
Total PCI-DSS Requirements	12 principal requirements, 300+ sub-requirements	-
Automated Infrastructure Controls	~35-40 controls (~15-20%)	✅ Strong
Partially Automated	~10-15 controls (~5%)	⚠️ Needs Enhancement
Manual Controls Required	~250+ controls (~75-80%)	❌ Documentation Needed
Infrastructure Coverage	~60-70% of automatable technical controls	✅ Excellent
Production Tested	Infrastructure controls only	⚠️ Auth not tested

Key Strengths

✅ Strong cryptography: AES-256 encryption at rest, TLS 1.2+ in transit (Req 3 & 4)
✅ Network segmentation: VPC, private subnets, security groups (Req 1)
✅ Comprehensive audit logging: CloudTrail, Flow Logs, ALB logs with 1+ year retention (Req 10)
✅ Threat detection: GuardDuty, AWS Config, Security Hub integration (Req 11)
✅ Multi-layer enforcement: Validation rules, Guard policies, AWS Config, Security Profiles
✅ Infrastructure as Code: Version-controlled, immutable deployments (Req 6)

Critical Gaps

❌ Application-Level Controls: Req 3 (PAN masking), Req 6 (secure development) - application-specific
❌ Organizational Policies: Req 12 (security policy), Req 9 (physical security)
❌ Operational Procedures: Req 5 (anti-malware management), Req 7 (access procedures)
❌ Testing & Validation: Req 11 (penetration testing, ASV scans) - requires third-party
⚠️ Authentication: Cognito/OIDC implemented but not production-tested
✅ WAF: REQUIRED and enforced in PRODUCTION (Req 6.6 automated enforcement)

PCI-DSS Framework Overview

Framework Structure

PCI-DSS v4.0.1 (latest version, June 2024) consists of 12 principal requirements organized into 6 control objectives:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and Maintain Network Security Controls
Requirement 2: Apply Secure Configurations to All System Components

Protect Account Data

Requirement 3: Protect Stored Account Data
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software
Requirement 6: Develop and Maintain Secure Systems and Software

Implement Strong Access Control Measures

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Requirement 8: Identify Users and Authenticate Access to System Components

Regularly Monitor and Test Networks

Requirement 9: Restrict Physical Access to Cardholder Data
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Requirement 11: Test Security of Systems and Networks Regularly

Maintain an Information Security Policy

Requirement 12: Support Information Security with Organizational Policies and Programs

Key Changes in PCI-DSS v4.0

✅ NOTE: The March 31, 2025 deadline has passed. All 51 formerly "best practice" v4.0 requirements are now mandatory and must be fully implemented.

March 31, 2025: 51 formerly "best practice" requirements become mandatory
Customized Approach: New option for demonstrating controls (vs. Defined Approach)
Multi-Factor Authentication (MFA): Expanded to all access to CDE (Req 8.4.2)
Targeted Risk Analysis: New requirements for risk-based security controls
Phishing-Resistant MFA: Recommended for high-risk scenarios (Req 8.5.1)

Important: This analysis and infrastructure implementation covers v4.0.1 requirements (including v4.0-specific controls like 12-character minimum passwords per Req 8.3.6).

Implementation Architecture

CloudForge CI implements PCI-DSS controls through 4 enforcement layers:

Layer 1: Validation Rules (Pre-Synthesis)

File: cloudforge-api/src/main/java/com/cloudforgeci/api/core/rules/PciDssRules.java

Java-based validation executed during CDK synthesis
Validates security profile configuration against PCI-DSS requirements
Blocks deployment if mandatory controls are missing (ENFORCE mode)
Provides warnings for recommended controls (ADVISORY mode)

Requirements Validated:

Req 1: Network segmentation, firewall configuration
Req 2: Vendor defaults, secure configurations
Req 3 & 4: Encryption at rest/transit
Req 6.6: Web Application Firewall
Req 7 & 8: Access control, authentication
Req 10: Audit logging, log retention (1+ year)
Req 11: Security monitoring, intrusion detection

Layer 2: CloudFormation Guard Policies (Pre-Deployment)

File: cloudforge-api/src/main/resources/cfn-guard/frameworks/pci-dss-v4.0.1.guard

Policy-as-Code validation of CloudFormation templates
Enforces security controls before infrastructure creation
15 validation rules covering encryption, access control, logging, backups

Key Rules:

pci_s3_encryption: S3 bucket encryption (Req 3.4)
pci_rds_encryption: RDS storage encryption (Req 3.4)
pci_alb_https: HTTPS/TLS on port 443 (Req 4.1)
pci_cloudtrail_enabled: CloudTrail logging (Req 10.2)
pci_cloudwatch_logs_retention: 365+ day retention (Req 10.7)
pci_s3_versioning: S3 versioning for backups (Req 9.5.1)

Layer 3: AWS Config Rules (Runtime Monitoring)

File: cloudforge-api/src/main/java/com/cloudforgeci/api/observability/ComplianceFactory.java

Continuous compliance monitoring via AWS Config
17 AWS Config managed rules for PCI-DSS
Automatic remediation via SSM Automation Documents
Evidence collection for Audit Manager

Rule Categories:

Base Controls (9 rules): Always deployed regardless of framework
PCI-DSS-Specific Controls (8 rules): Conditional on complianceFrameworks: "PCI-DSS"

Layer 4: Security Profile Configuration (Infrastructure Defaults)

File: cloudforge-api/src/main/java/com/cloudforgeci/api/core/security/ProductionSecurityProfileConfiguration.java

Production-grade security defaults
Enforces encryption, monitoring, backups, high availability
1-year minimum log retention (PCI-DSS Req 10.7)
MFA required, password complexity, session management

Detailed Control Mapping

Requirement 1: Install and Maintain Network Security Controls

1.1 - Network Security Controls Defined and Implemented

Sub-Requirement	Description	Implementation	Status	Evidence
1.1.1	Document network security controls	VPC architecture documentation required	❌ Manual	Infrastructure diagrams, network policies
1.1.2	Network diagrams showing CDE	VPC topology, security groups	⚠️ Partial	`PciDssRules.java:145-205`

Infrastructure Implementation:

// PciDssRules.java:148-160 - VPC network segmentation
if (ctx.vpc.get().isEmpty()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-1.2.1-VPC",
        "VPC required for network segmentation",
        "PCI-DSS Req 1.2.1: VPC required for network segmentation"
    ));
}

Testing Status: ✅ Production tested

1.2 - Network Security Controls Applied

Sub-Requirement	Description	Implementation	Status	Evidence
1.2.1	Restrict inbound/outbound traffic	Security groups, NACLs	✅ Automated	`PciDssRules.java:148-160`
1.2.2	Secure wireless environments	N/A (cloud infrastructure)	N/A	-
1.2.3	Prohibit direct public access from Internet to CDE	Private subnets, NAT gateways	✅ Automated	`PciDssRules.java:163-175`
1.2.4	Anti-spoofing measures	AWS VPC built-in protections	✅ Automated	AWS responsibility
1.2.5	Outbound traffic from CDE authorized	Security group egress rules	✅ Automated	Security group configuration
1.2.6	Security features defined for traffic from CDE	Security groups, TLS encryption	✅ Automated	`PciDssRules.java:178-202`
1.2.7	NSCs updated at least every 6 months	Infrastructure as Code (Git)	⚠️ Partial	Git commit history
1.2.8	Configuration files secured	CloudFormation templates in Git	✅ Automated	Git access control

Infrastructure Implementation:

VPC with public/private subnet isolation
Security groups with least-privilege rules
NACLs for additional network layer protection
Private network mode required for CDE (private-with-nat)

Config Rules Deployed:

vpc-default-security-group-closed - Default SG has no rules
restricted-ssh - SSH not open to 0.0.0.0/0
restricted-common-ports - Common ports restricted

Guard Policy: pci_rds_no_public_access - RDS not publicly accessible

Testing Status: ✅ Production tested

1.3 - Network Access to Cardholder Data Environment Restricted

Sub-Requirement	Description	Implementation	Status	Evidence
1.3.1	Inbound traffic restricted to necessary	Security group ingress rules	✅ Automated	`PciDssRules.java:178-202`
1.3.2	Outbound traffic restricted to necessary	Security group egress rules	✅ Automated	Security group configuration
1.3.3	No direct routes between Internet and CDE	Private subnets, NAT gateway	✅ Automated	VPC routing tables

Testing Status: ✅ Production tested

1.4 - Network Connections Between Trusted/Untrusted Networks Controlled

Sub-Requirement	Description	Implementation	Status	Evidence
1.4.1	NSCs implemented at each connection	ALB in public subnet, app in private	✅ Automated	VPC architecture
1.4.2	Inbound traffic from untrusted to trusted limited	Security groups, ALB routing	✅ Automated	Security group rules
1.4.3	Anti-spoofing at trusted/untrusted boundary	AWS VPC protections	✅ Automated	AWS responsibility
1.4.4	System components cannot expose CDE to Internet	Private subnets, no public IPs	✅ Automated	`PciDssRules.java:163-175`
1.4.5	Prevent disclosure of internal IP addresses	NAT gateway, ALB proxy	✅ Automated	Network architecture

Testing Status: ✅ Production tested

1.5 - Risks to CDE from Computing Devices Managed

Sub-Requirement	Description	Implementation	Status	Evidence
1.5.1	Security controls on portable devices	Not applicable (server infrastructure)	N/A	-

Requirement 2: Apply Secure Configurations to All System Components

2.1 - Vendor Defaults Changed Before Production

Sub-Requirement	Description	Implementation	Status	Evidence
2.1.1	Change vendor defaults before production	PRODUCTION profile auto-approved	⚠️ Operational	`PciDssRules.java:546-655`
2.1.2	Remove or disable unnecessary default accounts	IAM best practices, no default accounts	✅ Automated	IAM configuration

Infrastructure Implementation:

// PciDssRules.java:555-568 - Vendor defaults validation
if (isProduction || getBooleanSetting(ctx, "customConfigurationApplied", false)) {
    rules.add(ComplianceRule.pass(
        "PCI-DSS-Req-2.1-CustomConfig",
        "Custom configuration applied - vendor defaults changed (PRODUCTION profile)"
    ));
}

Note: For PRODUCTION security profile, operational controls are assumed to be in place (matches infrastructure-centric approach).

Testing Status: ⚠️ Operational assumption (not infrastructure-testable)

2.2 - Configuration Standards Developed

Sub-Requirement	Description	Implementation	Status	Evidence
2.2.1	Configuration standards address known vulnerabilities	PRODUCTION profile hardening assumed	⚠️ Operational	`PciDssRules.java:572-585`
2.2.2	Enable only necessary services	Security groups, minimal exposure	✅ Automated	`PciDssRules.java:588-602`
2.2.3	Additional security features implemented	TLS, encryption, monitoring	✅ Automated	Multiple controls
2.2.4	Configure system security parameters	Security profile configuration	✅ Automated	`ProductionSecurityProfileConfiguration.java`
2.2.5	Remove unnecessary functionality	Minimal images assumed	⚠️ Operational	`PciDssRules.java:606-619`
2.2.6	Change default credentials	IAM roles, no default credentials	✅ Automated	IAM configuration
2.2.7	Implement automated mechanism for compliance	AWS Config	✅ Automated	`ComplianceFactory.java`

Testing Status: Mixed (✅ infrastructure, ⚠️ operational assumptions)

2.3 - Wireless Environments Configured Securely

Sub-Requirement	Description	Implementation	Status	Evidence
2.3.1	Wireless encryption keys changed	N/A (cloud infrastructure)	N/A	-
2.3.2	Wireless security settings configured	N/A (cloud infrastructure)	N/A	-

2.4 - Inventory of System Components Maintained

Sub-Requirement	Description	Implementation	Status	Evidence
2.4.1	Inventory of system components	AWS Config resource inventory	✅ Automated	`PciDssRules.java:639-652`
2.4.2	Automated mechanisms identify connections	VPC Flow Logs, CloudTrail	✅ Automated	Flow Logs, CloudTrail

Testing Status: ✅ Production tested

Requirement 3: Protect Stored Account Data

3.1 - Account Data Storage Minimized

Sub-Requirement	Description	Implementation	Status	Evidence
3.1.1	Data retention policy documented	❌ Application responsibility	❌ Manual	Data retention policy document
3.1.2	Cardholder data storage minimized	❌ Application responsibility	❌ Manual	Application data handling
3.1.3	No sensitive authentication data stored post-authorization	❌ Application responsibility	❌ Manual	Application code review

Gap: Requirement 3.1 is application-specific and cannot be infrastructure-automated. Organizations must implement data minimization in their applications.

3.2 - Sensitive Authentication Data Not Stored After Authorization

Sub-Requirement	Description	Implementation	Status	Evidence
3.2.1	Do not store full track data	❌ Application responsibility	❌ Manual	Application code review
3.2.2	Do not store CAV2/CVC2/CVV2/CID	❌ Application responsibility	❌ Manual	Application code review
3.2.3	Do not store PIN/PIN block	❌ Application responsibility	❌ Manual	Application code review

Gap: Requirement 3.2 is application-specific and cannot be infrastructure-automated.

3.3 - PAN Masked When Displayed

Sub-Requirement	Description	Implementation	Status	Evidence
3.3.1	PAN masked when displayed	❌ Application responsibility	❌ Manual	Application UI/logging review
3.3.2	Technical controls for masking	❌ Application responsibility	❌ Manual	Application code review
3.3.3	Remote access displays max 4 digits	❌ Application responsibility	❌ Manual	Application code review

Gap: Requirement 3.3 is application-specific and cannot be infrastructure-automated.

3.4 - PAN Rendered Unreadable Anywhere Stored

Sub-Requirement	Description	Implementation	Status	Evidence
3.4.1	Disk encryption or database encryption	EBS, EFS, RDS, S3 encryption (AES-256)	✅ Automated	`PciDssRules.java:211-305`
3.4.2	PAN unreadable for removable media	S3 encryption, EBS snapshots encrypted	✅ Automated	AWS encryption

Infrastructure Implementation:

// PciDssRules.java:219-232 - EBS encryption validation
if (!config.isEbsEncryptionEnabled()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-3.4-EBS",
        "EBS encryption must be enabled for cardholder data at rest",
        "EbsEncryptionRule",
        "PCI-DSS Req 3.4: EBS encryption must be enabled"
    ));
}

Config Rules Deployed:

encrypted-volumes - EBS encryption enforcement
s3-bucket-encryption - S3 encryption enforcement
rds-storage-encrypted - RDS encryption enforcement

Guard Policies:

pci_s3_encryption - S3 BucketEncryption exists
pci_rds_encryption - RDS StorageEncrypted = true
pci_ebs_encryption - EBS Encrypted = true
pci_efs_encryption - EFS Encrypted = true
pci_dynamodb_encryption - DynamoDB SSEEnabled = true

Testing Status: ✅ Production tested

3.5 - Cryptographic Keys Protected

Sub-Requirement	Description	Implementation	Status	Evidence
3.5.1	Key-encrypting keys as strong as data keys	KMS customer-managed keys	✅ Automated	KMS configuration
3.5.2	Key management procedures documented	❌ Manual	❌ Manual	Key management policy

Testing Status: ✅ Infrastructure tested, ❌ procedures not documented

3.6 - Key Management Procedures Implemented

Sub-Requirement	Description	Implementation	Status	Evidence
3.6.1	Cryptographic key procedures	KMS key rotation, access policies	✅ Automated	`AuditManagerControlRegistry.java:251-263`
3.6.2	Key change procedures	KMS automatic rotation (annual)	✅ Automated	KMS rotation settings

Config Rule: kms-key-rotation-enabled - Annual key rotation

Guard Policy: pci_kms_key_rotation - EnableKeyRotation = true

Testing Status: ✅ Production tested

3.7 - Cryptography and Key Management Fully Documented

Sub-Requirement	Description	Implementation	Status	Evidence
3.7.1	Cryptography documented	❌ Manual	❌ Manual	Cryptography policy document

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

4.1 - Strong Cryptography and Security Protocols Used

Sub-Requirement	Description	Implementation	Status	Evidence
4.1.1	Industry best practices for TLS	ALB TLS 1.2+ minimum policy	✅ Automated	`PciDssRules.java:277-302`
4.1.2	Trusted keys and certificates maintained	ACM certificate management	✅ Automated	ACM configuration

Infrastructure Implementation:

// PciDssRules.java:277-288 - SSL/TLS enforcement
if (!ctx.cfc.enableSsl()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-4.1-SSL",
        "SSL/TLS must be enabled for encrypted transmission",
        "PCI-DSS Req 4.1: enableSsl must be true"
    ));
}

Additional Controls:

EFS encryption in transit (TLS)
TLS certificate validation
No insecure protocols (SSLv3, TLS 1.0/1.1)

Guard Policy: pci_alb_https - HTTPS/TLS on port 443

Testing Status: ✅ Production tested

4.2 - PAN Never Sent Via Unencrypted Technologies

Sub-Requirement	Description	Implementation	Status	Evidence
4.2.1	No unencrypted PAN transmission	❌ Application responsibility	❌ Manual	Application code review, logging review
4.2.2	No PAN via end-user messaging	❌ Application/policy	❌ Manual	Messaging policy, user training

Gap: Requirement 4.2 is application-specific and cannot be infrastructure-automated.

Requirement 5: Protect All Systems and Networks from Malicious Software

5.1 - Anti-Malware Mechanisms Deployed

Sub-Requirement	Description	Implementation	Status	Evidence
5.1.1	Anti-malware deployed on systems	Fargate (immutable containers) + GuardDuty	⚠️ Alternative approach	`ThreatProtectionRules.java`
5.1.2	Anti-malware kept current	AWS-managed (GuardDuty auto-updates)	✅ Automated	GuardDuty service

Alternative Approach:

Fargate: Immutable container infrastructure prevents malware persistence
GuardDuty: Runtime threat detection for crypto mining, malware, unauthorized access
Container Image Scanning: Recommended via ECR image scanning (external)

Testing Status: ⚠️ Alternative approach (not traditional anti-malware)

Action Required: Document alternative approach for QSA review

5.2 - Anti-Malware Mechanisms Configured Correctly

Sub-Requirement	Description	Implementation	Status	Evidence
5.2.1	Anti-malware active and cannot be disabled	GuardDuty always-on for production	✅ Automated	`ProductionSecurityProfileConfiguration.java:118-126`
5.2.2	Periodic scans performed	GuardDuty continuous monitoring	✅ Automated	GuardDuty findings
5.2.3	Removable media scanned	N/A (cloud infrastructure)	N/A	-

Testing Status: ✅ Production tested (GuardDuty)

5.3 - Anti-Malware Mechanisms Maintained

Sub-Requirement	Description	Implementation	Status	Evidence
5.3.1	Mechanisms kept current	AWS-managed updates	✅ Automated	AWS responsibility
5.3.2	Periodic evaluations performed	GuardDuty findings review	⚠️ Manual review	GuardDuty console
5.3.3	Generate audit logs	GuardDuty findings logged	✅ Automated	CloudWatch Events, S3
5.3.4	Anti-malware cannot be disabled	GuardDuty protected by IAM	✅ Automated	IAM policies
5.3.5	Administration tasks limited	IAM roles with least privilege	✅ Automated	IAM configuration

Testing Status: ✅ Production tested

Requirement 6: Develop and Maintain Secure Systems and Software

6.1 - Security Vulnerabilities Identified and Addressed

Sub-Requirement	Description	Implementation	Status	Evidence
6.1.1	Process to identify security vulnerabilities	AWS Config, Inspector (optional)	⚠️ Partial	Config compliance dashboard
6.1.2	Reputable outside sources for alerts	AWS Security Bulletins	✅ Automated	AWS notifications
6.1.3	Inventory of bespoke software	❌ Application responsibility	❌ Manual	Software inventory, SBOM

Testing Status: ⚠️ Partial (infrastructure monitoring only)

6.2 - Bespoke Software Developed Securely

Sub-Requirement	Description	Implementation	Status	Evidence
6.2.1	Software development personnel trained	❌ Organizational	❌ Manual	Training records
6.2.2	Software reviewed prior to release	❌ Application/process	❌ Manual	Code review process documentation
6.2.3	Change control for software changes	Infrastructure as Code (Git)	✅ Automated	Git commit history, PR approvals
6.2.4	Access to production data prevented	IAM least privilege, separate environments	✅ Automated	IAM policies

Testing Status: Mixed (✅ infrastructure, ❌ application development)

6.3 - Security Vulnerabilities Managed

Sub-Requirement	Description	Implementation	Status	Evidence
6.3.1	Inventory of software components	❌ Application responsibility	❌ Manual	Software Bill of Materials (SBOM)
6.3.2	Vulnerabilities prioritized by risk	AWS Config severity levels	⚠️ Partial	Config compliance dashboard
6.3.3	Vulnerabilities addressed based on risk	AWS Config remediation	⚠️ Partial	SSM automation documents

Testing Status: ⚠️ Partial (infrastructure only)

6.4 - Public-Facing Web Applications Protected

Sub-Requirement	Description	Implementation	Status	Evidence
6.4.1	Web apps protected from attacks	AWS WAF (REQUIRED)	✅ Enforced	`PciDssRules.java:317-334`
6.4.2	Automated technical solution enforced	WAF validation (fail=block)	✅ Automated	34 WAF test cases in compliance-test-matrix.csv

Infrastructure Implementation:

// PciDssRules.java:317-334 - WAF validation
if (!config.isWafEnabled()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-6.6-WAF",
        "Web Application Firewall (WAF) REQUIRED for PCI-DSS compliance in PRODUCTION",
        "WafEnabled",
        "PCI-DSS Req 6.6: Protect all public-facing web applications from known attacks by " +
        "installing a web application firewall..."
    ));
}

Important: WAF is now REQUIRED (not optional) for PRODUCTION with PCI-DSS. Validation will fail if WAF is not enabled.

Testing Status: ✅ WAF REQUIRED and enforced with 34 test cases

Evidence:

Implementation: PciDssRules.java:317-334
Testing: 34 WAF test cases in compliance-test-matrix.csv
Test Names: FAIL_PCI-DSS_*_no_WAF* (EC2, FARGATE, multi-framework combinations)

6.5 - Changes to System Components Managed Securely

Sub-Requirement	Description	Implementation	Status	Evidence
6.5.1	Change control procedures documented	Infrastructure as Code (Git)	✅ Automated	`PciDssRules.java:354`
6.5.2	Technical controls for change management	Git, PR approvals, CloudFormation	✅ Automated	Git workflow
6.5.3	Document pre-production testing	❌ Process documentation	❌ Manual	Testing procedures
6.5.4	Removal of test data before production	❌ Process documentation	❌ Manual	Data sanitization procedures
6.5.5	Change approval by authorized parties	Git branch protection, PR approvals	✅ Automated	GitHub/GitLab settings
6.5.6	Deployed changes documented	Git commit messages, CloudFormation change sets	✅ Automated	Git history, CloudTrail

Testing Status: ✅ Infrastructure change management tested

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

7.1 - Processes for Granting Access Defined

Sub-Requirement	Description	Implementation	Status	Evidence
7.1.1	Access control mechanisms	IAM policies, security groups	✅ Automated	`PciDssRules.java:343-404`
7.1.2	Access control configured	IAM roles with least privilege	✅ Automated	IAM policy documents

Infrastructure Implementation:

// PciDssRules.java:348-361 - IAM access control validation
if (ctx.iamProfile == null) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-7.1-IAM",
        "IAM profile must be configured for least privilege",
        "PCI-DSS Req 7.1: IAM profile required"
    ));
}

Config Rules Deployed:

iam-password-policy - Password complexity enforcement
iam-user-no-policies - Users must use groups
iam-root-access-key-rule - No root access keys

Testing Status: ✅ Production tested

7.2 - Access Based on Business Need to Know

Sub-Requirement	Description	Implementation	Status	Evidence
7.2.1	Access limited to least privileges	IAM roles, security groups	✅ Automated	IAM configuration
7.2.2	Access assignment based on role	IAM role-based access control (RBAC)	✅ Automated	IAM roles
7.2.3	Default deny for all access	Security groups deny-by-default	✅ Automated	Security group rules
7.2.4	Access rights reviewed and confirmed	❌ Manual process	❌ Manual	Access review records
7.2.5	Privileged access assigned based on need	IAM roles for services	✅ Automated	IAM service roles
7.2.6	Access control mechanisms configured	Security groups, IAM policies	✅ Automated	AWS configuration

Testing Status: ✅ Infrastructure tested, ❌ manual reviews not implemented

7.3 - Access to System Components Recorded

Sub-Requirement	Description	Implementation	Status	Evidence
7.3.1	All access to system components logged	CloudTrail, VPC Flow Logs	✅ Automated	`PciDssRules.java:410-478`

Testing Status: ✅ Production tested

Requirement 8: Identify Users and Authenticate Access to System Components

8.1 - Processes for User Identification Defined

Sub-Requirement	Description	Implementation	Status	Evidence
8.1.1	Users assigned unique ID	IAM users, Cognito users	⚠️ Implemented, not tested	IAM user list, Cognito User Pool

Testing Status: ⚠️ Cognito not production-tested

8.2 - User Authentication Managed

Sub-Requirement	Description	Implementation	Status	Evidence
8.2.1	Strong authentication for users	OIDC with MFA-enabled providers	⚠️ Implemented, not tested	`PciDssRules.java:364-379`
8.2.2	Strong authentication for admins	IAM MFA enforcement	✅ Automated	AWS Config: `iam-user-mfa-enabled`
8.2.3	Password policies enforce complexity	IAM password policy (8+ chars for PCI)	✅ Automated	`ProductionSecurityProfileConfiguration.java:449`
8.2.4	Password change procedures	IAM password rotation (90 days)	✅ Automated	IAM password policy
8.2.5	Passwords not sent in clear text	Cognito HTTPS, IAM console HTTPS	✅ Automated	HTTPS enforcement
8.2.6	Authentication credentials protected	KMS encryption, Secrets Manager	✅ Automated	KMS, Secrets Manager

Infrastructure Implementation:

// PciDssRules.java:364-379 - Authentication validation
String authMode = ctx.cfc.authMode();
if ("none".equals(authMode)) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-8.2-Auth",
        "Authentication must be enabled for production",
        "Configure authMode with MFA-enabled identity provider"
    ));
}

Testing Status: ⚠️ IAM tested, Cognito/OIDC not production-tested

8.3 - Multi-Factor Authentication (MFA) Implemented

Sub-Requirement	Description	Implementation	Status	Evidence
8.3.1	MFA for all non-console admin access	IAM MFA enforcement	✅ Automated	AWS Config: `iam-user-mfa-enabled`, `root-account-mfa-enabled`
8.3.2	MFA for all access to CDE	Cognito MFA or Identity Center MFA	⚠️ Implemented, not tested	`PciDssRules.java:381-401`

Infrastructure Implementation:

// PciDssRules.java:387-400 - MFA validation
boolean usingCognitoWithMfa = ctx.cfc.cognitoMfaEnabled();
boolean hasValidSso = ctx.cfc.ssoInstanceArn() != null;

if (!usingCognitoWithMfa && !hasValidSso) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-8.3-MFA",
        "Multi-factor authentication required",
        "Enable Cognito MFA OR configure IAM Identity Center"
    ));
}

Guard Policy: pci_cognito_mfa - MfaConfiguration in ['ON', 'OPTIONAL']

Testing Status: ⚠️ IAM MFA tested, Cognito/OIDC MFA not production-tested

Action Required: Test Cognito MFA and Identity Center MFA in production

8.4 - MFA Systems Configured Correctly

Sub-Requirement	Description	Implementation	Status	Evidence
8.4.1	MFA uses independent methods	Cognito TOTP/SMS, Identity Center MFA	⚠️ Implemented, not tested	Cognito MFA configuration
8.4.2	MFA for all access into CDE (v4.0 - Now Mandatory)	Cognito/Identity Center MFA	⚠️ Implemented, not tested	MFA configuration
8.4.3	MFA replay resistance (v4.0 - Now Mandatory)	Cognito time-based OTP, Identity Center	⚠️ Implemented, not tested	TOTP configuration

Note: 8.4.2 and 8.4.3 became mandatory on March 31, 2025 (PCI-DSS v4.0) - deadline has passed

Testing Status: ⚠️ Not production-tested

8.5 - MFA Use by Third Parties

Sub-Requirement	Description	Implementation	Status	Evidence
8.5.1	Phishing-resistant MFA for third-party access (v4.0 - Now Mandatory)	Identity Center with WebAuthn/FIDO2	⚠️ Recommended	Identity Center configuration

Note: 8.5.1 became mandatory on March 31, 2025 - deadline has passed

8.6 - Use of Application and System Accounts Managed

Sub-Requirement	Description	Implementation	Status	Evidence
8.6.1	Shared authentication not used	IAM service roles (unique per service)	✅ Automated	IAM configuration
8.6.2	Passwords for accounts not embedded	Secrets Manager, IAM roles	✅ Automated	Secrets Manager usage
8.6.3	Passwords changed when employee leaves	Secrets Manager rotation	⚠️ Manual trigger	Secrets Manager rotation policy

Testing Status: ✅ Infrastructure tested, ⚠️ rotation procedures not tested

Requirement 9: Restrict Physical Access to Cardholder Data

Note: Physical security is AWS's responsibility under the Shared Responsibility Model for cloud infrastructure.

Requirement	Description	Implementation	Status	Evidence
9.1 - 9.9	Physical access controls	AWS data center security (SOC 2 Type II)	✅ AWS Responsibility	AWS SOC 2 report, compliance certifications

Action Required: Obtain and review AWS SOC 2 Type II report for evidence of physical security controls

Testing Status: N/A (AWS responsibility)

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

10.1 - Processes for Logging Defined

Sub-Requirement	Description	Implementation	Status	Evidence
10.1.1	Logging enabled for all system components	CloudTrail, Flow Logs, ALB logs	✅ Automated	`PciDssRules.java:410-478`

Testing Status: ✅ Production tested

10.2 - Audit Logs Capture Required Details

Sub-Requirement	Description	Implementation	Status	Evidence
10.2.1	User access to cardholder data logged	CloudTrail, ALB logs	✅ Automated	`PciDssRules.java:418-431`
10.2.2	Administrative actions logged	CloudTrail API calls	✅ Automated	CloudTrail event history

Infrastructure Implementation:

// PciDssRules.java:418-431 - CloudTrail validation
if (!config.isCloudTrailEnabled()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-10.2-CloudTrail",
        "CloudTrail must be enabled for API activity audit logging",
        "CloudTrailEnabledRule"
    ));
}

Config Rule: cloudtrail-enabled - CloudTrail logging active

Guard Policy: pci_cloudtrail_enabled - IsLogging = true

Testing Status: ✅ Production tested

10.3 - Audit Logs Include Required Details

Sub-Requirement	Description	Implementation	Status	Evidence
10.3.1	User identification	CloudTrail provides user, timestamp, action	✅ Automated	CloudTrail log format
10.3.2	Event type	CloudTrail event names	✅ Automated	CloudTrail event history
10.3.3	Date and time	CloudTrail timestamps (UTC)	✅ Automated	CloudTrail logs
10.3.4	Success/failure indication	CloudTrail errorCode field	✅ Automated	CloudTrail logs
10.3.5	Event origin	CloudTrail sourceIPAddress	✅ Automated	CloudTrail logs
10.3.6	Identity of affected data/resource	CloudTrail resources field	✅ Automated	CloudTrail logs

Additional Logging:

VPC Flow Logs: Network traffic (source IP, dest IP, ports, protocol)
ALB Access Logs: HTTP requests (client IP, request path, response code)

Infrastructure Implementation:

// PciDssRules.java:434-445 - VPC Flow Logs validation
if (!config.isFlowLogsEnabled()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-10.3-FlowLogs",
        "VPC Flow Logs must be enabled for network activity tracking"
    ));
}

Guard Policy: pci_vpc_flow_logs - TrafficType == 'ALL'

Testing Status: ✅ Production tested

10.4 - Audit Logs Protected from Modification

Sub-Requirement	Description	Implementation	Status	Evidence
10.4.1	Audit log files protected	S3 versioning, CloudTrail log validation	✅ Automated	S3 versioning, CloudTrail validation
10.4.2	Audit log files promptly backed up	S3 replication, cross-region backup	✅ Automated	S3 replication configuration
10.4.3	Audit logs written to secure centralized location	S3 buckets with encryption	✅ Automated	CloudTrail S3 bucket

Config Rules Deployed:

s3-bucket-versioning-enabled - S3 versioning for recovery

Guard Policy: pci_s3_versioning - VersioningConfiguration.Status == 'Enabled'

Testing Status: ✅ Production tested

10.5 - Audit Logs Retained and Protected

Sub-Requirement	Description	Implementation	Status	Evidence
10.5.1	Audit logs retained at least 12 months	S3 lifecycle policies (1+ year)	✅ Automated	`PciDssRules.java:448-459`

Infrastructure Implementation:

// PciDssRules.java:448-459 - ALB access logging validation
if (!config.isAlbAccessLoggingEnabled()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-10.5-ALB",
        "ALB access logging must be enabled for web traffic audit trails"
    ));
}

Testing Status: ✅ Production tested

10.6 - Audit Logs Reviewed Regularly

Sub-Requirement	Description	Implementation	Status	Evidence
10.6.1	Logs reviewed at least daily	❌ Manual process	❌ Manual	Log review records
10.6.2	Logs reviewed daily for critical systems	❌ Manual process	❌ Manual	Log review procedures
10.6.3	Log review exceptions flagged	CloudWatch Alarms for anomalies	⚠️ Partial	CloudWatch alarm configuration

Testing Status: ⚠️ Infrastructure alerting exists, manual review not implemented

Action Required: Implement daily log review process and document review records

10.7 - Audit Log History Retained

Sub-Requirement	Description	Implementation	Status	Evidence
10.7.1	Retain at least 12 months, 3 months online	S3 lifecycle with Glacier transition	✅ Automated	`PciDssRules.java:462-476`

Infrastructure Implementation:

// PciDssRules.java:462-476 - Log retention validation
var retentionDays = config.getLogRetentionDays();
if (!isRetentionSufficient(retentionDays)) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-10.7-Retention",
        "Log retention must be at least ONE_YEAR (365 days)",
        "Current: " + retentionDays.toString()
    ));
}

Retention Configuration:

CloudWatch Logs: 1 year minimum (configurable)
S3 Logs: Lifecycle policies with Glacier transition
CloudTrail: 90 days in CloudTrail, indefinite in S3

Guard Policy: pci_cloudwatch_logs_retention - RetentionInDays >= 365

Testing Status: ✅ Production tested

10.8 - Audit Mechanisms Protect Audit Data

Sub-Requirement	Description	Implementation	Status	Evidence
10.8.1	Log analysis tool access controlled	IAM policies for CloudWatch/S3 access	✅ Automated	IAM configuration

Testing Status: ✅ Production tested

Requirement 11: Test Security of Systems and Networks Regularly

11.1 - Processes for Testing Defined

Sub-Requirement	Description	Implementation	Status	Evidence
11.1.1	All security control testing documented	❌ Manual process	❌ Manual	Testing procedures document
11.1.2	Testing includes technology and process	❌ Manual process	❌ Manual	Testing plan

11.2 - Wireless Access Points Managed

Sub-Requirement	Description	Implementation	Status	Evidence
11.2.1	Wireless access points inventory	N/A (cloud infrastructure)	N/A	-

11.3 - Vulnerabilities Identified and Addressed

Sub-Requirement	Description	Implementation	Status	Evidence
11.3.1	Internal vulnerability scans quarterly	❌ Requires scanning tool	❌ Manual	Inspector (optional), third-party scanner
11.3.2	External vulnerability scans quarterly by ASV	❌ Requires ASV vendor	❌ Manual	ASV scan reports

Gap: Req 11.3 requires Approved Scanning Vendor (ASV) for external scans and internal vulnerability scanning tool.

Action Required: Engage ASV vendor for quarterly scans, implement vulnerability scanner (Inspector, Qualys, etc.)

11.4 - External and Internal Penetration Testing Performed

Sub-Requirement	Description	Implementation	Status	Evidence
11.4.1	Penetration testing performed	❌ Requires pen testers	❌ Manual	Penetration test reports
11.4.2	Internal penetration testing performed	❌ Requires pen testers	❌ Manual	Internal pen test reports
11.4.3	Remediation of vulnerabilities	❌ Manual process	❌ Manual	Remediation tracking

Gap: Req 11.4 requires annual penetration testing by qualified internal or third-party pen testers.

Action Required: Engage penetration testing firm, schedule annual tests

11.5 - Network Intrusion Detection Systems Deployed

Sub-Requirement	Description	Implementation	Status	Evidence
11.5.1	Intrusion-detection/prevention deployed	GuardDuty threat detection	✅ Automated	`PciDssRules.java:492-505`
11.5.2	IDPS mechanisms kept current	AWS-managed updates	✅ Automated	AWS GuardDuty service

Infrastructure Implementation:

// PciDssRules.java:492-505 - GuardDuty validation
if (!config.isGuardDutyEnabled()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-11.4-GuardDuty",
        "GuardDuty (threat detection) must be enabled for production",
        "GuardDutyEnabled"
    ));
}

Config Rule: guardduty-enabled-centralized - GuardDuty active

Testing Status: ✅ Production tested

11.6 - File Integrity Monitoring Deployed

Sub-Requirement	Description	Implementation	Status	Evidence
11.6.1	File integrity monitoring (FIM) deployed	Fargate immutable containers + AWS Config	⚠️ Alternative approach	`PciDssRules.java:508-519`

Alternative Approach:

Fargate: Immutable infrastructure prevents file modification
AWS Config: Tracks infrastructure configuration changes

Infrastructure Implementation:

// PciDssRules.java:522-534 - AWS Config validation
if (!config.isAwsConfigEnabled()) {
    rules.add(ComplianceRule.fail(
        "PCI-DSS-Req-11.6-Config",
        "AWS Config recommended for continuous compliance monitoring"
    ));
}

Testing Status: ⚠️ Alternative approach (not traditional FIM)

Action Required: Document alternative approach for QSA review

Requirement 12: Support Information Security with Organizational Policies and Programs

Note: Requirement 12 is entirely organizational/procedural and cannot be infrastructure-automated.

Sub-Requirement	Description	Implementation	Status	Evidence
12.1	Establish security policy	❌ Manual	❌ Manual	Information security policy document
12.2	Implement risk assessment	❌ Manual	❌ Manual	Annual risk assessment report
12.3	Usage policies for critical technologies	❌ Manual	❌ Manual	Acceptable use policy (AUP)
12.4	Ensure personnel aware of security	❌ Manual	❌ Manual	Security awareness training records
12.5	Assign security responsibilities	❌ Manual	❌ Manual	Security roles and responsibilities document
12.6	Security awareness program implemented	❌ Manual	❌ Manual	Training program documentation
12.7	Screen personnel prior to hire	❌ Manual	❌ Manual	Background check records
12.8	Service providers managed	❌ Manual	❌ Manual	Third-party risk assessment, contracts
12.9	Service providers acknowledge responsibility	❌ Manual	❌ Manual	Third-party agreements
12.10	Incident response plan implemented	❌ Manual	❌ Manual	Incident response plan document

Gap: Requirement 12 requires comprehensive organizational policies, procedures, and programs.

Action Required: Document all Req 12 policies and procedures (security policy, risk assessment, training, incident response, etc.)

Infrastructure Verification

AWS Config Rules Deployment

Base Controls (Always Deployed)

Rule Name	AWS Managed Rule	PCI-DSS Mapping	Purpose	Remediation
`encrypted-volumes`	`ENCRYPTED_VOLUMES`	Req 3.4	EBS encryption enforcement	Auto-enable via SSM
`s3-bucket-public-read-prohibited`	`S3_BUCKET_PUBLIC_READ_PROHIBITED`	Req 1.3, Req 7.2	S3 public read prevention	Manual
`s3-bucket-public-write-prohibited`	`S3_BUCKET_PUBLIC_WRITE_PROHIBITED`	Req 1.3, Req 7.2	S3 public write prevention	Manual
`iam-password-policy`	`IAM_PASSWORD_POLICY`	Req 8.2.3	Password complexity	Manual
`iam-user-mfa-enabled`	`IAM_USER_MFA_ENABLED`	Req 8.3.1	User MFA enforcement	Manual
`root-account-mfa-enabled`	`ROOT_ACCOUNT_MFA_ENABLED`	Req 8.3.1	Root account MFA	Manual
`access-keys-rotated`	`ACCESS_KEYS_ROTATED`	Req 8.2.4	90-day key rotation	Manual
`cloudtrail-enabled`	`CLOUD_TRAIL_ENABLED`	Req 10.2	API audit logging	Auto-enable via SSM
`vpc-flow-logs-enabled`	`VPC_FLOW_LOGS_ENABLED`	Req 10.3	Network traffic monitoring	Manual

PCI-DSS-Specific Controls (Conditional)

Rule Name	AWS Managed Rule	PCI-DSS Mapping	Purpose	Condition
`s3-bucket-versioning-enabled`	`S3_BUCKET_VERSIONING_ENABLED`	Req 9.5.1, Req 10.5	Backup and recovery	`pciDssCondition`
`s3-bucket-encryption`	`S3_DEFAULT_ENCRYPTION_KMS`	Req 3.4	S3 encryption	`pciDssCondition`
`guardduty-enabled-centralized`	`GUARDDUTY_ENABLED_CENTRALIZED`	Req 11.5	Threat detection	`pciDssCondition`
`kms-key-rotation-enabled`	`CMK_BACKING_KEY_ROTATION_ENABLED`	Req 3.6	Key management	`pciDssCondition`
`alb-http-to-https-redirection`	`ALB_HTTP_TO_HTTPS_REDIRECTION_CHECK`	Req 4.1	Force HTTPS	`pciDssCondition`
`rds-multi-az-support`	`RDS_MULTI_AZ_SUPPORT`	Business continuity	Database HA	`pciDssRdsCondition`
`rds-storage-encrypted`	`RDS_STORAGE_ENCRYPTED`	Req 3.4	Database encryption	`pciDssRdsCondition`
`rds-automated-backups`	`DB_LAST_BACKUP_RECOVERY_POINT_CREATED`	Req 9.5.1	Database backups	`pciDssRdsCondition`

Total Rules: 17 (9 base + 8 PCI-DSS-specific)

Deployment Logic: See ComplianceFactory.java:246-300

CloudFormation Guard Policies

File: pci-dss-v4.0.1.guard

Validation Rules (15 total):

Encryption at Rest (Req 3.4)

pci_s3_encryption (lines 32-34) - S3 BucketEncryption exists
pci_rds_encryption (lines 37-39) - RDS StorageEncrypted = true
pci_rds_cluster_encryption (lines 42-44) - RDS Cluster encrypted
pci_ebs_encryption (lines 47-49) - EBS Encrypted = true
pci_efs_encryption (lines 52-54) - EFS Encrypted = true
pci_dynamodb_encryption (lines 57-60) - DynamoDB SSEEnabled = true
pci_kms_key_rotation (lines 63-65) - KMS EnableKeyRotation = true

Encryption in Transit (Req 4.1)

pci_alb_https (lines 73-75) - ALB HTTPS/TLS on port 443

Network Security (Req 1.2.1, 1.3)

pci_rds_no_public_access (lines 82-85) - RDS not publicly accessible

Access Control (Req 7.1, 7.2)

pci_s3_block_public_access (lines 92-96) - S3 public access blocks

Authentication (Req 8.2, 8.3)

pci_cognito_mfa (lines 103-105) - Cognito MfaConfiguration in ['ON', 'OPTIONAL']

Audit Logging (Req 10.1, 10.2, 10.3)

pci_cloudtrail_enabled (lines 112-114) - CloudTrail IsLogging = true
pci_vpc_flow_logs (lines 117-119) - VPC Flow Logs TrafficType = 'ALL'

Log Retention (Req 10.7)

pci_cloudwatch_logs_retention (lines 126-129) - RetentionInDays >= 365

Backup & Recovery (Req 9.5.1, 10.5)

pci_s3_versioning (lines 136-139) - S3 versioning enabled
pci_rds_automated_backups (lines 142-145) - RDS BackupRetentionPeriod >= 7

Security Profile Enforcement

File: ProductionSecurityProfileConfiguration.java

Production Defaults for PCI-DSS:

Control	Configuration	Line	PCI-DSS Req	Overridable
Log Retention	1 year minimum (365+ days)	55	Req 10.7	Yes (via `logRetentionDays`)
Flow Logs	Enabled (all traffic)	80	Req 10.3	Yes (via `flowLogsEnabled`)
CloudTrail	Always enabled	114	Req 10.2	Yes (via `cloudTrailEnabled`)
GuardDuty	Always enabled	125	Req 11.5	Yes (via `guardDutyEnabled`)
AWS Config	Always enabled	134	Req 11.6	No
EBS Encryption	Mandatory	148	Req 3.4	No
EFS Encryption (transit)	Mandatory	162	Req 4.1	Yes
EFS Encryption (rest)	Mandatory	167	Req 3.4	No
S3 Encryption	Mandatory	172	Req 3.4	No
ALB Access Logging	Enabled	285	Req 10.5	Yes
MFA Required	Always	418	Req 8.3	No
Password Length	14 chars (exceeds 8 minimum)	449	Req 8.2.3	No
Password Rotation	90 days	443	Req 8.2.4	No
Password Reuse	4 passwords	Implementation	Req 8.2.4	No

Gap Analysis

Critical Gaps (Require Manual Implementation)

1. Application-Level Controls (Req 3 & 4)

Gap: PAN masking, data flow validation, data retention minimization

Impact: Core PCI-DSS requirements (~20% of Req 3)

Requirement:

Req 3.1: Data retention and disposal policy
Req 3.2: No sensitive authentication data stored post-authorization
Req 3.3: PAN masked when displayed (show max 6 digits)
Req 4.2: No PAN sent via unencrypted technologies (email, IM, SMS)

Remediation:

Priority: CRITICAL
Timeline: Immediate (before processing cardholder data)
Owner: Application Development Team

Tasks:
1. Implement PAN masking in all user interfaces and logs
2. Validate no sensitive authentication data (CVV, PIN) stored
3. Implement data retention policy (delete data no longer needed)
4. Audit all data flows to ensure no unencrypted PAN transmission
5. Code review focused on PCI-DSS Req 3 & 4 compliance

Evidence Required:

Application code review report
Data flow diagrams showing PAN handling
Data retention policy document
Masking validation screenshots

2. Organizational Policies (Req 12)

Gap: Security policy, risk assessment, training, incident response

Impact: Entire Requirement 12 (~15% of total requirements)

Remediation:

Priority: HIGH
Timeline: 4-8 weeks
Owner: CISO + Compliance Officer

Tasks:
1. Write information security policy manual
2. Conduct annual risk assessment
3. Create acceptable use policy (AUP)
4. Develop security awareness training program
5. Document incident response plan
6. Create vendor management procedures
7. Implement background check process

Evidence Required:

Information security policy (board-approved)
Annual risk assessment report
Acceptable use policy
Training records (attendance, test scores)
Incident response plan
Vendor contracts with PCI-DSS clauses
Background check records

3. Testing & Validation (Req 11)

Gap: ASV scans, penetration testing, vulnerability scans

Impact: ~40% of Requirement 11

Remediation:

Priority: HIGH
Timeline: Immediate (quarterly scans required)
Owner: Security Team

Tasks:
1. Engage Approved Scanning Vendor (ASV) for external scans
2. Schedule quarterly ASV scans
3. Engage penetration testing firm
4. Schedule annual penetration tests
5. Implement vulnerability scanner (AWS Inspector, Qualys, etc.)
6. Conduct quarterly internal vulnerability scans

Evidence Required:

ASV scan reports (quarterly, passing)
Penetration test reports (annual)
Internal vulnerability scan reports (quarterly)
Remediation tracking for findings

4. Operational Procedures (Req 5, Req 6, Req 7)

Gap: Anti-malware management, secure SDLC, access reviews

Impact: ~25% of requirements

Remediation:

Priority: MEDIUM
Timeline: 4-6 weeks
Owner: Security Team + Engineering

Tasks:
1. Document alternative anti-malware approach (Fargate + GuardDuty)
2. Create secure development lifecycle (SDLC) documentation
3. Implement quarterly access reviews
4. Document code review process (Req 6.4.2 alternative to WAF)
5. Create software inventory and SBOM

Evidence Required:

Anti-malware alternative approach documentation
SDLC policy document
Quarterly access review records
Code review reports
Software inventory

Partial Gaps (Enhance Existing Controls)

1. Authentication Testing (Req 8)

Current State: Cognito and OIDC implemented but not production-tested

Gap: Production validation of MFA enforcement

Remediation:

Priority: HIGH
Timeline: 1-2 weeks
Owner: Engineering

Tasks:
1. Test Cognito User Pool with MFA in production
2. Validate TOTP MFA enrollment and challenge
3. Validate SMS MFA enrollment and challenge
4. Test Identity Center MFA integration
5. Verify session timeout enforcement
6. Test password policy enforcement
7. Document authentication flows

2. WAF Implementation (Req 6.4)

Current State: ✅ WAF REQUIRED and enforced in PRODUCTION

Validation: Automated enforcement via PciDssRules.java:317-334

Evidence: 34 WAF test cases in compliance-test-matrix.csv

Status: ✅ Fully Implemented

Deployment:

✅ WAF enabled by default in PRODUCTION security profile
✅ Validation fails if WAF disabled with PCI-DSS framework
✅ Comprehensive test coverage (EC2, FARGATE, multi-framework scenarios)
⏭️ Configure WAF rules (SQL injection, XSS, known bad inputs) - operational task
⏭️ Monitor WAF logs and tune rules - operational task

3. Daily Log Review (Req 10.6)

Current State: Logs collected, alerting exists, but no daily review process

Gap: Manual review procedures not documented

Remediation:

Priority: MEDIUM
Timeline: 2 weeks
Owner: Security Operations

Tasks:
1. Create log review procedures
2. Assign log review responsibilities
3. Create log review checklist
4. Implement log review tracking (tickets, spreadsheet)
5. Train personnel on log review

Coverage Metrics

Overall PCI-DSS Coverage

Requirement	Total Sub-Requirements	Automated	Partial	Manual	Coverage %
Req 1 - Network Security	~20	15	2	3	~85%
Req 2 - Secure Configurations	~12	6	4	2	~83%
Req 3 - Protect Stored Data	~15	3	0	12	~20%
Req 4 - Protect Transmitted Data	~8	5	0	3	~63%
Req 5 - Anti-Malware	~10	5	2	3	~70%
Req 6 - Secure Systems	~25	5	5	15	~40%
Req 7 - Restrict Access	~15	10	1	4	~73%
Req 8 - Identify/Authenticate	~20	8	6	6	~70%
Req 9 - Physical Access	~15	15 (AWS)	0	0	100% (AWS)
Req 10 - Log and Monitor	~20	15	3	2	~90%
Req 11 - Test Security	~15	5	2	8	~47%
Req 12 - Info Security Policy	~25	0	0	25	0%
TOTAL	~200	~92	~25	~83	~59%

Note: These percentages reflect infrastructure automation. PCI-DSS requires significant application-level and organizational controls.

Infrastructure Coverage

Automatable Technical Controls: ~110-120 controls Automated: ~92 controls Infrastructure Coverage: ~77% ✅

Testing Coverage

Control Category	Implemented	Production Tested	Status
Encryption (at-rest)	✅ Yes	✅ Yes	Complete
Encryption (in-transit)	✅ Yes	✅ Yes	Complete
Network Security	✅ Yes	✅ Yes	Complete
Access Control (IAM)	✅ Yes	✅ Yes	Complete
Authentication (Cognito/OIDC)	✅ Yes	⚠️ No	Action Required
MFA (Cognito/Identity Center)	✅ Yes	⚠️ No	Action Required
Audit Logging	✅ Yes	✅ Yes	Complete
Threat Detection (GuardDuty)	✅ Yes	✅ Yes	Complete
Intrusion Detection	✅ Yes	✅ Yes	Complete
Configuration Monitoring	✅ Yes	✅ Yes	Complete
WAF	✅ Yes	⚠️ Optional	Decision Required

Remediation Roadmap

Phase 1: Critical Gaps (Weeks 1-8)

Goal: Address mandatory controls required for PCI-DSS compliance

Task	Owner	Timeline	Deliverable
Application PAN masking (Req 3.3)	Application Dev	Weeks 1-2	Code review, masking validation
Data retention policy (Req 3.1)	Compliance	Week 1	Policy document
Sensitive auth data validation (Req 3.2)	Application Dev	Week 2	Code audit report
WAF decision and implementation (Req 6.4)	Security + Engineering	Weeks 1-2	WAF enabled OR code review process
Authentication testing (Req 8)	Engineering	Weeks 1-2	Test report, MFA validation
Engage ASV vendor (Req 11.3.2)	Security	Week 1	ASV contract, scan schedule
Information security policy (Req 12.1)	CISO + Compliance	Weeks 1-4	Policy document (board-approved)
Incident response plan (Req 12.10)	Security	Weeks 2-3	IRP document, playbooks

Success Criteria: Core technical controls operational, policies documented, ASV scans scheduled

Phase 2: Operational Controls (Weeks 9-16)

Goal: Implement operational procedures and testing

Task	Owner	Timeline	Deliverable
Penetration testing (Req 11.4)	Security	Weeks 9-12	Pen test contract, annual schedule
Internal vulnerability scans (Req 11.3.1)	Security	Weeks 9-10	Scanner implementation, scan reports
Security awareness training (Req 12.6)	HR + Security	Weeks 10-14	Training program, attendance records
Quarterly access reviews (Req 7.2.4)	Security	Weeks 12-13	Access review process, first review
Daily log review process (Req 10.6)	SecOps	Weeks 14-15	Review procedures, tracking system
Vendor management (Req 12.8)	Procurement + Security	Weeks 10-16	Vendor assessments, contracts

Success Criteria: All operational procedures documented, testing scheduled, first reviews completed

Phase 3: Continuous Compliance (Ongoing)

Goal: Maintain compliance, conduct regular assessments

Task	Frequency	Owner	Deliverable
ASV external scans	Quarterly	Security	ASV scan reports (passing)
Internal vulnerability scans	Quarterly	Security	Internal scan reports
Penetration testing	Annual	Security	Penetration test reports
Risk assessments	Annual	Compliance	Risk assessment report
Access reviews	Quarterly	Security	Access review records
Log reviews	Daily	SecOps	Log review tickets
Policy reviews	Annual	Compliance + Legal	Updated policy documents
Security training	Annual (new hires: immediate)	HR	Training records
Audit Manager evidence collection	Continuous	Automated	Evidence in S3 buckets

Success Criteria: Continuous compliance monitoring, quarterly/annual assessments on schedule, all evidence collected

Testing Status

Production-Tested Controls ✅

Control	Test Environment	Test Date	Status
EBS Encryption	Production	2025-Q4	✅ Pass
EFS Encryption (at-rest)	Production	2025-Q4	✅ Pass
EFS Encryption (in-transit)	Production	2025-Q4	✅ Pass
S3 Encryption	Production	2025-Q4	✅ Pass
RDS Encryption	Production	2025-Q4	✅ Pass
TLS/SSL (ALB)	Production	2025-Q4	✅ Pass
VPC Network Segmentation	Production	2025-Q4	✅ Pass
Security Groups	Production	2025-Q4	✅ Pass
IAM Password Policy	Production	2025-Q4	✅ Pass
IAM MFA Enforcement	Production	2025-Q4	✅ Pass
Access Key Rotation	Production	2025-Q4	✅ Pass
CloudTrail Logging	Production	2025-Q4	✅ Pass
VPC Flow Logs	Production	2025-Q4	✅ Pass
ALB Access Logs	Production	2025-Q4	✅ Pass
GuardDuty	Production	2025-Q4	✅ Pass
AWS Config (17 rules)	Production	2025-Q4	✅ Pass
Log Retention (1+ year)	Production	2025-Q4	✅ Pass

Not Yet Tested (Implemented) ⚠️

Control	Implementation Status	Test Requirement	Priority
Cognito Authentication	✅ Implemented	Production user registration/login	HIGH
Cognito MFA (TOTP)	✅ Implemented	MFA enrollment and challenge	HIGH
Cognito MFA (SMS)	✅ Implemented	SMS MFA flow	HIGH
Identity Center MFA	✅ Implemented	ALB-OIDC with Identity Center	HIGH
WAF Rules	✅ Implemented	SQL injection, XSS protection	HIGH
WAF Decision	⚠️ Optional	Enable WAF OR document code review	CRITICAL

Cardholder Data Environment (CDE) Scope

Defining Your CDE

Critical: PCI-DSS applies only to systems that store, process, or transmit cardholder data.

CDE Components:

System Components: Servers, containers, databases that handle cardholder data
Network Components: VPC, subnets, security groups protecting CDE
Connected-to or Security-Affecting Systems: Logging, monitoring, authentication

CloudForge CI CDE Scope:

In-Scope: Fargate/EC2 instances running application, EFS storage, ALB, VPC
Connected Systems: CloudTrail, GuardDuty, AWS Config, IAM
Out-of-Scope: Development environments (if not processing real card data)

Scope Reduction Strategies

Network Segmentation: Isolate CDE from non-CDE systems (✅ implemented via VPC)
Data Flow Minimization: Only transmit PAN where necessary (application responsibility)
Tokenization/P2PE: Use payment processor tokenization (application implementation)
Segmented Environments: Separate dev/test/prod (recommended architecture)

Action Required: Document CDE scope diagram showing all in-scope systems

Maintenance & Updates

Document Review Schedule

Review Type	Frequency	Owner	Next Review
Gap Analysis Update	Quarterly	Compliance Officer	2026-03-19
Control Mapping Verification	Quarterly	Security Team	2026-03-19
Testing Status Update	Monthly	Engineering Manager	2026-01-19
Remediation Roadmap Progress	Monthly	Project Manager	2026-01-19
PCI-DSS Framework Updates	Annually (or when released)	Compliance Officer	2026-12-19
v4.0 Mandatory Requirement Check	✅ Complete (deadline passed)	Compliance Officer	Passed: 2025-03-31

Change Log

Version	Date	Changes	Author
1.0	2025-12-14	Initial comprehensive PCI-DSS gap analysis (v4.0.1)	Claude (AI-assisted)
1.1	2025-12-19	Updated review schedule; noted March 31, 2025 v4.0 deadline has passed - all requirements now mandatory	Claude (AI-assisted)
1.2	2025-12-28	Updated WAF requirement from optional to REQUIRED; added evidence references for 34 WAF test cases and validation enforcement	Claude (AI-assisted)

PCI-DSS v4.0 Mandatory Requirements (Effective March 31, 2025)

STATUS: ✅ These requirements are now MANDATORY (deadline passed March 31, 2025):

Deadline	Requirement	Status
March 31, 2025 ✅	51 "best practice" requirements now mandatory	Verify all v4.0 requirements are implemented
March 31, 2025 ✅	Req 8.4.2 - MFA for all CDE access	Validate MFA enforcement for all CDE access
March 31, 2025 ✅	Req 8.4.3 - MFA replay resistance	Verify TOTP or phishing-resistant MFA in use
March 31, 2025 ✅	Req 8.5.1 - Phishing-resistant MFA for third parties (if applicable)	Verify WebAuthn/FIDO2 MFA implementation

Action Required: Conduct gap assessment to confirm all mandatory v4.0 requirements are fully implemented

References

Official PCI-DSS Documentation

PCI DSS v4.0.1 (Official Standard, June 2024)
Summary of Changes from PCI DSS v3.2.1 to v4.0
PCI DSS v4.x Resource Hub
PCI DSS 4.0 Mandatory Requirements: 2025 Compliance Guide
How to Comply with PCI DSS 4.0.1 (2025 Guide)

Internal Documentation

Code References

PciDssRules.java - Validation rules
pci-dss-v4.0.1.guard - Guard policies
ComplianceFactory.java - AWS Config deployment
ProductionSecurityProfileConfiguration.java - Security defaults
AuditManagerControlRegistry.java - Control mapping

Appendix: Quick Reference

PCI-DSS Compliance Checklist

Infrastructure Controls (Automated) ✅

Req 1: VPC, security groups, network segmentation
Req 2: Secure configurations, minimal services
Req 3.4: Encryption at rest (EBS, EFS, S3, RDS)
Req 4.1: Encryption in transit (TLS 1.2+)
Req 7: IAM access control, least privilege
Req 8: IAM password policy, MFA enforcement
Req 10: CloudTrail, Flow Logs, ALB logs (1+ year retention)
Req 11.5: GuardDuty intrusion detection

Application-Level Controls (Manual) ❌

Req 3.1: Data retention policy
Req 3.2: No sensitive auth data stored
Req 3.3: PAN masking (max 6 digits displayed)
Req 4.2: No unencrypted PAN transmission
Req 6.2: Secure SDLC, code review

Operational Controls (Manual) ❌

Req 5: Anti-malware documentation (or alternative approach)
Req 6.4: WAF enabled OR quarterly code review
Req 7.2.4: Quarterly access reviews
Req 8: MFA testing (Cognito/Identity Center)
Req 10.6: Daily log review process
Req 11.3: ASV scans (quarterly)
Req 11.4: Penetration testing (annual)
Req 12: All policies and procedures

Document End

For questions or updates to this document, contact the Security & Compliance Team.

For QSA assessments, provide this document along with evidence artifacts (scan reports, policies, test results).

Document Purpose​

Table of Contents​

Executive Summary​

Overall Coverage​

Key Strengths​

Critical Gaps​

PCI-DSS Framework Overview​

Framework Structure​

Build and Maintain a Secure Network and Systems​

Protect Account Data​

Maintain a Vulnerability Management Program​

Implement Strong Access Control Measures​

Regularly Monitor and Test Networks​

Maintain an Information Security Policy​

Key Changes in PCI-DSS v4.0​

Implementation Architecture​

Layer 1: Validation Rules (Pre-Synthesis)​

Layer 2: CloudFormation Guard Policies (Pre-Deployment)​

Layer 3: AWS Config Rules (Runtime Monitoring)​

Layer 4: Security Profile Configuration (Infrastructure Defaults)​

Detailed Control Mapping​

Requirement 1: Install and Maintain Network Security Controls​

1.1 - Network Security Controls Defined and Implemented​

1.2 - Network Security Controls Applied​

1.3 - Network Access to Cardholder Data Environment Restricted​

1.4 - Network Connections Between Trusted/Untrusted Networks Controlled​

1.5 - Risks to CDE from Computing Devices Managed​

Requirement 2: Apply Secure Configurations to All System Components​

2.1 - Vendor Defaults Changed Before Production​

2.2 - Configuration Standards Developed​

2.3 - Wireless Environments Configured Securely​

2.4 - Inventory of System Components Maintained​

Requirement 3: Protect Stored Account Data​

3.1 - Account Data Storage Minimized​

3.2 - Sensitive Authentication Data Not Stored After Authorization​

3.3 - PAN Masked When Displayed​

3.4 - PAN Rendered Unreadable Anywhere Stored​

3.5 - Cryptographic Keys Protected​

3.6 - Key Management Procedures Implemented​

3.7 - Cryptography and Key Management Fully Documented​

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission​

4.1 - Strong Cryptography and Security Protocols Used​

4.2 - PAN Never Sent Via Unencrypted Technologies​

Requirement 5: Protect All Systems and Networks from Malicious Software​

5.1 - Anti-Malware Mechanisms Deployed​

5.2 - Anti-Malware Mechanisms Configured Correctly​

5.3 - Anti-Malware Mechanisms Maintained​

Requirement 6: Develop and Maintain Secure Systems and Software​

6.1 - Security Vulnerabilities Identified and Addressed​

6.2 - Bespoke Software Developed Securely​

6.3 - Security Vulnerabilities Managed​

6.4 - Public-Facing Web Applications Protected​

6.5 - Changes to System Components Managed Securely​

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know​

7.1 - Processes for Granting Access Defined​

7.2 - Access Based on Business Need to Know​

7.3 - Access to System Components Recorded​

Requirement 8: Identify Users and Authenticate Access to System Components​

8.1 - Processes for User Identification Defined​

8.2 - User Authentication Managed​

8.3 - Multi-Factor Authentication (MFA) Implemented​

8.4 - MFA Systems Configured Correctly​

8.5 - MFA Use by Third Parties​

8.6 - Use of Application and System Accounts Managed​

Requirement 9: Restrict Physical Access to Cardholder Data​

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data​

10.1 - Processes for Logging Defined​

10.2 - Audit Logs Capture Required Details​

10.3 - Audit Logs Include Required Details​

10.4 - Audit Logs Protected from Modification​

10.5 - Audit Logs Retained and Protected​

10.6 - Audit Logs Reviewed Regularly​

10.7 - Audit Log History Retained​

10.8 - Audit Mechanisms Protect Audit Data​

Requirement 11: Test Security of Systems and Networks Regularly​

11.1 - Processes for Testing Defined​

11.2 - Wireless Access Points Managed​

11.3 - Vulnerabilities Identified and Addressed​

11.4 - External and Internal Penetration Testing Performed​

11.5 - Network Intrusion Detection Systems Deployed​

Document Purpose

Table of Contents

Executive Summary

Overall Coverage

Key Strengths

Critical Gaps

PCI-DSS Framework Overview

Framework Structure

Build and Maintain a Secure Network and Systems

Protect Account Data

Maintain a Vulnerability Management Program

Implement Strong Access Control Measures

Regularly Monitor and Test Networks

Maintain an Information Security Policy

Key Changes in PCI-DSS v4.0

Implementation Architecture

Layer 1: Validation Rules (Pre-Synthesis)

Layer 2: CloudFormation Guard Policies (Pre-Deployment)

Layer 3: AWS Config Rules (Runtime Monitoring)

Layer 4: Security Profile Configuration (Infrastructure Defaults)

Detailed Control Mapping

Requirement 1: Install and Maintain Network Security Controls

1.1 - Network Security Controls Defined and Implemented

1.2 - Network Security Controls Applied

1.3 - Network Access to Cardholder Data Environment Restricted

1.4 - Network Connections Between Trusted/Untrusted Networks Controlled

1.5 - Risks to CDE from Computing Devices Managed

Requirement 2: Apply Secure Configurations to All System Components

2.1 - Vendor Defaults Changed Before Production

2.2 - Configuration Standards Developed

2.3 - Wireless Environments Configured Securely

2.4 - Inventory of System Components Maintained

Requirement 3: Protect Stored Account Data

3.1 - Account Data Storage Minimized

3.2 - Sensitive Authentication Data Not Stored After Authorization

3.3 - PAN Masked When Displayed

3.4 - PAN Rendered Unreadable Anywhere Stored

3.5 - Cryptographic Keys Protected

3.6 - Key Management Procedures Implemented

3.7 - Cryptography and Key Management Fully Documented

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission

4.1 - Strong Cryptography and Security Protocols Used

4.2 - PAN Never Sent Via Unencrypted Technologies

Requirement 5: Protect All Systems and Networks from Malicious Software

5.1 - Anti-Malware Mechanisms Deployed

5.2 - Anti-Malware Mechanisms Configured Correctly

5.3 - Anti-Malware Mechanisms Maintained

Requirement 6: Develop and Maintain Secure Systems and Software

6.1 - Security Vulnerabilities Identified and Addressed

6.2 - Bespoke Software Developed Securely

6.3 - Security Vulnerabilities Managed

6.4 - Public-Facing Web Applications Protected

6.5 - Changes to System Components Managed Securely

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

7.1 - Processes for Granting Access Defined

7.2 - Access Based on Business Need to Know

7.3 - Access to System Components Recorded

Requirement 8: Identify Users and Authenticate Access to System Components

8.1 - Processes for User Identification Defined

8.2 - User Authentication Managed

8.3 - Multi-Factor Authentication (MFA) Implemented

8.4 - MFA Systems Configured Correctly

8.5 - MFA Use by Third Parties

8.6 - Use of Application and System Accounts Managed

Requirement 9: Restrict Physical Access to Cardholder Data

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

10.1 - Processes for Logging Defined

10.2 - Audit Logs Capture Required Details

10.3 - Audit Logs Include Required Details

10.4 - Audit Logs Protected from Modification

10.5 - Audit Logs Retained and Protected

10.6 - Audit Logs Reviewed Regularly

10.7 - Audit Log History Retained

10.8 - Audit Mechanisms Protect Audit Data

Requirement 11: Test Security of Systems and Networks Regularly

11.1 - Processes for Testing Defined

11.2 - Wireless Access Points Managed

11.3 - Vulnerabilities Identified and Addressed

11.4 - External and Internal Penetration Testing Performed

11.5 - Network Intrusion Detection Systems Deployed