What are the SOC 2 logging requirements?

The Trust Services Criteria do not publish a list of log sources or a fixed retention period. They expect you to monitor systems for anomalies that could be security events (CC7.2), evaluate what you detect (CC7.3), and keep reliable information to run your controls. In practice that means three things written in your own policy and then shown in records: which events are logged and where they go, how long logs are kept and who can alter them, and which alerts exist, who answers them and who reviews the results and how often. The auditor tests what you wrote against what you did, so the policy should describe only what you run.

How long do SOC 2 logs have to be retained?

The criteria do not set a number. One guide says the Trust Services Criteria do not mandate specific durations for data retention, and another says retention should cover the audit period and your incident-investigation needs. Guides that do give a figure tend to say twelve months and mostly borrow it from other frameworks or from practice, so treat it as a common choice and not a rule. The generated Logging and Monitoring Policy states its own period in statement 4.4, quoted on this page. Whatever period you adopt, the auditor tests whether your platform settings enforce it throughout the observation period.

What should we alert on for SOC 2?

The criteria leave the rules to you, and the outside guides converge on the same families: repeated failed logins, privilege escalation or new administrators, disabled logging, configuration changes outside the normal process and unusual data movement. The generated policy lists its own minimum set in statement 4.7 and requires each rule to have a severity, an owner and a runbook. One guide's test is useful: an alert must reach a human within a defined response target, and thousands of untriaged alerts a day count as a weakness, not as coverage.

How often do logs have to be reviewed?

No source we read gives a required frequency, and one says the auditor tests against the frequency in your own policy. The generated policy commits to a weekly review of alerts, privileged actions and log source health, plus a quarterly review of detection coverage and log platform access. Pick a cadence you will actually keep, because a missed review is easy to see in the records and can become an exception in the report.

What evidence do auditors ask for on logging and monitoring?

Typically the alert rules (an export or screenshot), a dashboard or inventory showing the log sources, the retention setting, the on-call or escalation configuration, and a sample of alerts with timestamps and the response to each. For Type II they sample across the observation period, so you need records from early, middle and late in it, including the weekly review records. The CC7.2 evidence list on this page comes from the Policyseed crosswalk and is a starting point to adjust after talking to your CPA firm.

Can a small team without a security operations center meet the monitoring criteria?

The criteria describe outcomes, so a small team can monitor with a few well-chosen alert rules routed to whoever is on call, a short weekly review and a quarterly check of coverage. What matters is that the alerts are acted on and the work is recorded. Staffing is a decision you document: if nobody can respond at night, say what the after-hours response actually is, and do not promise a response time you cannot meet.

SOC 2 logging and monitoring requirements: what to log, how long, and who reviews it

Updated 25 October 2026

SOC 2 expects you to log security-relevant events, watch them for anomalies, keep the logs for a period you choose, protect them from tampering, and show that a person acted on the alerts. It does not name a SIEM, a list of log sources or a retention period. Those decisions go in your own policy, and the auditor tests whether your records match what you wrote. This guide covers what to log, how long to keep it, what to alert on and what review evidence looks like, with the Policyseed Logging and Monitoring Policy quoted as one concrete example.

Short answer: the criteria set the outcome, your policy sets the numbers

A SOC 2 report is written by a CPA firm after it examines your controls against the Trust Services Criteria. The criteria that cover logging say what has to be true, for example that you monitor for anomalies that could be security events, and leave the log sources, the retention period and the tool to you. The outside guides we read agree on that and differ on the details:

