SOC 2 CC7.1 evidence: what auditors actually want (and what most teams hand them instead)

What CC7.1 actually asks for

SOC 2’s Common Criteria 7.1 lives in the Trust Services category labelled System Operations. Strip away the compliance-ese and the control says one thing: you detect when your system stops behaving the way it’s supposed to, and you can prove it.

The AICPA’s actual wording (slightly paraphrased) is: “The entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.” That’s broad on purpose. In practice, auditors interpret it as “show me evidence that anomalies in your production system get detected and triaged.”

For an API-shipping company, that question splits into two sub-questions auditors ask out loud:

1. How do you detect when something goes wrong in production?They want artifacts — logs, alerts, dashboards.
2. How do you know which change caused it? They want the link between the anomaly and the code change or configuration change that triggered it. This is the part most teams fail.

What most teams show their auditor (and why it’s thin)

Walk into a CC7.1 review and most engineering teams produce one or more of these artifacts:

• A list of Datadog or PagerDuty alerts. Useful for “we have monitors,” weak for “we know what caused this.” The alerts say p99 latency spiked; they don’t say PR #247 added an N+1 query.
• A spreadsheet of incidents and their root causes. Honest, but hand-maintained. Auditors notice that the spreadsheet has six entries for the quarter and the engineering team had ten visible incidents on the status page.
• A Notion page that says “we run unit tests in CI.”Not an artifact. Tests passing is not anomaly detection — it’s the absence of regressions that someone thought to test for.
• A statement of policy.“We monitor production behavior and investigate anomalies.” Fine as a stated control, weak as evidence the control is actually operating.

None of these are wrong. They’re just thin. A good auditor will accept them and move on; a careful auditor will write a“observation”noting that the team can detect anomalies but can’t consistently attribute them to a specific change. Observations don’t fail you. They show up in the report your customers read.

What a strong CC7.1 bundle looks like

The evidence that walks an auditor cleanly through CC7.1 has four parts. Each part is small on its own; together they tell the story the control is asking about.

1. A list of anomalies detected in the reporting period. One row per anomaly. Each row has a timestamp, a one-sentence description, and a severity.
2. The change that caused each anomaly. For each row, the PR (or config change, or deploy) that introduced the broken behavior, with the author and the merge time.
3. The authorizing artifact for that change. The Jira ticket, design doc, or PR description that explains why the change happened. This is what proves the change was authorized rather than rogue.
4. The resolution. Either a fix PR, a revert, or an explicit decision that the new behavior is intentional (with a rule-update record showing the policy changed). With timestamps so time-to-resolve is computable.

Auditors love this format because it’s the same shape as the incident retrospectives they already expect. The difference is that it’s machine-generated and complete — every anomaly in the period appears, not just the ones someone remembered to write up.

Why this is hard to assemble manually

The reason most teams don’t produce a bundle in this format is that no single tool in their stack has all four pieces.

• Datadog / New Relic / Honeycombhave the anomaly list. They don’t know which PR caused each anomaly.
• GitHubhas the PR list. It doesn’t know which PR corresponds to which anomaly.
• Jirahas the authorization context. It doesn’t know which ticket relates to which PR (the mention in the PR title is often the only link, and often missing).
• Vanta / Drata / Secureframehave the compliance control framework. They don’t read your code or your traffic.

Producing the bundle by hand means hopping between four tools for each incident and reconstructing the story. At a small company, this is a quarter of someone’s month. At a growing company, it stops being feasible at all — which is when teams start submitting the thin Datadog-list version and accepting the observation.

How an API rule registry produces this bundle

Stoney is built around the four-piece structure described above. Because it already correlates your code, your PRs, and your tickets to maintain the rule registry, generating the CC7.1 bundle is reading the data it’s already maintaining.

Specifically:

• Anomalies= drift events. Every time an approved rule’s expected behavior stops being true, Stoney logs a drift event with timestamp, severity, and the rule that broke.
• The change that caused each anomaly = the forensic-report attribution. Each drift carries the PR most likely to have caused it, the author, and the timestamp.
• The authorizing artifact = the linked Jira ticket. The same ticket that authorized the original rule, plus the ticket the change contradicted.
• The resolution = the auto-resolve timestamp when the contract started passing again, or the manual resolution record if a human marked the drift closed with a reason.

Click Compliance → Generate evidence, pick a reporting window, choose JSON or Markdown, and the bundle renders. The same data that drives Slack escalations and the dashboard becomes the audit artifact — with no screenshotting and no manual reconciliation. See the Compliance and security docs for the full format.

Practical tips for your next audit cycle

Three things to do in the run-up to your audit window, whether or not you use Stoney:

1. Pick the reporting period before you start collecting.Auditors want evidence covering the stated period exactly — not “the last six months of incidents you happened to remember.” Stoney's export lets you set the window precisely; if you’re doing it by hand, write the window down first.
2. Include resolved and open anomalies. Auditors get suspicious when every incident in the period was resolved cleanly. Real systems have open issues. Show them.
3. Tie each anomaly to a change and to an authorization.If you can’t produce that link for every row, you’ll get an observation. The fix is either a tool that maintains the link continuously, or a quarterly project to back-fill it — pick one.

Closing

CC7.1 isn’t the hardest control in SOC 2. It’s the one where engineering teams most often produce thin evidence and accept an observation in the audit report. The fix is structural — tying every anomaly back to the change that caused it and the authorization behind the change — and it compounds across the rest of the framework. The same data structure backs CC8.1 (change management), CC6.7 (data in transit), and parts of CC4 (monitoring and review).

If you’re prepping for an audit and want to see what the bundle looks like with your real code and tickets, start free or read the rest of the documentation.