Procedure 14 HYBRID
Security & Penetration Testing Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 14 · PCI DSS Req 11.4 · 1 of 6 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 14 — Security & Penetration Testing PolicyThe rule this procedure implements
How Revique implements this today
Continuous security validation in production comes from GuardDuty (Procedure 03/10) and, on the build path, ECR image scanning (Procedure 05). Penetration testing and external ASV scanning are vendor activities that leave no configuration trace in AWS — they are evidenced by the tester's report, not by a console setting. AWS permits customer-initiated penetration testing against in-scope services without prior approval, so no AWS authorisation record exists or is needed.
The rule against the current state
Each row takes a statement from Policy 14 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 |
|---|
| Internal and external vulnerability scans on a defined schedule | Amazon Inspector is disabled in all three accounts and both regions. No scheduled internal scanning is running. | Gap |
| External scans by a qualified provider (ASV) | Vendor activity — no AWS evidence. Report not sighted. | Gap |
| Annual penetration test and after significant change | Vendor activity — no AWS evidence. Report not sighted. | Gap |
| Issues remediated and re-tested to confirm closure | Procedural; depends on the tests above existing. | Gap |
| Testing results documented and retained | Administrative record. | Gap |
| Continuous automated detection in production | GuardDuty enabled in both production regions with 6-hour publishing. | Meets |
🔍 Auditor verification — where to log in and what you will see
What automated testing does existConsole → GuardDuty → production account, both regions → Enabled. Console → ECR → native application repository → Scan on push: Enabled.
What does notConsole → Amazon Inspector → Account management, each account and region → Disabled for EC2, ECR and Lambda.
Penetration test evidenceAsk for the most recent penetration test report, its date, the tester's qualification, the findings list and the re-test confirmation. None of this is in AWS — it must be produced as a document.
ASV scan evidenceAsk for the quarterly ASV scan attestations for the internet-facing scope.
Team process
The Security Officer schedules penetration testing and ASV scanning with the chosen vendor, receives the report, and tracks findings to closure with Engineering. Re-test confirmation closes the loop. AWS does not need to be notified in advance for testing against permitted services.
⚠️ Where reality does not meet the policy
- No penetration test evidence exists. The policy requires at least an annual test; no report was available and there is no AWS-side artefact that could substitute for one.
- No ASV or scheduled vulnerability scanning. Amazon Inspector — the AWS service that would provide continuous internal scanning of EC2, ECR and Lambda — is disabled across the entire estate. This is the single cheapest gap to close on this page.
- Because no testing programme is running, the remediation and re-test requirements are moot rather than met.
Evidence location. Penetration test reports, ASV attestations and remediation tracking are vendor and Security Officer documents held outside AWS.
📘Back to the PolicyPolicy 14 — Security & Penetration Testing Policy (PCI DSS Req 11.4)←