Introduction
Logging and monitoring evidence for SOC 2 is the dated proof that your organization captures security-relevant events from in-scope systems, keeps those logs long enough and safely enough to use them, runs alert rules that someone owns, reviews what the rules surface on a defined cadence, and records what happened to each meaningful alert across the audit period.
Most SaaS teams already log a lot. The audit gap is rarely "no logs." It is that nobody can show which sources are in scope, how long each one is retained, which detections exist, who looked at them last March, and what happened to the alert that fired on a Saturday. A bucket full of cloud audit logs that nobody queries is storage, not a monitoring control.
Here is a concrete example. An auditor samples three weeks from the period and asks how you would have detected a new administrator being added in your identity provider. Strong evidence includes a log source inventory showing identity provider admin events are collected, a retention setting that covers the period, an alert rule for privileged group changes with a named owner, the alert history for the sampled weeks, and a triage ticket for each alert that fired with a disposition and timestamp. Weak evidence is a screenshot of a dashboard taken the day before fieldwork.
In plain language: this guide is an evidence playbook for the logging and monitoring pipeline up to the point where something is declared an incident. It is not a second definition of monitoring, and it does not repeat Incident Response Evidence for SOC 2, which covers what happens after an incident is declared.
What Logging and Monitoring Evidence Means
Logging evidence proves that the right events are generated, collected, protected, and retained. Monitoring evidence proves that those events are watched through alert rules and reviews, and that the results of watching were acted on and recorded.
A complete logging and monitoring file usually answers:
- Which systems are in scope, and which log sources from each are collected?
- Where do logs go, who can change or delete them, and how long are they kept?
- Which alert rules or detections exist, what do they look for, and who owns them?
- Where do alerts route, and has anyone confirmed the route still reaches a human?
- Which reviews happen on a schedule (daily triage, weekly privileged activity review, monthly rule tuning), and where are the records?
- What happened to each meaningful alert: dismissed with a reason, fixed, or escalated to an incident?
- Can you export the populations an auditor will sample for any part of the period?
How This Guide Differs From Related Pages
| Page | Primary job | Use it when |
|---|---|---|
| What Is Monitoring? | Defines security, control, and continuous monitoring | You need the concept and vocabulary |
| What Is an Audit Trail? | Defines a chronological record of actions | You need the idea behind event history |
| What Is Data Retention? | Defines how long data is kept and why | You need the retention principle |
| Incident Response Evidence for SOC 2 | Evidence after an incident is declared | You are proving severity, timelines, and post-incident review |
| Vulnerability Management Evidence for SOC 2 | Scan cadence, severity SLAs, remediation | You are proving vulnerability handling |
| This guide | Log sources, retention, alert rules, review cadence, triage records, and Type 2 sampling | You need the detection pipeline evidence playbook |
What SOC 2 Requires vs Common Practice
Keep the criteria and your chosen practices apart.
What the criteria address. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) include themes that logging and monitoring controls commonly support:
- CC7.1: using detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.
- CC7.2: monitoring system components and their operation for anomalies that indicate malicious acts, natural disasters, and errors, and analyzing those anomalies to determine whether they represent security events.
- CC7.3: evaluating security events to determine whether they could or did result in a failure to meet objectives, and taking action when they did.
- CC4.1: selecting, developing, and performing ongoing or separate evaluations to confirm that components of internal control are present and functioning.
Points of focus are illustrative. SOC 2 does not name a SIEM, a log platform, a retention length, or a review frequency.
What is common practice, not a fixed SOC 2 rule:
- Centralizing logs in one SIEM or log platform (many teams use native cloud tools plus a few exports)
- Retaining logs for 12 months or longer (your policy, contracts, and audit period drive the number)
- Daily alert triage and weekly privileged activity review (cadence is your choice; follow it once written)
- A specific detection count or rule library
If your policy says identity provider admin events are retained for at least 13 months and privileged activity is reviewed weekly, the evidence must show both for the sampled period.
For design input, NIST SP 800-92, Guide to Computer Security Log Management covers log generation, storage, analysis, and disposal, and NIST SP 800-53 Rev. 5 includes audit and accountability themes (for example event logging, audit record review, protection of audit information, and audit record retention) and system monitoring themes. Use them as reference points and map carefully to the controls you assert through control mapping.
The Logging and Monitoring File at a Glance
| Pipeline stage | What to keep | Stronger evidence | Weaker evidence |
|---|---|---|---|
| Scope | Log source inventory tied to in-scope systems | Dated inventory with owner per source | "We log everything" |
| Collection | Proof each source is flowing | Collector health checks or ingestion reports over time | One screenshot of a log search |
| Protection | Who can alter or delete logs | Access list, immutability or write-once settings, change history | Logs stored where engineers have delete rights |
| Retention | Configured retention per source | Exported settings matching policy, plus oldest available record | Policy says 12 months, settings say 30 days |
| Detection | Alert rules with purpose and owner | Rule catalog with dates, owners, severity, and change history | Rules exist only inside the tool with no owner |
| Routing | Where alerts go | On-call schedule, route config, periodic test records | Alerts to an archived chat channel |
| Review | Scheduled reviews | Dated review tickets or sign-offs with findings | "The team keeps an eye on it" |
| Triage | Disposition of each meaningful alert | Ticket per alert with reason, actor, and time | Alerts auto-closed with no record |
| Escalation | Link to incident process | Alert linked to incident ticket when declared | Incident ticket with no detection source |
| Tuning | Changes to noisy or broken rules | Change tickets explaining why a rule changed | Rules silently disabled |
Building the Evidence Step by Step
1. Inventory log sources by system
Start from your system description and list the in-scope systems. For each one, record which log sources are collected, where they go, and who owns them. Common sources include:
- Identity provider sign-ins, MFA events, and admin actions
- Cloud provider audit trails (API calls, IAM changes, network and storage configuration changes)
- Production database access and administrative queries where feasible
- Source control events such as branch protection changes, admin role grants, and force pushes
- CI/CD deployment events
- Endpoint and device management events for managed laptops
- Application security events such as authentication failures, permission changes, and data exports
Date the inventory, version it, and review it when systems enter or leave scope. A new production database without a log source entry is a gap auditors notice.
2. Prove collection keeps working
Collection fails quietly. An agent is uninstalled, an API token expires, or a new region is never wired up. Keep evidence that sources stayed healthy across the period, such as collector health alerts, ingestion volume checks, or a recurring task that confirms each critical source has recent events. When a source goes dark, record when it was noticed and when it was restored.
3. Protect logs from tampering
Logs are only useful as evidence if the people being logged cannot quietly change them. Record who has write or delete access to log storage, whether immutability or write-once settings are on, and how changes to logging configuration are approved. Route changes to log pipelines through your change management process so a disabled trail leaves its own trail.
4. Set and evidence retention
Write retention per source in policy, then show the configured value matches. A practical check is to export the retention settings and query the oldest available record for each critical source. Retention should cover your audit period and any investigation window your policy promises. See data retention for the broader principle, and keep cost-driven reductions documented as approved decisions rather than silent edits.
5. Maintain an alert rule catalog
For each detection, keep the purpose, the log source, the logic in plain language, severity, owner, routing, and the date it was created or last changed. Prioritize rules that map to risks in your risk assessment, for example:
- New members added to privileged groups in the identity provider
- MFA disabled for a user or policy
- Root or break-glass account use in the cloud provider
- Changes to logging configuration or log storage permissions
- Branch protection disabled on production repositories
- Unusual data export volume from production systems
- Repeated failed sign-ins followed by a success from a new location
6. Test alert routing
Alert routes break after tooling and team changes. Test routes on a schedule and after major changes, and keep a record of each test: which rule, which route, who received it, and when. A test record is often the cleanest evidence that monitoring would have worked during a quiet period with few real alerts.
7. Run and record scheduled reviews
Some monitoring is rule-driven. Some is human review on a cadence. Common review types include daily alert queue triage, weekly privileged activity review, and monthly rule and coverage review. For each review, keep who performed it, when, what was in scope, what was found, and any follow-up tickets. A review with "no findings" is still evidence when it is dated and signed.
8. Record triage dispositions
Every meaningful alert should end with a recorded disposition: expected activity with a reason, false positive with a tuning follow-up, fixed with a link to the change, or escalated to an incident. Keep the actor and timestamp. This is where many Type 2 samples fail, because alerts were handled in chat and the record disappeared.
9. Escalate cleanly into incident response
When triage determines an alert is a security event that meets your incident criteria, open or link an incident record and hand off to the process in Incident Response Evidence for SOC 2. The incident record should name the detection source, and the alert record should point to the incident. That link is how auditors connect CC7.2 monitoring to CC7.3 evaluation and response.
10. Tune with a trail
Noisy rules get disabled, thresholds get raised, and coverage shrinks without anyone deciding it should. Treat rule changes as changes: a ticket, a reason, an approver where your policy requires one, and a date. Disabled detections without a record look like control drift.
Review Cadence Options
SOC 2 does not set a cadence. Pick one that fits your risk and staffing, write it down, and follow it.
| Review | Common cadence | Evidence to keep |
|---|---|---|
| Alert queue triage | Daily or each on-call shift | Queue export or tickets with dispositions |
| Privileged activity review | Weekly or biweekly | Dated review record with findings and follow-ups |
| Collector and source health | Weekly or automated alert | Health report or alert history |
| Alert route test | Quarterly and after tooling changes | Test record naming rule, route, recipient, time |
| Rule catalog and coverage review | Monthly or quarterly | Catalog version, changes made, gaps logged |
| Retention verification | Quarterly or semiannually | Settings export and oldest record query results |
Type 1 vs Type 2 Considerations
For a Type 1 report, auditors look at whether logging and monitoring controls are suitably designed and in place at a point in time. A current log source inventory, retention settings, the alert rule catalog, routing configuration, and a recent review record usually support that.
For a Type 2 report, auditors test operation across the period. Expect requests such as:
- A population of alerts for the period, then samples with triage dispositions
- Review records for sampled weeks or months
- Proof that retention covered the full period (the oldest records still exist)
- Change history for alert rules and logging configuration
- Evidence that sources were healthy, or documented gaps when they were not
- Links from sampled incidents back to their detection source
A review backfilled the week before fieldwork does not replace period history. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
Evidence Examples by Scenario
| Scenario | Stronger evidence | Weaker evidence |
|---|---|---|
| Privileged group change | Alert fired, ticket shows approved change reference and disposition | Alert auto-resolved with no record |
| Quiet period with no alerts | Route test records and weekly review sign-offs | Nothing to show for six weeks |
| Log source went dark | Health alert, ticket with outage window and restore time | Gap discovered during fieldwork |
| Retention reduced to save cost | Approved change with risk acceptance and updated policy | Setting changed silently |
| Noisy rule disabled | Tuning ticket with reason and replacement rule | Rule missing from catalog with no history |
| Alert escalated | Alert linked to incident ticket with detection time | Incident ticket says "found by engineer" with no source |
| New in-scope system | Inventory updated with sources and owner on go-live | System live for months before logging was added |
Common Mistakes
- Collecting logs with no alert rules and no owners
- No inventory, so nobody can say which in-scope systems are covered
- Retention settings that do not match policy or the audit period
- Engineers who can delete or alter the logs that record their own actions
- Alerts routed to channels or inboxes nobody watches
- Triage done in chat with no durable disposition record
- Scheduled reviews that stop during busy quarters
- Detections disabled for noise with no ticket or replacement
- Incident tickets that do not name the detection source
- Dashboard screenshots offered as proof of operation over time
These patterns create findings and real detection risk. When you find one, record it and track the fix through Exception Management and Audit Findings Remediation.
Operating Model: Make Monitoring Evidence Routine
1. Name owners
Assign an owner for the log platform, an owner for each critical source, and an owner for each alert rule. Ownership is what turns logs into a control.
2. Write the standard
Document in-scope sources, retention per source, review cadence, routing, and triage expectations in a procedure that matches live settings. Link it to your information security policy.
3. Make triage leave a ticket
Configure alerts that matter to open or update a ticket, or require a disposition field in the alerting tool that can be exported later.
4. Schedule reviews as recurring tasks
Recurring tickets with due dates create their own evidence. Missed reviews become visible instead of forgotten.
5. Watch the watchers
Alert on logging changes, collector failures, and permission changes to log storage. Monitoring that can be turned off silently is weak evidence.
6. Dry-run sampling before fieldwork
Pick three random weeks from the period. Pull the alert population, two triage records, the privileged activity review, and the retention check for each. Fix gaps and record any late items honestly.
Linking Logging and Monitoring to Neighboring Controls
- Change management. Logging configuration and rule changes should follow change management, and deploy events are a common log source.
- Access control. Privileged access alerts back up logical access and least privilege controls between reviews.
- Onboarding and offboarding. Alerts on re-enabled or lingering accounts catch lifecycle failures. See Employee Onboarding and Offboarding Evidence for SOC 2.
- Vulnerability management. Configuration and exposure detections support CC7.1 alongside vulnerability management.
- Incident response. Alerts that meet incident criteria hand off to incident management.
- Zero Trust. Continuous verification depends on telemetry. See Mapping Zero Trust Controls to SOC 2 Evidence.
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For logging and monitoring, that can mean dated history for triage tickets, scheduled review tasks, rule change tickets, and related workflow steps, so you can show reviews and dispositions across the period without rebuilding the story from chat. Your log platform, SIEM, cloud provider, and alerting tools remain the systems of record for log data and detections. AuditFlo.co is not a SIEM or log management platform, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors or on-call responders.
To see the workflow for your stack, request a demo.
Final Thoughts
Logging and monitoring evidence is the proof behind your detection pipeline: an inventory of in-scope log sources, protected storage with retention that matches policy, an owned alert rule catalog, tested routes, scheduled reviews, and a recorded disposition for each meaningful alert. SOC 2 does not dictate your tools, retention length, or cadence, so write the standard, follow it, and keep timestamps that survive Type 2 sampling. Keep this playbook distinct from incident response evidence, and link the two so every incident has a detection source and every escalated alert has an incident.
If you are building the broader readiness path, start with What Is Monitoring?, Incident Response Evidence for SOC 2, Change Management Evidence for SOC 2, What Is SOC 2 Evidence?, and how to prepare for a SOC 2 audit.
FAQ
Does SOC 2 require a SIEM?
No. The Trust Services Criteria describe monitoring and evaluation outcomes, not a product. Many teams use native cloud logging plus targeted alerts. What matters is that sources, retention, detections, reviews, and dispositions match your written controls and leave evidence.
How long should we retain logs for SOC 2?
SOC 2 does not set a number. Your policy, contracts, and investigation needs set it. Retention should at least cover the audit period you are reporting on so sampled events can still be shown. Many teams choose 12 months or longer for security-relevant sources.
What is the difference between logging and monitoring evidence?
Logging evidence proves events are captured, protected, and kept. Monitoring evidence proves someone or something watches those events through rules and reviews, and that results were acted on. Auditors usually want both.
How is this different from incident response evidence?
Monitoring evidence covers detection, triage, and disposition of alerts. Incident response evidence starts when an event is declared an incident and covers severity, containment, communications, and post-incident review. The alert record and incident record should link to each other.
What if we had very few alerts during the audit period?
Quiet periods are common. Show that monitoring was still operating: route test records, collector health history, scheduled review sign-offs, and the rule catalog. That evidence shows the absence of alerts reflects reality, not a broken pipeline.
Do we need to review every log line?
No. Reviewing raw logs at scale is not practical. Use alert rules for known risks, scheduled reviews for high-risk activity such as privileged changes, and record what each review covered and found.
Does AuditFlo.co collect or analyze our logs?
No. AuditFlo.co helps organize dated evidence such as tickets, reviews, and workflow history from systems you already use. Your logging and alerting tools remain the systems of record, and AuditFlo.co does not replace your auditor.