Procedure 13 TECHNICAL
Secure Configuration Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 13 · PCI DSS Req 2 · 1 of 5 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 13 — Secure Configuration PolicyThe rule this procedure implements
How Revique implements this today
The native estate is defined as infrastructure-as-code using AWS CDK — every account and region carries a CDK asset repository, and resources are created from versioned templates rather than by hand. This is what delivers consistent configuration: encryption-by-default, private database placement and minimal security groups in production all come from the same code path. Container images use immutable tags in all five ECR repositories, so a deployed image cannot change underneath the running service. Vendor defaults are addressed by using managed services (Aurora, Fargate, Lambda) whose administrative credentials are set at creation and held in Secrets Manager rather than left at a default.
The rule against the current state
Each row takes a statement from Policy 13 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 |
|---|
| Documented hardening standards applied to all components | CDK templates are the de facto standard for the native estate. No written hardening standard document exists, and the legacy us-e****-2 estate is not IaC-managed. | Partial |
| Vendor default passwords and accounts changed or disabled | Managed services with credentials in Secrets Manager; root accounts have MFA and no access keys. | Partial |
| Unnecessary services and ports removed or disabled | True in production (Procedure 12). Not true in dev us-e****-2. | Partial |
| Configurations reviewed for drift on a defined schedule | AWS Config is not enabled anywhere — zero configuration recorders and zero rules across all three accounts and both regions. | Gap |
| Image immutability | All 5 ECR repositories enforce immutable tags. | Meets |
🔍 Auditor verification — where to log in and what you will see
Infrastructure is code-definedConsole → CloudFormation → production us-e****-1 — the native stacks are CDK-generated. Console → ECR shows the matching cdk-* asset repositories in each account.
Tag immutabilityConsole → ECR → Repositories → Tag immutability: Enabled on all repositories in all accounts.
Drift detection is absentConsole → AWS Config → each account, each region → Settings shows no configuration recorder, and Rules shows 0 rules.
Managed credentialsConsole → Secrets Manager → Secrets (names and metadata only).
Team process
DevOps changes infrastructure by editing CDK code and deploying it; the Security Officer owns the hardening standard. Production application releases go through the gated pipeline (Procedure 02), though CDK infrastructure deploys do not pass that same gate.
⚠️ Where reality does not meet the policy
- AWS Config is not enabled in any account or region. There is no configuration recorder, no conformance pack and no rules, so configuration drift is neither detected nor alerted on. The policy's “reviewed for drift on a defined schedule” requirement has no technical implementation. Enabling Config would also give an auditor a point-in-time configuration history, which does not exist today.
- No written hardening standard exists. CDK encodes the intended configuration but there is no document an auditor can compare a system against.
- The legacy us-e****-2 estate is not managed as code. Its security groups were created through the EC2 launch wizard (Procedure 12), which is the visible symptom of ad-hoc configuration.
- Infrastructure changes bypass the manual approval gate that application releases pass through.
Evidence location. CDK source is in the code repository; hardening standard documentation does not currently exist.
📘Back to the PolicyPolicy 13 — Secure Configuration Policy (PCI DSS Req 2)←