Controls29 April 2026 8 min read

CC7: System Operations and Incident Detection in SOC 2

SOC 2 CC7 covers system operations, anomaly detection, and incident response. Learn the CC7.1–CC7.5 requirements and how to build a compliant incident response process.

Key Takeaways

CC7.1 requires baseline configurations and monitoring against those baselines.
CC7.2 requires monitoring for anomalies and indicators of compromise.
CC7.3–CC7.5 cover incident response: detection, escalation, recovery, and post-incident review.
AWS GuardDuty, Security Hub, and CloudTrail together provide strong CC7.2 evidence.
Incident response must be documented and tested — a runbook that has never been exercised is insufficient.

In this guide

What Is CC7?
CC7.1: Baseline Configurations
CC7.2: Anomaly Detection
CC7.3: Incident Response
CC7.4: Recovery and Restoration
CC7.5: Incident Disclosure
CC7 Evidence Checklist

What Is CC7?

CC7 covers System Operations — the ongoing running and monitoring of the system. It has five sub-criteria that progressively cover: maintaining secure baseline configurations (CC7.1), detecting anomalies and security events (CC7.2), responding to incidents (CC7.3), recovering from incidents (CC7.4), and disclosing incidents to affected parties (CC7.5).

CC7 is where your monitoring and incident response program gets evaluated. The AICPA expects a closed loop: you detect events, you respond to them, you recover, you review, and you improve. Evidence for CC7 spans your SIEM, ticketing system, and incident runbooks.

CC7.1: Baseline Configurations

CC7.1 requires the entity to use detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities. In practice, this means defining baseline configurations for your infrastructure and detecting deviations.

AWS Config continuously monitors your AWS resource configurations against defined rules. When a resource drifts from its baseline — for example, a security group that opens port 22 to the public — Config flags it as non-compliant. Enabling AWS Config with a managed rule set satisfies CC7.1.

Augment AWS Config with Infrastructure as Code (Terraform, AWS CDK) — when all infrastructure is defined in code, unauthorized configuration changes are immediately visible in the diff. CodePipeline or GitHub Actions can enforce that all infrastructure changes go through a reviewed deployment process.

CC7.2: Anomaly and Threat Detection

CC7.2 requires monitoring for indicators of compromise, anomalous activity, and security events. For AWS environments, the core detection stack is: AWS GuardDuty (threat intelligence and behavior anomaly detection), AWS Security Hub (aggregated security findings across services), and CloudTrail (audit log of all API calls).

GuardDuty should be enabled in all AWS accounts and all regions, including those with no active workloads (attackers create resources in unused regions to avoid detection). Security Hub should aggregate findings from GuardDuty, Config, Inspector, and Macie. CloudTrail should log all management and data events to a dedicated S3 bucket with log file validation enabled.

Alerts from these services should route to a notification channel — SNS to Slack, PagerDuty, or a ticketing system — so they are actioned. Auditors will check both that the detection tools are configured and that alerts were reviewed during the audit period.

CC7.3: Incident Response

CC7.3 requires that security incidents are identified, contained, eradicated, and that the root cause is analyzed. Your incident response policy should define: what constitutes a security incident, the severity levels, response timeframes for each severity, and the response team and escalation path.

The IR policy alone isn't sufficient — auditors want to see it was tested. Tabletop exercises (a facilitated discussion of a hypothetical incident scenario) count as testing. Run at least one tabletop per year and document it. Even better: simulate a phishing attack or unauthorized access attempt and run through the actual IR procedure.

During the audit period, auditors will sample any actual security incidents that occurred and trace through the response: detection, ticket creation, escalation, containment, and closure. Every step should be documented in your incident tracking system.

CC7.4: Recovery and Restoration

CC7.4 requires that after an incident, systems are recovered and restored to their normal operating state. This overlaps with the Availability trust service category but is also a common criteria requirement under CC7.

Your incident response runbook should include a recovery procedure: how to restore from backup, how to rebuild a compromised instance, how to roll back a malicious code change. AWS Systems Manager Incident Manager can be used to run recovery runbooks automatically after an alert fires.

Evidence for CC7.4: backup restoration test records (restore a database from backup and verify data integrity), DR drill records, and incident post-mortems documenting recovery actions taken.

CC7.5: Incident Disclosure

CC7.5 requires that incidents affecting users or data are communicated to affected parties in a timely manner. Your incident response policy must specify: what types of incidents require customer notification, what the notification timeframe is (72 hours is a common standard, required by GDPR and DPDP Act), and what the communication template is.

For breaches involving personal data, DPDP Act requirements may also apply — notification to the Data Protection Board within 72 hours of the organization becoming aware. Document this in your IR policy to satisfy both SOC 2 CC7.5 and DPDP Act obligations simultaneously.

CC7 Evidence Checklist

(1) AWS Config rules list and compliance status report. (2) AWS GuardDuty enabled screenshot for all accounts and regions. (3) Security Hub findings report from audit period. (4) CloudTrail configuration showing management and data event logging. (5) Incident response policy and runbook. (6) Tabletop exercise record or simulated incident documentation. (7) Sample incident tickets from audit period showing full lifecycle. (8) Backup restoration test results. (9) Post-incident review records.

Frequently Asked Questions

Does GuardDuty need to be enabled in every region for CC7.2?

Yes. Attackers often launch resources in unused regions to avoid detection. AWS recommends enabling GuardDuty in all regions, even those with no active workloads. Use AWS Organizations to enable GuardDuty across all accounts and all regions from a delegated administrator account.

What counts as a security incident for CC7.3 purposes?

Your IR policy should define this, but typically: unauthorized access to production systems or data, malware detection, phishing attack resulting in credential compromise, accidental data exposure, and denial-of-service attacks. Not every GuardDuty finding is an incident — define a severity threshold for formal incident declaration.

If we had no security incidents during the audit period, how do we evidence CC7.3?

Your IR policy, runbook, and tabletop exercise evidence demonstrate the process is in place. Auditors understand that a well-secured environment may have no incidents. However, they will expect to see some investigation records even for low-severity alerts — the absence of any documentation can suggest monitoring isn't being reviewed.

How long should we retain CloudTrail logs for SOC 2?

SOC 2 doesn't specify a retention period, but the standard practice is 12 months hot (S3 Standard) and 7 years cold (S3 Glacier) to cover audit and litigation hold requirements. Enable CloudTrail log file validation to detect tampering, and enable access logging on the CloudTrail S3 bucket.

Is PagerDuty required, or can we use Slack for incident response?

Any tool that demonstrates alert routing and on-call coverage satisfies CC7.3. Slack alone is generally insufficient for P1/critical incidents because it lacks escalation paths and acknowledgment tracking. PagerDuty, OpsGenie, or AWS Systems Manager Incident Manager provide the escalation and audit trail that auditors expect for critical incidents.