Source	Criteria and events	Retention	SIEM
SOC 2 Auditors	Puts logging and monitoring mainly under CC7.2, with CC7.1 and CC7.3. Gives no fixed event list; says to aggregate logs from cloud infrastructure, the identity provider, applications, endpoints and the network.	No number. Says retention should cover the audit period and incident-investigation needs.	Says the criteria do not mandate a specific tool such as a SIEM.
Konfirmity, logging and monitoring	Does not map logging to a numbered criterion. Lists logins, configuration changes, network connections, API calls, access decisions, identity provider logs and deployment pipeline activity.	No SOC 2 figure. Says many teams keep security logs for at least twelve months, a practice and not a rule.	Not required; suggests a SIEM or a log analytics platform, and managed detection as an option.
Konfirmity, data retention	Not about event lists.	Says the Trust Services Criteria do not mandate specific retention durations. Lists periods from other frameworks (NERC, ISO 27001 guidance, SOX, PCI DSS) and its own 12 to 24 month schedule.	Not discussed.
Konfirmity, SIEM use cases	Maps SIEM use cases to CC7.1, CC7.2 and CC7.3, among others.	Says SOC 2 typically looks back 12 months and recommends keeping logs at least one year; notes an audit period might be six months.	Does not say it is required, but argues continuous monitoring is nearly impossible without one.

Three of the four pages are from one vendor that sells compliance services, and the fourth is another site that publishes SOC 2 guidance, so read all of them as one side. The useful overlap is that no criterion fixes a number or a product. Where they differ is retention: the ones that give a figure treat a year as common and none cites a criterion for it. Your auditor and your largest customer's contract are the real sources for a minimum.

The criteria logging supports

The generated Logging and Monitoring Policy is mapped to these criteria in the Policyseed crosswalk. The wording is a paraphrase, not the AICPA text:

CC7.2 (Monitoring for anomalies): Systems and logs are monitored for unusual activity that could indicate a security event, and alerts reach a person who is expected to act on them.
CC7.3 (Evaluating security events): When something suspicious is detected, the company decides whether it is a real incident, how serious it is, and whether a control failed.
CC7.1 (Detecting vulnerabilities and configuration changes): The company watches for new vulnerabilities and for unexpected changes to its infrastructure configuration, and fixes what it finds within defined timeframes.
CC2.1 (Quality information): The company collects and keeps the information it needs to run its controls, such as an accurate asset inventory, logs and a risk register, and that information is reliable.
A1.1 (Capacity management): The company tracks how much of its infrastructure capacity is being used, forecasts demand, and adds capacity before it runs out.

CC7.2 is the center of it: logs only matter to this criterion if somebody monitors them and an alert reaches a person who acts. CC7.3 is what happens next, since a detected event has to be evaluated and classified, which is why the policy hands confirmed or probable events to the Incident Response Policy. Availability monitoring applies only when Availability is in your scope. To see how the criteria fit together, read the SOC 2 controls list.

What to log

No source gives one authoritative list, but they overlap: authentication and failed logins, privilege and role changes, configuration changes, API activity, and the audit logs of your cloud, identity provider and deployment pipeline. The generated policy turns that into a list tied to the tools in your answers. The text below is not written by hand. It is rendered from the policy template for the Northwind Cloud Inc sample intake, so it changes when the template does, and the platform and product names are the sample's.

Logging and Monitoring Policy, 4.1: At minimum the following are logged: for each platform in AWS and Vercel, the provider's management and API audit log, identity and access changes, network flow or firewall logs where available, and access logs for storage holding customer data; Okta sign-in events, multi-factor enrollment changes and administrator actions; the organization audit log of GitHub and repository security setting changes; GitHub Actions runs and configuration changes; Northwind authentication successes and failures, password and multi-factor changes, authorization failures, privileged actions, API key creation and revocation, data exports and deletions, and security setting changes; Kandji enrollment and compliance changes; endpoint security agent events; and vendor administrator audit logs where available.

A log is only useful if it can be trusted and correlated, so the policy also fixes what each record contains and what must never appear in it:

Logging and Monitoring Policy, 4.2: Each record includes a UTC timestamp, source system, acting identity, action, target, result and, where relevant, source IP address and a correlation identifier. Passwords, session tokens, API keys, private keys, full card numbers, health information and other sensitive data are never logged; fields that could contain them are masked before emission.

