Procedure 07 TECHNICAL
Access Control Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 07 · PCI DSS Req 7 · 2 of 7 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 07 — Access Control PolicyThe rule this procedure implements
How Revique implements this today
Access is granted through named IAM identities in each of the three accounts — 10 in dev, 10 in UAT, 7 in production — with production deliberately the smallest. AWS IAM is deny-by-default, so every permission an identity holds is an explicit grant. The most sensitive data store, the production Aurora PostgreSQL cluster in us-e****-1, is not publicly accessible and sits behind the application tier. Application-to-service access uses IAM roles attached to ECS tasks rather than long-lived keys.
The rule against the current state
Each row takes a statement from Policy 07 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 |
|---|
| Access defaults to deny, granted only by explicit authorisation | IAM's native model. No identity holds permissions it was not explicitly granted. | Meets |
| Production data store not reachable from the internet | Production Aurora PostgreSQL cluster: PubliclyAccessible = false. | Meets |
| Least privilege | Production carries the fewest identities. However both production legacy MySQL instances in us-e****-2 are PubliclyAccessible = true. | Partial |
| Access rights reviewed every [X] months and revoked when no longer required | No access review evidence exists, and dormant credentials remain active — see gaps. | Gap |
| Privileged access restricted and logged | All API calls are captured by CloudTrail in dev and production (Procedure 11). UAT has no trail, so privileged actions there are not logged. | Partial |
| Access revoked immediately on termination or role change | Procedural. Several identities show no usage for 3–6 years yet remain active. | Gap |
| Storage not publicly exposed | No account-level S3 Public Access Block is configured in any of the three accounts. Bucket-level block-public-ACLs covers 12 of 22 production buckets, 4 of 17 UAT, 16 of 40 dev. | Gap |
🔍 Auditor verification — where to log in and what you will see
Who has accessConsole → IAM → Users / Roles in each account. Or IAM → Credential report for a single CSV of every identity, its console access, MFA state and key ages.
Production database is privateConsole → RDS → production account, us-e****-1 → the Aurora PostgreSQL cluster → Connectivity & security → Publicly accessible: No.
Legacy databases are publicConsole → RDS → production account, us-e****-2 → both MySQL instances → Publicly accessible: Yes.
S3 exposureConsole → S3 → Block Public Access (account settings) in each account — expect not configured. Then per bucket → Permissions → Block public access.
Dormant credentialsIAM → Credential report → compare access_key_1_last_used_date against today.
Team process
Access is requested from the Security Officer with a business justification, who approves the specific permissions required; DevOps then provisions them. On termination or role change the same two roles are responsible for prompt revocation. Access reviews are the Security Officer's responsibility.
⚠️ Where reality does not meet the policy
- No account-level S3 Block Public Access in any of the three accounts, and bucket-level blocks cover only a minority of buckets (12/22 production, 4/17 UAT, 16/40 dev). Nothing structurally prevents a bucket from being made public.
- Both production legacy MySQL instances are publicly accessible from the internet. Network reach is constrained by security groups, but the policy's least-privilege and need-to-know intent is not met for the legacy data tier.
- Dormant credentials remain active. Access keys last used in 2021, 2022 and 2023 — and several never used at all — are still enabled across all three accounts. Some were last rotated in 2019.
- No evidence of a periodic access review. The policy requires review every [X] months; no review record exists and the dormant credentials above are the visible consequence.
Evidence location. Access request approvals and review sign-offs are held in the issue tracker / by the Security Officer.
📘Back to the PolicyPolicy 07 — Access Control Policy (PCI DSS Req 7)←