PCI DSS Reassessment Triggers on AWS: When Architecture Changes Need Review

The Annual Assessment Misconception

PCI DSS requires an annual assessment — but this is a minimum frequency, not a maximum. The standard (Req 12.3.1) requires a targeted risk analysis to be performed whenever environmental or operational changes occur that could affect the security of cardholder data. For AWS-hosted environments, where infrastructure changes can be deployed in minutes, this creates a continuous obligation that many entities and their assessors may consider as an annual exercise.

The risk: An entity undergoes a major architectural change after their annual assessment — migrating from EC2 to ECS, adding a new AWS region, or integrating a new payment processor. They continue operating under the prior AOC. Their acquirer is later notified of a breach. The acquirer's forensic investigation finds that the breach exploited a control gap introduced by the architecture change — a gap that a delta assessment would have caught. The entity's liability is materially increased by the failure to re-assess.

Triggers Requiring a Full Re-Assessment

The following changes on AWS invalidate the prior assessment's scoping decisions sufficiently to require a full re-assessment — not a delta. A full re-assessment is required when the change affects the fundamental architecture of the CDE, the segmentation controls, or the trust boundary between in-scope and out-of-scope systems.

New AWS region added to CDE

Adding a new AWS region that will process, store, or transmit cardholder data introduces a new network boundary, new IAM scope, new logging configuration, and new physical location. The prior assessment's segmentation validation does not cover the new region. Full re-assessment required before CHD flows to the new region.

Acquisition or merger adding AWS accounts

Merging AWS accounts or adding accounts from an acquired entity into the organisation introduces systems with unknown security posture into the AWS Organization. All accounts that touch or could touch CDE must be assessed before being added to the organisation's AOC scope.

New payment processor or card scheme integration

Adding a new payment processor integration changes the trust boundary — new network flows, new credential management requirements, new TPSP obligations. This is a scope expansion requiring re-assessment of the affected components.

Migration from PaaS to IaaS (or vice versa)

Migrating from managed services (RDS, ECS Fargate) to self-managed infrastructure (EC2, self-managed containers) shifts the shared responsibility boundary — the entity takes on OS-level and container-level controls that were previously AWS's responsibility. New control gaps require full assessment of the migrated components.

Change of key management provider

Moving from AWS-managed KMS keys to CMKs, or from KMS to an external HSM, changes the cryptographic architecture and key management procedures. Req 3.7 controls require re-validation when the key management approach changes.

Removal of network segmentation control

Any change that connects previously segmented CDE networks to non-CDE networks — removing a VPC boundary, enabling VPC peering, adding a Transit Gateway — requires immediate re-assessment of segmentation. This includes "temporary" changes for maintenance.

Triggers Requiring a Delta Assessment

A delta assessment covers a defined subset of requirements affected by a specific change. It supplements rather than replaces the prior assessment. The following changes typically warrant a delta assessment:

Change	Affected requirements	Delta scope	Pre-go-live or post-go-live?
New web application or API added to CDE	6.x (secure development), 11.x (security testing), 1.x (network controls)	Application security controls, WAF rules, pen test of new application	Pre-go-live — application must be assessed before CHD flows through it
New IAM role or permission boundary change affecting CDE access	7.x (access control), 8.x (user management)	Role policy review, least privilege validation, MFA enforcement	Pre-go-live for new roles; post-change for modified roles with 30-day window
New CloudTrail configuration or logging change	10.x (logging and monitoring)	Log completeness, integrity validation, retention policy, alert coverage	Post-change within 30 days
Patch or OS upgrade on in-scope EC2 instances	2.2.x (secure configuration), 6.3.x (vulnerability management)	Configuration baseline re-validation, patch compliance evidence	Post-change within 30 days
New third-party script on payment page	6.4.3, 11.6.1 (payment page integrity)	Script inventory update, SRI implementation, CSP update, monitoring confirmation	Pre-go-live — script must be assessed before it is served on the payment page
Change to encryption algorithm or TLS configuration	4.2.x (encryption in transit), 3.4.x (encryption at rest)	Cipher suite review, certificate validation, deprecated algorithm removal evidence	Pre-go-live for client-facing changes; post-change within 14 days for internal

