Procedures
How Revique actually implements each of the 21 policies in its real AWS environment — the current configuration, the value against the rule, the team workflow, and the exact path an auditor follows to verify it. Where a control is not in place, the procedure says so.
accounts 292**** (dev) · 559**** (UAT) · 501**** (prod) · regions us-e****-1 / us-e****-2 · values masked · AWS facts collected read-only on 2026-08-13
Accuracy over appearance. These procedures describe the estate as it was configured on 2026-08-13, collected through read-only AWS API calls. Where a control the policy requires is not configured, that is stated plainly rather than glossed over — an auditor will compare the procedure to reality, and an overstated procedure is worse than one that flags a gap. No secret values, cardholder data or PHI were read; only configuration metadata. All identifiers on these pages are masked.
How to read a procedure
Every procedure page has the same five parts, in the same order:
- How Revique implements this today — the real configuration in plain language.
- The rule against the current state — each policy statement paired with what is actually configured, and a verdict of Meets, Partial, Gap or N/A.
- Auditor verification — exactly where to log in and what will be on screen.
- Team process — who requests, who approves, who is notified.
- Where reality does not meet the policy — the honest gap list.
Procedures are labelled TECHNICAL when the control lives in AWS and can be verified from the console, ADMINISTRATIVE when it is a people or documentation control whose evidence lives in HR or management records, and HYBRID when it is both. The label tells an auditor where to look before they start.
The 21 procedures
📘Security Policies — the rule bookThe 21 rules these procedures implement, each mapped to PCI DSS→