Sooner or later, every SOC 2 project reaches the same question: what exactly do we have to log? The criteria an auditor tests against never give a list of events, a retention period or a tool. In the whole document, the word “logging” appears exactly once. The criteria describe outcomes, such as detecting anomalies and responding to incidents, and leave you to prove them. This guide translates those outcomes into the logs, retention settings and evidence auditors actually ask for.
The short answer: SOC 2 has no fixed logging checklist. The Trust Services Criteria, mainly CC6 (access) and CC7 (system operations), require you to control and record access, monitor systems for anomalies, evaluate security events and respond to incidents. In practice, auditors expect logs of sign-ins, privilege and access changes, configuration changes and security alerts from every system in scope, proof that someone reviews them and acts, and logs kept long enough to cover the whole audit period. SOC 2 does not name a SIEM (security information and event management system) or set a retention number; you set both in policy, and the auditor checks that you follow it.
Where logging sits in SOC 2
SOC 2 (System and Organization Controls 2) reports are issued by licensed certified public accountant (CPA) firms, which test your controls against the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria. The current edition is the 2017 criteria with points of focus revised in 2022; the criteria themselves have not changed since 2017. Every report covers the Security category, whose criteria are also called the Common Criteria (CC1 to CC9). Availability, Processing Integrity, Confidentiality and Privacy are optional. Logging matters most in the Common Criteria, so every SOC 2 report touches it.
Each criterion comes with points of focus: examples of what a control might address. They are not a mandatory checklist. The only one that says “logging” sits under CC7.2, which lists logging of unusual system activity among the detection procedures an organization may use.
The AICPA text is copyrighted, so the table below paraphrases each criterion and adds what it usually means for logs.
| Criterion | What it covers (paraphrased) | What it means for logs |
|---|---|---|
| CC6.1 | Logical access security over protected information | Record who signs in to what, including administrators and service accounts |
| CC6.2 | Registering, authorizing and removing users | Log account creation, approval and removal, and keep the tickets |
| CC6.3 | Granting, changing and removing access by role | Log role and group changes, especially new administrator rights |
| CC6.6 | Protection against threats from outside the system boundary | Logs from firewalls, virtual private network (VPN) gateways, intrusion detection and endpoint detection show the boundary protections work |
| CC6.8 | Preventing or detecting unauthorized or malicious software | Antivirus and endpoint detection alerts, and records of unapproved software |
| CC7.1 | Detecting risky configuration changes and new vulnerabilities | Configuration change logs, change detection on critical files, and vulnerability scan results |
| CC7.2 | Monitoring system components for anomalies that may be attacks, errors or failures | The core logging criterion: collect logs, alert on anomalies, and watch that monitoring itself works |
| CC7.3 | Evaluating security events to decide whether they are incidents | Triage records: who looked at an alert, what they decided and why |
| CC7.4 | Responding to incidents with a defined program | Incident tickets, actions taken and timelines built from logs |
| CC7.5 | Recovering from incidents | Records of restoration and lessons learned |
| CC8.1 | Authorizing, testing and approving changes | Change logs from code repositories, pipelines and infrastructure, tied to approvals |
| CC4.1 | Ongoing evaluations that controls are present and working | Periodic reviews of the logging setup itself: sources, alerts and gaps |
How SOC 2 criteria map to a logging program
Each step needs evidence that covers the whole audit period
- RecordSign-ins, access and changes. CC6.1 to CC6.3, CC8.1
- MonitorAlerts on anomalies and failures. CC7.1, CC7.2
- EvaluateDecide which events are incidents. CC7.3
- RespondContain, recover, document. CC7.4, CC7.5
- CheckConfirm the setup still works. CC4.1
What events to log for SOC 2
Start from the system description in your SOC 2 report. Every component listed there, and every system that stores or processes customer data, is in scope. For each one, capture the events below.
| Source | Events to capture | Why auditors care |
|---|---|---|
| Identity provider and directory | Sign-ins (success and failure), multi-factor events, new users, disabled users, group and role changes | CC6.1 to CC6.3: proves access is controlled and changes are approved |
| Cloud accounts | Control plane activity: new users and keys, policy changes, security group changes, logging changes | CC6.1, CC7.1: shows who changed permissions or exposed resources |
| Production servers and containers | Administrator logins, privilege use, service changes, process starts on critical hosts | CC6.1, CC7.2 |
| Code and deployment pipeline | Merges to protected branches, pipeline changes, secrets access, repository visibility changes | CC8.1: shows changes were approved and tested |
| Network edge | Firewall denies and allows at the boundary, VPN sign-ins, web application firewall blocks | CC6.6 |
| Endpoints | Malware detections, endpoint detection alerts, disabled protection | CC6.8 |
| The logging system itself | A source that stops sending, a disabled audit log, failed log collection, changes to alert rules | CC7.2 asks you to monitor that detection works |
Each log entry should answer six questions. If your logs cannot answer them, an investigation stalls and an auditor notices.
What a useful audit log entry contains
Illustration: one cloud permission change, as a SIEM shows it after parsing
- When, from a clock synced to a common time source
- Who, as a named person rather than a shared account
- What happened, specific enough to judge the risk
- From where: address, device or session
- Which system, so the event can be tied to the system description
- The outcome, because failures matter as much as successes
Two cautions. Logs can leak the data you protect, so mask passwords, tokens and customer records before long-term storage. And logging everything is not the goal: a smaller set that someone reviews beats a huge archive nobody opens.
How long to keep logs for SOC 2
The Trust Services Criteria do not set a retention period. Your own policy does, and the auditor checks that you follow it. Two facts should drive the number you choose.
- The audit period. A Type 1 report covers whether your controls are suitably designed, without testing how they operated. A Type 2 report tests whether they operated effectively throughout a specified period. The criteria set no length for that period; in practice it commonly runs from 3 months, often for a first report, to 12 months for recurring reports. The auditor picks samples from anywhere in that period, so logs from its first day must still exist when fieldwork happens, often weeks after the period ends.
- Investigations. Attackers can sit in a network for weeks before they are found. Logs that expire after 30 days cannot show how they got in.
Why retention must outlast the audit period
Illustration: a 12-month Type 2 period followed by fieldwork
- Month 1Period startsThe oldest logs the auditor may sample
- Months 1 to 12Controls operateAlerts, reviews and incidents happen and are recorded
- Months 13 to 14FieldworkThe auditor asks for samples from any point in the period
- Month 15Report issuedThe next period is already running
A sensible setting for most SOC 2 companies is at least 12 months, with enough extra to cover fieldwork, and a few recent weeks or months kept fast to search. If other rules apply to you, the strictest one wins. The Payment Card Industry Data Security Standard (PCI DSS), for example, requires 12 months of audit log history with the last three months immediately available. See PCI DSS logging requirements and the retention table in SIEM compliance requirements for the numbers by framework.
The evidence auditors ask for
Expect requests like these during a Type 2 audit. Preparing them before fieldwork saves weeks.
- A logging and monitoring policy that names the systems logged, the events captured, who reviews them, how often, and how long logs are kept.
- A list of log sources that matches the system description, with proof each one is sending.
- Configuration evidence, such as screenshots or exports showing audit logging turned on in the cloud accounts, identity provider and databases.
- Alert samples. The auditor picks alerts from across the period and asks what happened to each one: who looked, what they decided, and the ticket.
- Review records that show logs and alerts were reviewed on the schedule your policy promises.
- Incident records with timelines, actions and lessons learned.
- Access to the logs themselves: who can read, change or delete them. Administrators of a system should not be able to erase its logs quietly.
- Retention settings that match the policy.
- Time synchronization across systems, so timelines from different sources line up.
SOC 2 logging gaps that become exceptions
Problems that turn into exceptions in a Type 2 report
Do you need a SIEM for SOC 2?
No. SOC 2 does not require any specific tool, and a very small company with one cloud account and an identity provider can meet CC7.2 with the native audit logs, a few alerts and a documented weekly review.
A SIEM earns its place when that stops scaling: logs live in many places nobody can search together, native retention is too short or too costly, or audit evidence takes days to assemble.
A SIEM collects the logs in one place, checks them against detection rules, keeps them for the period you set, and records who handled each alert. Compliance automation platforms are a different tool: they track policies, screenshots and settings, but they do not watch events. Many companies use both. See governance, risk and compliance (GRC) tools compared for how the two fit together.
How UTMStack fits
We build UTMStack, so weigh our view accordingly. Here is what it does for SOC 2, and where it stops.
- SOC 2 report. The Enterprise edition includes a SOC 2 framework among its nine compliance frameworks. It maps the 51 SOC 2 requirements it tracks to 34 controls from one library based on National Institute of Standards and Technology (NIST) SP 800-53, checks the controls that can be proven from log data against your events over a recent window (30 days by default), and produces PDF reports and a score history. The free Community edition includes the Cybersecurity Maturity Model Certification (CMMC) 2.0 and the General Data Protection Regulation (GDPR), not SOC 2.
- Honest limit on automation. Many SOC 2 criteria, such as board oversight or vendor management, cannot be proven from logs at all. In the current release, automated checks also cover only part of the criteria that logs could support. Rows without a check show as not evaluated and are left out of the score. You can add your own checks, or record a note and your evidence on any row so the report explains itself.
- Detection for the systems SOC 2 companies run. More than 600 detection rules mapped to MITRE ATT&CK are checked as each log arrives, before storage. They include 73 for Amazon Web Services (AWS), 46 for Azure, 43 for Google Cloud, 57 for Microsoft 365 and 13 for GitHub, plus rules for Windows and Linux hosts through free agents.
- Response and records. Alerts become incidents with a history of who did what. Response flows can block an address, disable an account or isolate a host. That trail of alert, decision and action is what CC7.3 and CC7.4 sampling looks for.
- Retention. UTMStack can keep logs up to five years, with older logs in cold storage that stays searchable without a restore. Cloud plans keep about a month in fast storage and a year in the archive, with longer retention on request.
- What it does not do. UTMStack has no file integrity monitoring, so file-level change detection for CC7.1 needs another tool. It has a Google Cloud parser but no Google Workspace parser, so companies using Google Workspace as their identity provider need another way to bring in those sign-in logs.
UTMStack is priced per device, never by log volume, which keeps the cost of logging everything in scope predictable. Ask for a quote or see pricing. To estimate storage for a year or more of logs, use the SIEM sizing calculator.
Frequently asked questions
Does SOC 2 require a SIEM? No. The Trust Services Criteria name no tools. They require monitoring, evaluation of security events and incident response. A SIEM is a practical way to meet CC7.2 once you have more than a few log sources, but native cloud logs with documented reviews can work for a small environment.
How long do I need to keep logs for SOC 2? SOC 2 sets no number. Keep logs at least long enough to cover your Type 2 period plus fieldwork, which in practice means at least 12 months with some margin. If PCI DSS, the Health Insurance Portability and Accountability Act (HIPAA) or a contract also applies, follow the strictest rule.
What is the difference between Type 1 and Type 2 for logging? A Type 1 report checks that logging and monitoring controls are suitably designed, without testing them over time. A Type 2 report tests that they operated over a period, so the auditor samples alerts, reviews and incidents from across that period. Logging exceptions appear in Type 2 reports, because only Type 2 tests operation.
How often do logs have to be reviewed? As often as your policy says, and the auditor will hold you to it. Real-time alerts for high-risk events plus a documented daily or weekly review of the rest is a common pattern. Never promise a review schedule you cannot evidence.
Can a compliance tool or SIEM produce my SOC 2 report? No. Only a licensed CPA firm can perform the examination and issue the report. Tools collect evidence; the auditor tests it. In 2026 the AICPA published FAQs on how software tools affect SOC 2 examinations, and its peer review board warned reviewers about template-driven reports.
Which SOC 2 criterion covers logging? CC7.2 is the core one: monitoring system components for anomalies. It is also the only criterion whose points of focus use the word “logging”. CC6.1 to CC6.3 cover access logging, CC7.3 and CC7.4 cover what happens after an alert, and CC8.1 covers change records.
Sources
- AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022)
- AICPA, System and Organization Controls: SOC suite of services
- AICPA, FAQs: effect of the use of software tools on SOC 2 examinations (March 31, 2026)
- Journal of Accountancy, AICPA guides peer reviewers to address SOC 2 risks (May 2026)
- PCI DSS v4.0.1, Requirement 10.5.1, available free from the PCI SSC document library