The QSA's Decision Framework

When a client notifies a QSA of an architecture change, the following decision framework determines the appropriate response:

Does the change affect the CDE boundary?

If the change adds, removes, or modifies a system component that processes, stores, or transmits CHD — or adds a new network path to such a component — the CDE boundary has changed. Any boundary change requires at minimum a delta assessment. If the change expands the boundary significantly (new region, new account), a full re-assessment is required.

Does the change affect segmentation controls?

Segmentation controls are the network-layer controls that prevent out-of-scope systems from communicating with the CDE. Any change to VPC configuration, security group rules, NACLs, Transit Gateway routing, or VPC peering that could affect segmentation requires re-validation of segmentation — even if the change was intended to be additive rather than permissive.

Does the change introduce a new TPSP into scope?

Adding a new third-party service provider that touches CHD — a new payment gateway, a new fraud detection service, a new analytics platform receiving transaction data — requires: (a) TPSP due diligence, (b) written agreement covering PCI DSS obligations, and (c) delta assessment of the integration's controls. The AOC must be updated to reflect the new TPSP.

Does the change affect a control relied upon in the prior assessment?

If the prior assessment relied on a specific control — a WAF rule set, a specific KMS configuration, a specific IAM policy — and that control has changed, the assessment finding that relied on it is no longer valid. A delta assessment must re-test the affected requirement.

Document the determination regardless of outcome

Even if the determination is "no delta assessment required," the QSA should produce a written determination documenting the change, the analysis performed, and the conclusion. This provides evidence that the entity's change management process engaged the QSA — satisfying Req 6.5.1 and 12.3.1 documentation requirements.

AWS Services That Signal a Re-Assessment Trigger

The following CloudTrail events and AWS Config changes, when detected in a CDE account, should automatically trigger a re-assessment review notification to the QSA. Entities should configure CloudWatch alarms for these events:

CloudTrail event / Config change	Potential trigger	Review action
CreateVpc, CreateSubnet, CreateInternetGateway	New network components — potential CDE expansion	Confirm new VPC is out of scope OR begin scoping review for new VPC
AuthorizeSecurityGroupIngress (0.0.0.0/0)	New public-facing ingress — potential CDE exposure	Verify rule applies only to non-CDE components; confirm WAF covers new endpoint
CreateVpcPeeringConnection, AcceptVpcPeeringConnection	New VPC peering — potential segmentation impact	Review routing tables to confirm peering does not enable CDE-to-non-CDE routing
CreateDBInstance, RestoreDBInstanceFromDBSnapshot	New RDS instance — potential CHD store	Confirm new instance is not in scope OR begin assessment of storage controls
PutBucketPolicy (with AllowPublic or s3:GetObject /**)	S3 bucket made public — potential CHD exposure	Immediate review; confirm bucket contains no CHD
CreateFunction (Lambda)	New Lambda function — potential CHD processing	Confirm function is not in CDE data path OR begin assessment of function controls
CreateTrail (with IsMultiRegionTrail=false)	Single-region trail created — potential logging gap	Verify all CDE regions covered by a multi-region trail
StopLogging	CloudTrail logging stopped — audit log gap	Immediate alert; investigate reason and restore logging; review for data loss window

Practical recommendation: Include a clause in your engagement letter requiring the client to notify you within 5 business days of any architecture change that adds a new AWS service to the CDE, adds a new AWS region, or modifies network segmentation. Without this clause, the QSA has no contractual right to conduct a delta assessment before the change goes live — and no protection if the change introduces a gap that is later exploited.

Payment Architecture & Evidence Workspace

Turn this guidance into a structured decision

Open the relevant workspace tool to apply the article to your payment environment. Eligible membership access may be required; the tool page shows access before you begin.

Architecture Change Impact Analyser

Assess the PCI DSS impact of a proposed architecture change — identify which requirements are affected, whether a delta assessment is required, and what evidence the client must produce before go-live.