For SOC 2 Type 2, collect logs that show who accessed what and what changed, alerts from your detection tools, records that a person reviewed them, and incident tickets with outcomes, for every week of the observation period. Auditors test whether monitoring ran, not just whether a tool was installed.
What the criteria ask for
CC7.2 says the entity monitors system components for anomalies indicative of malicious acts, natural disasters and errors, and analyses anomalies to decide whether they are security events. The points of focus mention detection policies, procedures and tools, logging of unusual activity, filters to summarise and analyse anomalies, and monitoring the effectiveness of detection tools themselves. CC7.3 covers evaluating security events to determine whether they are incidents, and CC7.4 and CC7.5 cover response and recovery.
None of this prescribes a product, a log retention length or a review frequency. You choose them, write them in policy, and the auditor tests against your choices over the period.
The evidence set
Log sources and coverage. A list of in-scope systems and where their logs go: identity provider, cloud control plane, production hosts, databases, code hosting, endpoint tooling, VPN or zero trust gateway. A gap in coverage is a gap in CC7.2.
What is captured. Authentication events, privilege changes, administrative actions, configuration changes, access to sensitive data stores and security tool alerts. Note that CC7.1 also points to change detection for critical system and configuration files.
Retention and protection. How long logs are kept, where, and who can alter or delete them. Restrict write access so logs cannot be quietly edited.
Alert rules. Screens or exports of alert definitions: what triggers them, severity and who is notified. Keep a version history, since rules change during a period.
Proof of review. Dated records that a person looked: weekly review tickets, on-call handoff notes, dashboard sign-offs. A tool that alerts nobody is not monitoring.
Event evaluation. For alerts that fired, the ticket showing triage and the decision about whether it was a security incident (CC7.3). Include false positives, because they show the process ran.
Incidents. For real incidents: timeline, severity, containment, root cause, communication, post incident review and recovery actions (CC7.4, CC7.5).
Monitoring the monitors. A check that log pipelines and agents are healthy, with alerts when a source goes silent.
Sampling reality
The auditor will pick dates or alerts and ask you to show the log entry, the alert and the review. Make it easy: consistent ticket titles, links from alerts to tickets, and a spreadsheet or export listing all alerts in the period.
Pitfalls
Logging enabled only after the period started. Retention shorter than your own policy. Reviews done in chat with no record. Alert fatigue, where so many alerts fire that nobody evaluates them; tune and document the tuning. Forgetting new systems added mid period.
A worked example
Say your policy states that security alerts are reviewed every weekday. Over the period that is a few hundred review events. The auditor picks several dates. For each, you show the alert queue as it stood, the person who reviewed it, and the ticket or note recording the outcome. If one date has no record, you log an exception explaining what happened and how you prevent a repeat. Writing a weekly review commitment you cannot keep is a bigger risk than choosing a lighter cadence you always meet.
What to do
- Write the list of log sources and check each really sends data.
- Define what you log, retention, and who can access logs.
- Document alert rules and assign receivers and an on-call route.
- Set a review rhythm, then record each review in a ticket.
- Create a tag or label for security events so you can pull a period report.
- Run a log pipeline health check weekly or set an alert for silence.
- Export a monthly bundle: coverage list, alert list, review log, incident list.
Quick check
How long must I keep logs for SOC 2?
The criteria do not set a period. Choose a retention that supports investigations and your observation period, write it in policy and follow it.
Is a SIEM required?
No product is required. You need detection, analysis and evidence that people reviewed results. A SIEM is one way to do it.
How Safeguard helps automate this
Monitoring evidence piles up daily, which is why screenshots do not scale. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, leaving your team time for other work. Technical evidence about dependencies and code comes from scans, SBOMs and reachability on your real repositories. Autonomous remediation can open tested fix pull requests for findings; it is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. Safeguard helps you prepare and keep evidence ready; the auditor gives the opinion. Book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): CC7.1 to CC7.5 and the Type 2 description. Paraphrased.
Last reviewed: 18 October 2026.
