Your auditor will sample 25 alerts. Can you show what you checked?
Published
For SOC 2, an auditor testing security monitoring will typically sample individual alerts from your period and ask you to show, for each one, that it was detected, reviewed, dispositioned and, where needed, escalated. Owning a SIEM proves nothing on its own. The evidence that satisfies the control is a per-alert record showing who looked at it, when, what they concluded, and why.
What is the auditor actually testing?
The SOC 2 Trust Services Criteria most relevant here are CC7.2, which concerns monitoring system components for anomalies and evaluating them, and CC7.3, which concerns evaluating identified events to determine whether they constitute a security incident. Read plainly, both are about evaluation, not about tooling.
This trips teams up because procurement and compliance conversations are usually framed around products. Buying Microsoft Sentinel does not satisfy CC7.2, in the same way that buying a fire extinguisher does not satisfy a fire drill requirement. The control asks what you did when something fired.
So the auditor pulls a sample, often a couple of dozen alerts across the audit period, and works through them one by one. For each: was it detected, was it seen by a human, what was decided, when, and on what basis. That is the test.
Why does every alert need a disposition?
Not every alert becomes an incident. But every alert needs an outcome that someone recorded, because an alert with no recorded outcome is indistinguishable from an alert nobody looked at.
This is where the sample bites. If the auditor picks an alert from a Tuesday in March and your answer is "that one was a false positive", the follow-up is immediate: show me. If there is no record, the finding is not that you were wrong, it is that the control is not operating.
The trap is the closed-as-benign pile. It is by far the largest category, it is the one nobody documents, and it is the one an auditor is most likely to sample, precisely because it is the largest. A high-severity alert that turned into a real incident usually has a paper trail. The 400 alerts you dismissed do not.
What does good evidence actually look like?
The bar is lower than most teams fear, but it is specific. For each sampled alert, an auditor is generally trying to reconstruct the story from artefacts rather than from your memory.
- The alert itself, with a stable identifier and a timestamp, and the source system it came from.
- Evidence a human reviewed it, with a name and a time. "The team monitors the queue" is not evidence; a record with a person and a timestamp is.
- The disposition: true positive, false positive, benign expected activity, or escalated to an incident. One of a defined set, not free text that varies per analyst.
- The reasoning, and ideally the underlying data. Why was this benign? An answer that points back to the specific log or finding is far stronger than an assertion.
- Timeliness against whatever SLA your own policy claims. If your policy says high-severity alerts are triaged within four hours, the sample will be checked against that. Do not write an SLA you do not meet.
- For anything escalated, the link onward into your incident record.
What are the three ways teams fail this?
The failures are boringly consistent, and none of them are about detection quality.
The first is the undocumented dismissal: hundreds of alerts closed as noise with no record of who decided or why. The second is the policy you wrote but do not operate: an SLA or a review cadence in the document that the sample immediately contradicts. The third is evidence that lives in a person: the one engineer who remembers what happened in March, who is on holiday during the audit, and whose knowledge is not an artefact.
All three are recording problems rather than security problems. The team was often doing reasonable triage. They just cannot prove it eleven months later, which for the purposes of the audit is the same as not having done it.
How do you produce this evidence without a SOC team?
The requirement is a durable, per-alert record with a reviewer, a disposition, a rationale and a link back to the underlying data. Nothing about that requires a 24/7 team; it requires that the investigation is written down at the time, in a consistent shape.
This is a side effect of how OwlSOC works rather than a compliance feature bolted on. Each alert gets an investigation record with an evidence-linked timeline, where every claim carries a source or pivot ID back to the origin log, a MITRE ATT&CK mapping, the resolved entities, and a plain-language verdict. Because the reasoning is linked rather than asserted, an auditor asking "why did you think this was benign?" can be answered by pointing at the specific evidence rather than by recalling a Tuesday in March.
Two outputs matter for an audit specifically. Case reports export, including PDF, so a sampled alert can be handed over as a self-contained document. And the audit log itself is exportable as CSV or JSON, tenant-scoped and date-filterable, so you can produce the record for the period the auditor asked about. Approvals carry the person and the timestamp, which is the part teams most often cannot reconstruct.
What does this not prove?
It is worth being precise, because compliance content usually is not. A good evidence trail proves that alerts were investigated, dispositioned and recorded. It does not prove your detection coverage is adequate, that your rules would catch a competent attacker, or that a verdict was correct.
An auditor testing CC7.2 is testing whether the control operates, not whether your security is good. Those are different questions, and passing the first while failing the second is entirely possible. Do not let a clean audit substitute for an honest look at coverage.
It also does not remove the human. A disposition still needs a person accountable for it, which is one reason OwlSOC recommends rather than closes cases by itself. An AI that silently auto-closed the benign pile would produce a tidy audit trail of decisions no human ever made, which is a worse position than the messy one you started in.
Frequently asked
What evidence does a SOC 2 auditor want for security alert monitoring?
For criteria such as CC7.2 and CC7.3, an auditor will typically sample individual alerts from the audit period and, for each, look for: the alert with its identifier, timestamp and source; evidence that a named person reviewed it and when; a disposition from a defined set such as true positive, false positive or escalated; the reasoning behind that disposition, ideally linked to the underlying log data; timeliness against your own documented SLA; and a link to the incident record for anything escalated.
Do we have to document alerts we closed as false positives?
Yes, and it is the category auditors most commonly sample, because it is the largest. Not every alert becomes an incident, but every alert needs a recorded disposition with a reviewer and a rationale. An alert closed with no record is indistinguishable, from an auditor's point of view, from an alert nobody looked at, and the resulting finding is that the control is not operating rather than that a judgement was wrong.
Does buying a SIEM satisfy SOC 2 monitoring requirements?
No. The criteria are about evaluation, not tooling. Deploying Microsoft Sentinel, Microsoft Defender or AWS Security Hub demonstrates that you can detect events; it does not demonstrate that identified events were reviewed and dispositioned, which is what the auditor tests by sampling alerts. The evidence has to show what happened after an alert fired.
Can OwlSOC produce the evidence a SOC 2 auditor asks for?
It produces the per-alert investigation record that underpins it. Every alert gets an evidence-linked timeline where each claim carries a source or pivot ID back to the origin log, a MITRE ATT&CK mapping and a plain-language verdict. Case reports can be exported, including as PDF, and the audit log can be exported as CSV or JSON, tenant-scoped and date-filterable, with approvals recording who decided and when. OwlSOC is not a compliance product and does not assess your control environment; it produces the underlying artefacts your auditor samples.
Is OwlSOC SOC 2 certified?
No. OwlSOC is not currently SOC 2 or ISO 27001 certified, and we say so plainly rather than implying otherwise. What we can do is help you produce evidence for your own audit, and limit your exposure while you evaluate us: OwlSOC connects read-only by default, takes no action without a human approving it, and only executes on write scopes you explicitly grant.
Start with a 30-day refundable pilot. £495, one environment, every alert investigated, a full report at week four. Read-only, live within 48 hours of access.