Two practical points. First, write the list for your own systems; a source you do not have should not be in the policy, and a source you do have but cannot log, such as a vendor that exposes no audit log, goes in as an approved exception. Second, keep an inventory of log sources and check it against your asset list, because an unlogged system is the gap an auditor finds by comparing the two.

Where logs go: centralize, then restrict

The guides recommend centralizing logs, and some name a SIEM or log analytics platform as one option. The policy's wording depends on whether you name a logging tool in the generator. The same sentence is shown twice from the same intake:

With a tool named: Logs from all sources are forwarded to your logging tool within 15 minutes of generation. Sources have write-only access, and the platform is the system of record for investigations.

With none named: Logs from all sources are forwarded to a central log platform designated by Engineering within 15 minutes of generation. Sources have write-only access, and the platform is the system of record for investigations.

The forwarding window, the write-only sources and the "system of record" wording are the template's defaults, not values taken from a criterion, so change them to match how your platform behaves before you adopt the policy.

Does SOC 2 require a SIEM?

No. No criterion names a SIEM or any other product. One guide states that the criteria do not mandate a specific tool such as a SIEM (SOC 2 Auditors), and another says a SIEM is not required while suggesting one among other options (Konfirmity). The strongest pro-SIEM position in what we read is a vendor page saying that without one, the required level of continuous monitoring is nearly impossible (Konfirmity). That page does not claim a mandate, and it is the seller's view of what it takes to demonstrate the outcome.

What the auditor needs is the outcome: logs from your important systems in one searchable place, alert rules that cover the conditions you named, proof that alerts reached a person, and review records. A SIEM, a managed logging service or your cloud provider's native tools can produce that. The SOC 2 Auditors guide, which says a SIEM is not mandatory, also warns that a SIEM producing thousands of low-fidelity alerts a day with no triage process is a control weakness, so the tool alone is not the control. Pick on what you can staff and what you can export as evidence.

Retention: the period is your policy's choice

Retention is the least settled part. The data retention guide says the criteria do not mandate specific durations (Konfirmity), and the logging controls guide says only that retention should cover the audit period and your incident-investigation needs (SOC 2 Auditors). The figures that do appear are borrowed: the data retention guide lists periods from other frameworks, such as PCI DSS, which it describes as twelve months of history with three months readily available for cardholder data, and NERC at six months for logs. Those frameworks are not SOC 2. The SIEM guide adds a practical reading: SOC 2 typically looks back 12 months, and an audit period might be six months, so the logs you keep should outlast the period (Konfirmity).

The Policyseed template picks its own number and says how it is enforced. That is a template default, not a requirement, and you should change it if your contracts, your data or your CPA firm point elsewhere:

Logging and Monitoring Policy, 4.4: Security and audit logs are retained for at least 12 months with the most recent 90 days searchable without restoration; application debug logs are retained for 30 days. Retention is enforced by platform configuration and reviewed under the Data Retention and Disposal Policy.

Logging and Monitoring Policy, 5.7: Retention and archive. Engineering configures 90 days of searchable storage and archive to immutable lower-cost storage through 12 months, after which records are deleted automatically unless a legal hold under the Data Retention and Disposal Policy applies. Settings are verified quarterly.

Whatever you write, the settings have to match. A policy that promises a period while log rotation deletes records earlier is a straightforward exception, because the auditor can compare the setting with the policy. The templates also tie retention to the Data Retention and Disposal Policy, and the free data retention schedule is where the period for each log type belongs. Because a Type II report covers a stretch of time, logs from the start of the observation period still have to exist when the auditor samples near the end of it, and during fieldwork.

The policy also protects what it keeps:

Logging and Monitoring Policy, 4.5: Logs are tamper-resistant: storage is append-only or uses provider immutability, deletion occurs only through the configured retention policy, and no individual, including administrators, holds standing rights to delete or modify records. Disabling a source, changing retention or altering forwarding is a change under the Change Management Policy and raises an alert.

