SOC 2 CC7 Monitoring Controls: AWS GuardDuty, Config, and CloudTrail
A practical guide to implementing SOC 2 CC7 system monitoring controls in AWS using GuardDuty, AWS Config, CloudTrail, and Inspector — with evidence requirements for auditors.
The CC7 Monitoring Category
SOC 2 CC7 covers System Operations — the controls that detect, respond to, and recover from security incidents and system failures. Where CC6 is about prevention (keeping unauthorized access out), CC7 is about detection (knowing when something has gone wrong and responding appropriately).
CC7 has six sub-criteria. Here's the AWS implementation for each.
CC7.1 — System Components Are Monitored
What it requires: To detect and act upon indicators of compromise or security events, the entity monitors system components for configuration changes and behavior anomalies.
AWS services:
AWS Config: Continuously records configuration changes to all AWS resources. When an S3 bucket's block-public-access setting is changed, Config records it with a timestamp. Config rules evaluate resources against compliance baselines.
CloudWatch: Collects metrics, logs, and events. CloudWatch Metrics Alarms alert on threshold violations. CloudWatch Logs Insights queries log data for anomalies.
CloudTrail: Records all AWS API calls — who called what, from where, at what time. Essential for operational monitoring and forensic investigation.
Evidence SecureSpect collects:
aws.config.recorder_enabled — CC7.1
aws.config.rules_compliance — CC7.1
aws.cloudtrail.multi_region — CC7.1
aws.cloudtrail.log_file_validation — CC7.1
aws.vpc.flow_logs_enabled — CC7.1
aws.eks.audit_logging — CC7.1
aws.waf.logging_enabled — CC7.1
What auditors want to see:
- AWS Config enabled in all regions, recording all resource types
- CloudTrail multi-region trail with log file validation enabled
- VPC flow logs enabled
- A process for reviewing configuration change alerts
CC7.2 — Anomalies and Security Events Are Detected
What it requires: The entity detects anomalies that may indicate compromise or system failure.
AWS services:
Amazon GuardDuty: Machine learning-based threat detection analyzing CloudTrail, DNS logs, and VPC flow logs. Identifies compromised credentials, data exfiltration attempts, cryptocurrency mining, and anomalous API activity.
Amazon Inspector v2: Vulnerability scanner for EC2 instances and ECR container images. Identifies CVEs in running software and container dependencies.
CloudTrail Insights: Detects unusual API activity — a sudden spike in failed DescribeInstances calls, for example, may indicate enumeration.
Evidence SecureSpect collects:
aws.guardduty.enabled — CC7.2
aws.guardduty.high_severity_findings — CC7.2
aws.inspector.enabled — CC7.2
What auditors want to see:
- GuardDuty enabled in all regions with a findings review process
- Inspector enabled with no unaddressed critical/high vulnerability findings
- A documented process for responding to GuardDuty findings within defined SLAs (HIGH within 24 hours, MEDIUM within 72 hours)
CC7.3 — Security Events Are Evaluated
What it requires: Security events are evaluated, and response decisions are made in a timely manner.
AWS implementation:
- GuardDuty findings routed to SNS → PagerDuty/Slack for high-severity events
- AWS Security Hub as a central aggregation point for findings from GuardDuty, Inspector, Config, and IAM Access Analyzer
- Defined incident classification: P1 (immediate), P2 (within 4 hours), P3 (within 24 hours), P4 (within 72 hours)
- Documented runbooks for common GuardDuty finding types
CC7.4 — Security Incidents Are Responded To
What it requires: Security incidents are responded to, identified causes investigated, and actions taken to prevent recurrence.
AWS implementation:
This is primarily a process and documentation requirement, not a technical one. You need:
- A written Incident Response Plan (IRP) that defines incident classification, escalation paths, and roles
- A forensic capability: CloudTrail logs retained for 12+ months, VPC flow logs available, GuardDuty findings retained
- Evidence of the IRP being tested (tabletop exercises, at minimum)
CC7.5 — Identified Vulnerabilities Are Addressed
What it requires: Vulnerabilities are identified and addressed in a timely manner.
AWS implementation:
Amazon Inspector v2: Continuously scans EC2 instances and ECR container images for CVEs. Inspector generates findings with severity scores and links to the CVE database.
ECR image scanning: Scans container images on push for known vulnerabilities. Integrate this into your CI/CD pipeline — fail the build on CRITICAL CVEs.
GitHub Dependabot: Scans application dependencies for known vulnerabilities and creates PRs to update affected packages.
Vulnerability management SLAs:
- CRITICAL: patch within 7 days
- HIGH: patch within 30 days
- MEDIUM: patch within 90 days
Building a CC7 Evidence Package
For each CC7 sub-criterion, you need:
SecureSpect handles #1 and #2 automatically. #3 requires writing 2–3 short policy documents.
FAQ
Is GuardDuty sufficient for CC7.2? GuardDuty is the primary CC7.2 control for AWS environments, but it needs a review and response process to be effective. GuardDuty running with no one looking at the findings doesn't satisfy CC7.2.
Do I need a SIEM for SOC 2? No. AWS services (GuardDuty, Inspector, Config, CloudTrail, Security Hub) provide sufficient monitoring for CC7. A SIEM becomes valuable as you scale and handle more complex threat environments.
How often should we test our incident response plan? Annually at minimum. Quarterly tabletop exercises are better. Auditors will ask whether the IRP has been tested.
