Procedure 03 HYBRID
Incident Response Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 03 · PCI DSS Req 12.10 · 1 of 6 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 03 — Incident Response PolicyThe rule this procedure implements
How Revique implements this today
Detection in production rests on GuardDuty, which is enabled in both production regions with a six-hour finding-publishing frequency. At the time of collection us-e****-1 had zero findings and us-e****-2 had one open low-severity finding (severity 2.0, Discovery:S3/AnomalousBehavior, last updated 2026-08-07). Operational detection is provided by CloudWatch alarms — 50 in production us-e****-2 covering API Gateway 4XX/5XX/latency, Lambda errors, EC2 health and RDS capacity, and 6 in us-e****-1 covering dead-letter queues and scaling — wired to SNS topics for notification. CloudTrail (Procedure 11) provides the forensic record needed to investigate.
The rule against the current state
Each row takes a statement from Policy 03 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 |
|---|
| Monitoring and alerting in place to support timely detection | GuardDuty on in both production regions; 56 CloudWatch alarms in production; CloudTrail multi-region with S3 data events for forensics. | Meets |
| A documented incident response plan, tested annually | No IR plan document is discoverable from AWS. This is an administrative artefact and its existence could not be confirmed. | Gap |
| An IR team with defined roles, available 24/7 | Roles are named in the policy; a rota is an administrative artefact. | Partial |
| Incidents classified by severity | GuardDuty assigns severity automatically; a Revique-side classification scheme is administrative. | Partial |
| Breach-notification procedure for CHD/PHI compromise | Administrative — not implementable in AWS. | Partial |
| Detection extends to all environments | GuardDuty is not enabled in the dev (292****) or UAT (559****) accounts. | Gap |
🔍 Auditor verification — where to log in and what you will see
GuardDuty is enabled in productionConsole → GuardDuty → production account, us-e****-1 and us-e****-2 → Settings shows status Enabled, publishing frequency 6 hours.
Current findingsGuardDuty → Findings. Expect 0 in us-e****-1; one low-severity S3 discovery finding in us-e****-2.
Alerting is wired upConsole → CloudWatch → Alarms → production us-e****-2: 50 alarms, each with an SNS action. Then SNS → Topics → Subscriptions for the delivery targets.
Forensic record availableConsole → CloudTrail → Event history, and the trail's S3 destination (see Procedure 11).
The IR plan itselfAsk for the incident response plan document and the record of its last test — not stored in AWS.
Team process
GuardDuty findings and CloudWatch alarms notify via SNS. Any person who suspects an incident reports it immediately to the Security Officer, who classifies severity, coordinates containment with DevOps, and owns the post-incident review. For a suspected CHD/PHI compromise the Security Officer also owns the breach-notification decision and its timing.
⚠️ Where reality does not meet the policy
- No incident response plan document could be evidenced. The policy requires a documented plan tested at least annually; detection tooling exists but the written plan, the team rota and the test record do not.
- GuardDuty is enabled in production only. Dev and UAT have no threat detection at all, so an incident originating in a lower environment would not be detected.
- There are no security-event alarms anywhere in the estate — no alarm on root account use, IAM policy changes, failed console logins or unauthorised API calls. Every one of the 56 production alarms is operational (CPU, errors, latency, queue depth), so PCI DSS 10.6-style alerting is absent.
- Four of the six production us-e****-1 alarms have no alarm action configured — they change state but notify nobody.
Evidence location. Incident response plan, team rota, annual test results and post-incident reviews are documents held outside AWS.
📘Back to the PolicyPolicy 03 — Incident Response Policy (PCI DSS Req 12.10)←