Logging and Monitoring Policy, 4.6: Log access is restricted to Engineering and the Security Owner under the Access Control Policy, administrative access is limited to named individuals, and all access is logged and reviewed quarterly. All systems synchronize time with a trusted source so that events correlate across platforms.

Alerting: rules with owners, and a response target

Logging without alerting leaves CC7.2 unanswered. The guides agree on the rule families: repeated failed logins, privilege escalation, disabled logging, configuration changes and unusual data movement. One of them states the test plainly, that alerts must reach a human within a defined response target, and gives no number for it (SOC 2 Auditors). The response times in a policy are therefore yours to set. The generated policy sets its own minimum rule set and its own timelines:

Logging and Monitoring Policy, 4.7: Alert rules exist for at least: repeated authentication failures or credential stuffing; multi-factor authentication disabled or reset; a new administrator or privilege escalation; changes to cloud identity policies or roles; use of a root, owner or break-glass account; a security group or firewall rule opened to the internet; a storage bucket made public; a secret detected in GitHub; logging disabled; unusual data export or deletion volume; changes to GitHub Actions configuration or deployment credentials; a device falling out of compliance in Kandji; and any endpoint security detection. Each rule has a severity, an owner and a runbook.

Logging and Monitoring Policy, 4.8: Alerts are acknowledged and triaged within defined timelines: Critical within 1 hour at any time; High within 4 business hours; Medium within 2 business days; Low at the weekly review. Any alert assessed as a confirmed or probable security event is escalated under the Incident Response Policy and reported to security@northwindcloud.example.

Two things make this a control the auditor can test and not a promise. Each rule has a severity, an owner and a runbook, so there is something to sample. And the policy says what happens to false positives, so noise does not drown the real alerts:

Logging and Monitoring Policy, 4.11: Alert rules are tuned to keep false positives manageable; changes to a rule's logic, threshold or severity are recorded with the reason, and rules that produced only false positives for a quarter are reviewed for relevance.

Do not copy the timelines unless you can meet them. If nobody can respond within the hour at night, write the response you actually run. A missed target in the records is easier to explain than a target nobody could meet.

Review cadence and the evidence it leaves

No source we read sets a required review frequency. One says the auditor tests against the frequency in your own policies and that a missed review can count as an exception (Konfirmity). That puts the cadence in your hands, and the point is to pick one you will keep. The generated policy commits to a weekly review, a quarterly coverage review and a semi-annual test that the alerts really fire:

Logging and Monitoring Policy, 4.10: The Security Owner or a delegate reviews alert activity, privileged actions and log source health weekly, and reviews detection coverage against 4.1 and 4.7 quarterly, with results documented.

Logging and Monitoring Policy, 5.5: Weekly log review. The Security Owner or delegate reviews the week's alerts and their dispositions, samples privileged actions across AWS and Vercel, Okta and GitHub, confirms every source reported during the week and records the review with date, reviewer and follow-up actions.

Logging and Monitoring Policy, 5.10: Detection testing and reporting. Semi-annually Engineering simulates a sample of the 4.7 conditions, such as a burst of failed logins or a test secret pushed to a sandbox repository, confirms each alert reaches on-call within the expected time and records the results. Each quarter the Security Owner reports to Executive Management on alert volume by severity, acknowledgment times against 4.8, incidents escalated, coverage gaps, availability against objectives and corrective actions.

Each of those leaves a record, which is the evidence. The Policyseed crosswalk lists what an auditor can ask for under CC7.2:

Logging tool alert rules export (for example Datadog monitors) covering authentication failures, privilege changes and production errors
Sample alert notification with timestamp and the on-call response
Centralized logging dashboard screenshot showing production log sources
On-call rotation schedule or escalation configuration

Add the weekly review records (date, reviewer, follow-up), the quarterly catalog and coverage review, the detection test results and the retention verification. For a Type II report the auditor samples across the period, so a review that stops in month four is visible. The SOC 2 evidence checklist puts these next to the rest of your evidence, and the security metrics report turns alert volume and acknowledgment times into the quarterly report to management.

