Change Management
Change management is a foundational security and governance process that ensures all changes to systems, applications, infrastructure, and configurations are formally reviewed, tested, approved, implemented, and documented in a controlled manner. The objective of change management within PCI DSS is to prevent unauthorized or poorly managed changes from introducing security vulnerabilities, disrupting services, or compromising the confidentiality and integrity of the cardholder data environment (CDE). Effective change management provides traceability and accountability by requiring organizations to assess security impacts, obtain approvals, perform testing, maintain rollback procedures, and document implementation activities to ensure compliance and operational stability.
Change Management within the AWS SRA
The AWS SRA provides foundational guidance for change management that directly supports key elements of PCI DSS:
AWS Config in security tooling account can be used to assess, audit, and evaluate the configurations of supported AWS resources in AWS accounts. AWS config provides the foundational change detection and configuration compliance mechanism prescribed by the AWS SRA. Using AWS Config in proactive mode, organizations can evaluate resource configurations before deployment, preventing non-compliant changes from reaching production environments (Requirement 6.5.1). In detective mode, Config continuously evaluates deployed configurations against defined rules, identifying unauthorized or unintended changes. Config integrates with AWS Systems Manager Automation runbooks for automated remediation of non-compliant configurations, creating a closed-loop change validation system (Requirement 6.5.2). The AWS SRA deploys Config across all accounts with the Security Tooling account serving as delegated administrator, providing organization-wide visibility into configuration changes.
AWS CloudTrail in security tooling account is a service that supports governance, compliance, and auditing of activity for AWS account, providing monitoring through an organization trail that logs all events for all AWS accounts in that AWS organization. AWS CloudTrail records all API calls across the organization trail, providing the audit trail necessary to demonstrate that all changes to system components follow established change control procedures (Requirement 6.5.1). CloudTrail logs capture who made changes, what was changed, when changes occurred, and from where, supporting the documentation requirements for change records. Logs are delivered to the centralized Log Archive account with integrity validation enabled.
AWS Organizations is referenced as AWS SRA building block which aids in centrally managing and governing the environment as additional AWS resources are deployed, while also providing several policies that enable centrally applying additional security controls to all member accounts in the organization. Service Control Policies (SCPs) deployed through AWS Organizations provide the structural foundation for separating production and non-production environments, as required by PCI DSS Requirement 6.5.2. The AWS SRA prescribes distinct organizational units for different environment types, with SCPs enforcing preventive guardrails that restrict which APIs can be called and prevent disabling of security services. SCPs are applied from the Org Management account and inherited by all member accounts, ensuring that environment separation controls cannot be overridden at the account level.
AWS Systems Manager in infrastructure account, is referenced as a network and application protection service which provides a collection of capabilities that enable visibility and control of AWS resources while supporting a number of preventive, detective, and responsive security features. AWS Systems Manager Session manager is a feature of AWS Systems Manager which provides secure, auditable remote access to EC2 instances without opening inbound SSH ports, managing SSH keys, or deploying bastion hosts (Requirement 6.5.1 Changes to all system components in the production environment are made according to established procedures that include: 1/ reason for, and description of, the change, 2/ documentation of security impact, 3/ documented change approval by authorized parties, and 4/ testing to verify that the change does not adversely impact system security.) All sessions are logged and auditable, supporting the requirement 6.4 that production data and accounts are not used in pre-production environments and that access to production systems follows controlled processes. Session Manager operates through VPC endpoints, maintaining private connectivity.
Change Management beyond the AWS SRA
Some incremental enhancements may be needed to extend the AWS SRA for alignment with additional PCI DSS requirement elements:
Configure AWS Config for change control validation: Deploy custom AWS Config and conformance packs that validate all changes to in-scope system components comply with established change control requirements (Requirement 6.5.1). Create Config rules that detect unauthorized modifications to security-relevant configurations including security group rules, IAM policies, encryption settings, and network ACLs. Pair detective Config rules with AWS Systems Manager Automation runbooks to automatically revert unauthorized changes or quarantine non-compliant resources. Route Config compliance change events through Amazon EventBridge to notify security teams and create audit records in Amazon CloudWatch Logs and Amazon S3 (Requirement 6.5.2). Deploy proactive Config rules using AWS CloudFormation Guard within deployment pipelines to evaluate resource configurations before provisioning, preventing non-compliant changes from being deployed to production.
Configure IAM Access Analyzer custom policy checks in deployment pipelines: Integrate IAM Access Analyzer custom policy checks with AWS CloudFormation to automate policy reviews within CI/CD pipelines (Requirement 6.5.1). Configure the CheckNoNewAccess API to compare proposed IAM policy changes against established reference policies, blocking deployments that introduce unintended privilege escalation. Configure the CheckAccessNotGranted API to validate that deployments do not grant access to defined critical actions or resources within the CDE. This ensures that access control changes undergo automated security validation before reaching production, supporting the requirement that change control processes confirm security controls are not adversely impacted.
Deploy AWS CloudFormation Guard for pre-deployment compliance validation: Implement AWS CloudFormation Guard rules within CI/CD pipelines to evaluate infrastructure-as-code templates against PCI DSS security requirements before resource provisioning (Requirement 6.5.1). Create Guard rule sets that validate encryption configurations, network segmentation controls, logging enablement, and access restrictions. Integrate Guard with cdk-nag for AWS CDK
Enable separation of development/test and production environments: Configure AWS Organizations organizational unit (OU) structure with separate OUs for development, test, and production workloads, enforcing environment isolation through Service Control Policies (SCPs) (Requirement 6.5.3). Deploy AWS Config to detect and alert on any cross-environment access patterns or data flows between non-production and production accounts. Use AWS Secrets Manager to manage environment-specific credentials, supporting environment promotion (dev to pre-prod to prod) without code changes while maintaining strict separation of authentication material (Requirement 6.5.4). Configure SCPs to prevent production account access from development IAM principals and restrict data copying between environments.
Implement change impact analysis and rollback capabilities: Configure AWS Config advanced queries and configuration timeline to provide before-and-after comparison of resource configurations for all changes to in-scope system components (Requirement 6.5.1). Deploy AWS CloudFormation change sets to preview proposed infrastructure changes before execution, enabling review of security impact prior to deployment. Implement AWS Systems Manager Automation runbooks with approval workflows requiring documented authorization before changes execute in production environments. Configure Amazon EventBridge rules to capture all CloudFormation stack events and Systems Manager Automation executions, routing them to Amazon CloudWatch Logs for change documentation and audit trail maintenance.
Enforce production data protection in non-production environments: Deploy AWS Config custom rules to detect when production data sources (Amazon RDS snapshots, S3 objects, DynamoDB table exports) are shared with or copied to non-production accounts (Requirement 6.5.4). Configure Service Control Policies to restrict cross-account data sharing between production and non-production OUs. Implement AWS Lambda functions triggered by Amazon EventBridge to automatically revoke unauthorized cross-environment resource sharing. Where test data is required, use AWS Glue or AWS Lambda to implement data masking or tokenization pipelines that sanitize production data before use in non-production environments. Configure AWS CloudTrail to log all cross-account resource access attempts for audit purposes.
Configure automated change documentation and approval workflows: Deploy AWS Systems Manager Automation runbooks with multi-level approval gates that require documented authorization, impact analysis, and back-out procedures before changes execute in production (Requirement 6.5.1). You can also use AWS Systems Manager Change Manager or simple manual approval stages within CodePipeline to implement approval workflow. Configure Amazon EventBridge to capture all change events (CloudFormation deployments, Systems Manager executions, Config rule evaluations) and route them to Amazon CloudWatch Logs with structured metadata including change requester, approver, timestamp, and affected resources. Store change records in Amazon S3 within the Log Archive account with lifecycle policies ensuring retention for assessment evidence. Integrate SSM automation runbooks with AWS Security Hub to validate that security controls remain operational after each change completes.
Leverage Infrastructure as Code (IaC) and source code versioning: IaC source code versioning capabilities helps implement a robust change management that ensure infrastructure is deployed through code and all code changes are authorized and tracked through version control of source code repository. Additionally, when you manage your resources through CloudFormation you can use drift detection to identify stack resources to which configuration changes have been made outside of CloudFormation management. You can then take corrective action so that your stack resources are again in sync with their definitions in the stack template
