Change Management Policy

1. Purpose

This policy defines how changes to the Gatelithix Gateway Cardholder Data Environment (CDE) and connected systems are proposed, reviewed, tested, approved, deployed, and documented. It ensures that changes do not introduce vulnerabilities or compromise cardholder data security, in compliance with PCI DSS 4.0.1 Requirement 6.5.

2. Scope

This policy applies to all changes affecting:

• CDE systems: Token Vault Service (apps/vault/), PCI Cloud SQL, Cloud KMS configuration, PCI VPC/firewall rules
• Connected systems: Gateway API (apps/gateway/), Connector services (apps/connectors/), Dashboard (apps/dashboard/)
• Infrastructure: Terraform configurations (infra/terraform/), CI/CD pipelines (.github/workflows/)
• Database schemas: Goose migrations (db/migrations/, db/migrations/vault/)
• Dependencies: Go module updates, npm package updates
• Configuration: Cloud Run environment variables, Secret Manager secrets, Auth0 tenant settings

Changes are classified into two categories:

3. Roles and Responsibilities

4. Policy Statements

4.1 Standard Change Process

All standard changes follow this process:

Step 1: Development

1. Create a feature branch from main.
2. Implement the change with appropriate unit and integration tests.
3. Ensure all tests pass locally before creating a pull request.

Step 2: Pull Request

1. Create a pull request (PR) on GitHub with:
   • Clear description of what is changing and why
   • PCI scope impact assessment: does this change affect the CDE boundary, data flows, access controls, encryption, or audit logging?
   • Testing performed (automated and manual)
   • Rollback plan if the change causes issues
2. The PR triggers automated CI checks:
   • go test ./... (unit tests)
   • go vet ./... (static analysis)
   • golangci-lint (linting)
   • govulncheck (Go vulnerability scanning)
   • trivy (container image scanning)
   • npm run build for dashboard changes
   • Database migration validation

Step 3: Review and Approval

1. All PRs require at least one approval from a qualified reviewer.
2. Changes to apps/vault/ require approval from the Engineering Lead (enforced via GitHub CODEOWNERS).
3. Changes to infra/terraform/pci/ require approval from the ISO or Engineering Lead.
4. Reviewers verify:
   • No PAN in logs, error messages, or API responses
   • No new dependencies with known critical vulnerabilities
   • Access controls are not weakened
   • Encryption is not bypassed or downgraded
   • Audit logging covers new operations
   • Tests adequately cover the change

Step 4: Merge and Deploy

1. Approved PRs are merged to main via squash merge.
2. Merging to main triggers the CI/CD pipeline:
   • Build container images
   • Push to Artifact Registry
   • Deploy to Cloud Run (core project for non-CDE services)
   • Deploy to Cloud Run (PCI project for vault service, if vault files changed)
3. Post-deployment health checks verify the service is responding correctly.

Step 5: Post-Deployment Verification

1. Verify the change is working as expected in production.
2. For CDE changes: verify audit logging, encryption, and access controls are functioning.
3. For database migrations: verify schema by querying information_schema.columns (do not rely solely on goose version table).

4.2 CDE-Specific Change Requirements

Changes to CDE components have additional requirements beyond the standard process:

1. Explicit confirmation from the Engineering Lead or ISO before modifying vault code, as documented in CLAUDE.md.
2. PCI scope impact analysis documented in the PR description: could this change expand the CDE boundary, introduce new data flows, or weaken existing controls?
3. Vault interface preference: prefer adding to the vault’s public interface over modifying its internals. Minimize the scope of CDE changes.
4. Database migration verification: after deploying vault migrations, verify the schema by querying information_schema.columns — the goose version table can be out of sync.
5. Audit trail: CDE changes are logged in the Git history, PR review history, and Cloud Run deployment history.

4.3 Infrastructure Change Requirements

Changes to Terraform configurations follow additional steps:

1. terraform plan output must be included in the PR or PR comments.
2. The plan must be reviewed for unintended changes (resource destruction, security group modifications).
3. terraform apply is executed by the CI/CD pipeline after merge — never manually from a developer machine.
4. Network changes (firewall rules, VPC peering) require ISO approval regardless of who authors them.

4.4 Emergency Change Process

Emergency changes are permitted when a delay would result in:

• Active exploitation of a security vulnerability
• Ongoing cardholder data exposure
• Complete service outage affecting merchant payment processing

Emergency change procedure:

1. The Incident Commander (per the Incident Response Plan) authorizes the emergency change.
2. The change may be deployed directly to production with verbal approval from the ISO or Engineering Lead.
3. A PR is created retroactively within 24 hours of the emergency change.
4. The retroactive PR documents: what was changed, why it was urgent, who approved it, and the full test/verification results.
5. The ISO records the emergency change in the change log with the justification.

4.5 Rollback Procedures

Every change shall have a documented rollback plan:

4.6 Change Log

1. The ISO shall maintain a change log tracking all changes to CDE systems.
2. Each change log entry includes:
   • Date and time of change
   • Change author
   • PR number and link
   • Description of the change
   • Systems affected (CDE, connected, infrastructure)
   • Reviewer and approver
   • Test results summary
   • Rollback plan
3. The change log is derived from Git history and supplemented with deployment records.
4. Change log records are retained for at least 12 months.

4.7 Separation of Duties

1. The person who authors a change shall not be the sole approver of that change (enforced by GitHub branch protection requiring at least one review from a different person).
2. For CDE changes, the author, reviewer, and deployer roles should be distinct where team size permits.
3. CI/CD pipeline credentials (service accounts) are separate from developer credentials.

4.8 Development and Test Environments

1. Development and testing shall use test payment data only (Stripe test PANs, sandbox processor credentials).
2. Production cardholder data shall never be used in development or test environments.
3. Test environments shall mirror production security controls (encryption, TLS, access controls) but use separate credentials and key material.
4. See the Data Classification Policy for handling rules for test vs. production data.

5. Compliance and Enforcement

1. Deploying changes to CDE systems without following this process (except for authorized emergency changes) is a policy violation.
2. Merging PRs without required approvals is blocked by GitHub branch protection rules. Attempts to bypass these controls shall be investigated.
3. The ISO reviews the change log quarterly to verify process compliance.

6. Related Documents

• Information Security Policy (POL-001) — Parent policy
• Incident Response Plan (POL-005) — Emergency change authorization
• Network Security Policy (POL-003) — Network change process
• Access Control Policy (POL-002) — Access provisioning changes
• GitHub CODEOWNERS file — Enforces vault code review by Engineering Lead
• PCI DSS 4.0.1 Requirement 6.5

7. Document History