When logging can't be done as written

Some systems cannot forward logs and some vendors expose none. Do not leave the policy saying otherwise. The template routes these cases to a written exception with compensating controls and an expiry date, and the free policy exception register is built for it. Anything you do not log on a system that holds customer data should be a decision someone approved, not an oversight the auditor finds first. To see where logging sits among your other gaps, run the free readiness assessment.

The generator writes the logging policy from your cloud, identity provider, source control, CI/CD and logging tool answers, so the quotes above become your own tools' names. The Audit Kit ($59, one time) tailors the policy statements and procedures to your intake and adds drafts such as the security metrics report and exceptions register. It does not configure your logging, and the CPA firm still decides whether the evidence is enough.

Frequently asked questions

What are the SOC 2 logging requirements?: The Trust Services Criteria do not publish a list of log sources or a fixed retention period. They expect you to monitor systems for anomalies that could be security events (CC7.2), evaluate what you detect (CC7.3), and keep reliable information to run your controls. In practice that means three things written in your own policy and then shown in records: which events are logged and where they go, how long logs are kept and who can alter them, and which alerts exist, who answers them and who reviews the results and how often. The auditor tests what you wrote against what you did, so the policy should describe only what you run.
Does SOC 2 require a SIEM?: No criterion names a SIEM. One outside guide on logging controls states that the criteria do not mandate a specific tool such as a SIEM, and a second guide says a SIEM is not required while recommending a SIEM or log analytics platform. A third guide, from a vendor that sells SIEM-related services, argues continuous monitoring is nearly impossible without one, which is a sales position and not a criterion. What the auditor looks for is centralized logs, alert rules, evidence that alerts reached a person, and review records. A managed logging service, a cloud provider's native tools or a SIEM can all produce those, and the CPA firm decides whether yours is enough for your system.
How long do SOC 2 logs have to be retained?: The criteria do not set a number. One guide says the Trust Services Criteria do not mandate specific durations for data retention, and another says retention should cover the audit period and your incident-investigation needs. Guides that do give a figure tend to say twelve months and mostly borrow it from other frameworks or from practice, so treat it as a common choice and not a rule. The generated Logging and Monitoring Policy states its own period in statement 4.4, quoted on this page. Whatever period you adopt, the auditor tests whether your platform settings enforce it throughout the observation period.
What should we alert on for SOC 2?: The criteria leave the rules to you, and the outside guides converge on the same families: repeated failed logins, privilege escalation or new administrators, disabled logging, configuration changes outside the normal process and unusual data movement. The generated policy lists its own minimum set in statement 4.7 and requires each rule to have a severity, an owner and a runbook. One guide's test is useful: an alert must reach a human within a defined response target, and thousands of untriaged alerts a day count as a weakness, not as coverage.
How often do logs have to be reviewed?: No source we read gives a required frequency, and one says the auditor tests against the frequency in your own policy. The generated policy commits to a weekly review of alerts, privileged actions and log source health, plus a quarterly review of detection coverage and log platform access. Pick a cadence you will actually keep, because a missed review is easy to see in the records and can become an exception in the report.
What evidence do auditors ask for on logging and monitoring?: Typically the alert rules (an export or screenshot), a dashboard or inventory showing the log sources, the retention setting, the on-call or escalation configuration, and a sample of alerts with timestamps and the response to each. For Type II they sample across the observation period, so you need records from early, middle and late in it, including the weekly review records. The CC7.2 evidence list on this page comes from the Policyseed crosswalk and is a starting point to adjust after talking to your CPA firm.
Can a small team without a security operations center meet the monitoring criteria?: The criteria describe outcomes, so a small team can monitor with a few well-chosen alert rules routed to whoever is on call, a short weekly review and a quarterly check of coverage. What matters is that the alerts are acted on and the work is recorded. Staffing is a decision you document: if nobody can respond at night, say what the after-hours response actually is, and do not promise a response time you cannot meet.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.