Procedure 12  TECHNICAL

Network Security Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 12  ·  PCI DSS Req 1  ·  1 of 5 policy statements fully met  ·  AWS facts collected read-only 2026-08-13
← All 21 procedures 📘← Back to Policy 12 — Network Security PolicyThe rule this procedure implements

How Revique implements this today

Network exposure in production is tight. In production us-e****-1 there are 8 security groups and exactly one permits inbound traffic from 0.0.0.0/0 — the application load balancer's group, on ports 80 and 443 only. In production us-e****-2 there are 3 security groups and none is open to the internet. No production security group exposes SSH, RDP or a database port to the world. The application tier sits behind the load balancer and the production Aurora cluster is not publicly accessible. Segmentation between the native (us-e****-1) and legacy (us-e****-2) tiers is by separate VPCs and regions.

The rule against the current state

Each row takes a statement from Policy 12 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 ruleCurrent stateVerdict
Rules restrict traffic to only what is required, default denySecurity groups are allow-list only. Production exposes 80/443 on the load balancer and nothing else.Meets
No unnecessary ports or services exposed to the internetTrue in production (both regions). Not true in dev us-e****-2.Partial
Inbound administrative access (SSH) from the internet not allowedNo production security group allows 22 from 0.0.0.0/0. Two dev security groups do.Partial
The cardholder data environment is segmented from untrusted networksNative and legacy tiers are in separate accounts' VPCs and separate regions; the production database tier is not internet-reachable in us-e****-1. The legacy MySQL instances in us-e****-2 are publicly accessible (Procedure 07).Partial
Network rules reviewed every [X] monthsNo review evidence exists; the stale dev rules below are the visible consequence.Gap

🔍 Auditor verification — where to log in and what you will see

Production exposureConsole → EC2 → Security groups → production account, us-e****-1 → 8 groups. Filter inbound rules for source 0.0.0.0/0 — only the load balancer group matches, on TCP 80 and 443. In us-e****-2, 3 groups and no 0.0.0.0/0 inbound rules.
No public admin access in productionSame view → filter inbound for port 22, 3389, 3306, 5432 with source 0.0.0.0/0 — no results in either production region.
The dev exposureConsole → EC2 → Security groups → dev account (292****), us-e****-2 → groups named default, launch-wizard-1 and launch-wizard-2 carry inbound 0.0.0.0/0 rules including TCP 22 (SSH) and TCP 3306 (MySQL).
SegmentationConsole → VPC in each account and region — the native and legacy tiers share no VPC.

Team process

Security group changes are made by DevOps through CDK for the native estate. The Security Officer approves and reviews network rules. Production changes follow the change management flow in Procedure 02.

⚠️ Where reality does not meet the policy

Evidence location. All evidence is in AWS (EC2 security groups, VPC, RDS).
📘Back to the PolicyPolicy 12 — Network Security Policy (PCI DSS Req 1)←
Revique security documentation  ·  generated 2026-08-13  ·  all identifiers masked  ·  AWS facts collected read-only on 2026-08-13
Policies define the rule; procedures describe the implementation and how to verify it.