SOC 2's CC7.2 criterion asks whether an organization monitors system components for anomalies and takes action when they're detected. Most companies have monitoring — CloudWatch alarms, GuardDuty findings, Security Hub — but the evidence gap shows up when an auditor asks "show me that this alarm actually led to a documented response," not just "show me the alarm exists."
Why Alarms Alone Aren't Evidence
A CloudWatch alarm firing and sending an SNS notification demonstrates detection. It doesn't demonstrate response, and CC7.2 evidence needs to show the full loop: something anomalous happened, someone was notified, someone acted, and there's a timestamped record connecting all three. Screenshotting an alarm history in the console for an auditor shows detection worked — it says nothing about whether anyone did anything about it.
The Pipeline We Build
Instead of relying on whoever's on-call to remember to document their response, we build the documentation into the response workflow itself:
import boto3
import json
from datetime import datetime
def handle_alarm_to_ticket(sns_message):
"""Triggered by SNS when a CloudWatch alarm or GuardDuty finding fires.
Creates a tracked ticket and starts the evidence record automatically."""
alarm_data = json.loads(sns_message)
ticket = create_ticket(
title=f"Anomaly detected: {alarm_data['AlarmName']}",
description=alarm_data.get("NewStateReason", ""),
priority=map_severity_to_priority(alarm_data),
)
evidence_record = {
"alarm_name": alarm_data["AlarmName"],
"detected_at": alarm_data["StateChangeTime"],
"ticket_id": ticket["id"],
"ticket_created_at": datetime.utcnow().isoformat(),
"status": "open",
}
store_evidence_record(evidence_record) # DynamoDB table, queryable at audit time
return ticket
When the ticket is later resolved, a webhook from the ticketing system (Jira, Linear, ServiceNow) closes the loop by appending the resolution timestamp, the assignee, and a summary of the action taken to the same evidence record. The result is a single queryable table where every row shows detection time, response time, resolver, and resolution — exactly what CC7.2 sampling looks for.
Handling High-Volume, Low-Severity Findings
Not every finding warrants a ticket — a naive implementation that tickets every GuardDuty low-severity finding will bury the team and produce noise instead of evidence. We tune the pipeline to ticket based on severity thresholds and known-pattern suppression (see our related piece on AWS GuardDuty finding triage automation), so the evidence pack reflects genuine anomaly response, not an alert-fatigue-driven rubber stamp.
What This Produces for an Auditor
Instead of a narrative explanation of "we monitor things and respond when needed," the evidence export is a structured record: alarm name, severity, detection timestamp, ticket ID, assignee, resolution timestamp, and resolution summary — sortable and filterable, which is exactly the format that survives an auditor pulling a random sample of 25 events from a full year rather than the handful you remembered to document manually.
Frequently Asked Questions
Does this work with third-party monitoring tools, not just AWS-native ones?
Yes — the pattern is agnostic to the alarm source as long as it can trigger a webhook or API call (SNS, a monitoring platform's alert webhook, a SIEM alert), since the evidence pipeline starts from that trigger regardless of origin.
How do we handle alarms that turn out to be false positives?
The evidence record still captures the full loop — detection, ticket, and resolution noting "false positive, no action required" — which is itself valid evidence that the monitoring and response process functioned correctly.
What ticketing systems does this integrate with?
Most modern ticketing systems with a webhook or REST API (Jira, Linear, ServiceNow, GitHub Issues) can plug into this pattern; the specific integration code varies but the evidence structure stays consistent.
How long does it take to build this evidence pipeline for an existing monitoring setup?
For a team with monitoring already in place and a ticketing system with API access, wiring the alarm-to-ticket-to-evidence pipeline is typically a matter of weeks, most of which goes into severity tuning to avoid ticket flooding.
Ask us what your GRC platform isn't covering on monitoring evidence → rutagon.com/contact or call 907-841-8407.