Procedure 02 TECHNICAL
Change Management Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 02 · PCI DSS Req 6.5 · 2 of 5 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 02 — Change Management PolicyThe rule this procedure implements
How Revique implements this today
Production front-end releases run through a single AWS CodePipeline in the production account (us-e****-2). The pipeline has four stages: Source (CodeCommit, mirrored from Bitbucket) → Build (CodeBuild) → Approve (manual approval) → Deploy (S3, served via CloudFront). The Approve stage is a real Approval/Manual action sitting between build and deploy — the build artefact cannot reach production until a human clicks Approve, and the approval prompt reads “Please review and approve to deploy to Production!”. The UAT and dev pipelines (one each, plus 17 further pipelines in the dev account) deliberately have no approval stage, so non-production deploys stay fast. The five most recent production executions all completed Succeeded, the latest on 2026-05-08.
The rule against the current state
Each row takes a statement from Policy 02 and states what is actually configured. Meets = implemented as written. Partial = implemented, but not everywhere or not to the full standard. Gap = not implemented. N/A = not verifiable from infrastructure configuration.
| The rule | Current state | Verdict |
|---|
| Production deployments pass a pipeline with a manual approval gate; no change may bypass it | Production pipeline is Source → Build → Approve (Manual) → Deploy. Deploy is unreachable without the approval. | Meets |
| Every change tested in UAT before promotion to production | A separate UAT pipeline and UAT account (559****) exist and deploy the same application. Promotion discipline is procedural, not enforced by the pipeline. | Partial |
| Every change has a documented request with reason and impact | Change requests live in the issue tracker / Bitbucket pull requests, not in AWS. | Partial |
| Every change record includes a rollback plan | Deployment target is a versioned S3 origin behind CloudFront; rollback is redeploying the prior artefact. A written per-change back-out plan is not captured in the pipeline. | Partial |
| Approval is documented and attributable | CodePipeline records the approving IAM identity, the timestamp and any comment against each execution, retained in the execution history. | Meets |
🔍 Auditor verification — where to log in and what you will see
The approval gate existsConsole → CodePipeline → production account, region us-e****-2 → pipeline rev**** → the stage list shows Source, Build, Approve, Deploy.
The gate is a genuine manual approvalClick the Approve stage → action ManualApproval, provider Manual, category Approval.
Who approved a given releaseCodePipeline → the pipeline → Execution history → select an execution → the Approve stage shows the approving identity, time and comment.
Non-production has no gate (by design)Same view in the dev (292****) and UAT (559****) accounts → pipelines rev**** show Source, Build, Deploy only.
Team process
A developer opens a pull request in Bitbucket; the merge mirrors to CodeCommit and triggers the pipeline automatically (source events show trigger type CloudWatchEvent). Build runs in CodeBuild. The pipeline then halts at Approve. An authorised approver reviews the change and either approves — releasing it to the production S3 origin — or rejects it, which stops the execution. Emergency changes use the same pipeline and the same gate; the retrospective review is a manual step recorded in the tracker.
⚠️ Where reality does not meet the policy
- The manual approval action has no SNS notification target configured — approvers are not alerted when a release is waiting. Approval depends on someone watching the console, which can delay releases and weakens the “timely, documented approval” intent of the policy.
- Change requests, impact assessments and rollback plans live in the issue tracker rather than being linked from the pipeline execution, so an auditor cannot trace an execution to its change record without cross-referencing a second system.
- Only the front-end release path is gated by CodePipeline. Infrastructure changes made via CDK deploy or console are not covered by this gate.
Evidence location. Change requests, PR reviews and retrospective emergency-change reviews are held in Bitbucket and the issue tracker.
📘Back to the PolicyPolicy 02 — Change Management Policy (PCI DSS Req 6.5)←