SOC 2 Audit Logs: What Counts as Evidence & What's Rejected
Learn what makes SOC 2 audit logs valid, why auditors reject evidence, and how to configure your systems for continuous compliance and automated log retention.
Introduction
For many senior engineers and tech leads, a SOC 2 (System and Organization Controls) audit feels like a tax on productivity. It is often perceived as a bureaucratic exercise in generating screenshots and filling out spreadsheets. However, as infrastructure moves toward cloud-native architectures and automated deployments, the nature of audit evidence has shifted fundamentally. We are moving away from the era of "point-in-time" manual checks and toward a model of continuous observability. In this landscape, audit logs are no longer just troubleshooting tools; they are the primary legal and technical evidence of your organization’s security posture.
The challenge is that auditors do not accept just any log file. In a SOC 2 Type II audit, the auditor is looking for proof that your controls were operating effectively over a specific observation period—usually six to twelve months. If your logging configuration is flawed, or if your logs lack the necessary metadata to prove their integrity, you risk a "qualified" report or an outright failure. This is particularly painful because logging gaps are often discovered months after the fact, when it is impossible to go back in time and recreate the missing data.
As a senior engineer, your goal is to build a logging pipeline that is "audit-ready" by design. This means moving beyond screenshots and manual exports toward automated, immutable evidence streams. This guide will detail exactly what counts as valid evidence, why auditors reject certain logs, and how to configure your systems to ensure a frictionless audit process.
The Anatomy of Valid SOC 2 Evidence
What makes a log "evidence" rather than just "data"? To an auditor, valid evidence must satisfy several criteria: completeness, accuracy, and integrity. If a log cannot be proven to be a complete and untampered record of the events it purports to describe, it will be discarded.
1. Completeness and the Observation Period
A common mistake is providing logs that only cover a portion of the audit window. If your audit period is January 1st to December 31st, but your log retention policy is set to 90 days, you have a massive evidence gap. Auditors verify completeness by looking at the timestamps. They need to see a continuous stream of events without unexplained silences. This is why "sampling" is often done by the auditor; they will pick random dates throughout the year and ask to see the logs for those specific 24-hour windows.
2. Tamper-Evidence and Immutability
Evidence must be protected from unauthorized alteration. If an engineer has the permissions to both perform an action (like deleting a database) and modify the logs that record that action, the log is not considered reliable evidence. Valid logs are typically streamed to a centralized, read-only repository (like a hardened S3 bucket or a dedicated security account) where even administrators have restricted delete permissions.
3. Contextual Metadata
A log that says "User updated setting" is useless. A valid audit log must answer the "Five Ws":
- Who: The unique identifier of the actor (IAM user, service account, or API key).
- What: The specific action taken (e.g.,
UpdateSecurityGroup,DeleteS3Bucket). - When: An accurate, synchronized timestamp (preferably in UTC).
- Where: The source IP address and the specific resource affected (ARN, UUID).
- Outcome: Whether the action succeeded or failed (e.g., a 200 OK vs. a 403 Forbidden).
Why Auditors Reject Logs
Understanding why logs are rejected is just as important as knowing how to collect them. Rejection usually stems from a break in the "chain of custody" or a lack of technical detail.
Manual Curation and "Cleaned" Logs
If you provide a CSV file that looks like it was manually edited in Excel, an auditor will immediately flag it. Any human intervention in the evidence pipeline introduces the possibility of bias or deletion of incriminating events. Auditors prefer raw, structured data (JSON or Syslog) pulled directly from the source system via API or automated export. As noted in the discussion on moving beyond screenshots, manual evidence collection is prone to human error and is inherently suspect in a modern audit.
Lack of Correlation
If you provide an application log showing a user logged in, but you cannot provide a corresponding identity provider (IdP) log showing the MFA challenge, the auditor cannot verify that your "MFA Required" control is actually working. Rejection often happens because the logs are siloed; the auditor cannot trace an action from the edge to the database.
Missing System-Generated Timestamps
Logs that rely on client-side timestamps are often rejected because client clocks can be manipulated or drift. Auditors look for server-side or ingestion-time timestamps to verify the actual sequence of events.
Summarized or Aggregated Data
Dashboards are not evidence. A screenshot of a Datadog graph showing "0 Unauthorized Access Attempts" is a visualization, not a log. The auditor needs the underlying raw events that prove the graph is accurate. If you cannot produce the raw records that back up your monitoring dashboards, the evidence will be rejected.
Critical Systems That Must Produce Logs
For a SOC 2 audit, you must identify your "in-scope" systems. Generally, any system that touches customer data (PII/PHI) or manages the infrastructure that hosts that data is in scope.
Identity and Access Management (IAM)
This is the most scrutinized area. You must log:
- Login successes and failures.
- MFA enrollment and usage.
- Privilege escalations (e.g.,
AssumeRolecalls). - Changes to IAM policies or group memberships.
Production Infrastructure (Cloud Provider)
If you are on AWS, GCP, or Azure, you must have platform-level logging enabled (e.g., CloudTrail, Cloud Audit Logs). This captures every API call made against your infrastructure.
- Retention Requirement: Minimum 1 year for SOC 2 Type II.
- Configuration: Must be enabled across all regions, even those you don't actively use, to detect "shadow" infrastructure.
CI/CD Pipelines and Source Control
Since SOC 2 covers Change Management, your logs must show:
- Who approved a Pull Request.
- The transition of code from staging to production.
- Automated test results that gate deployments.
- Any manual overrides of the deployment pipeline.
Database and Data Stores
Auditors look for "Access to Sensitive Data" logs. This includes:
- Administrative access to the database (DBA activity).
- Changes to database schemas.
- Exports or bulk downloads of sensitive tables.
Technical Configuration for Audit-Readiness
To ensure logs are accepted, you need to implement specific technical configurations. This involves defining your logging as code and ensuring the destination is secure.
Example: Securing an Evidence Bucket
If you are storing logs in AWS S3, your configuration should enforce immutability through S3 Object Lock or strict bucket policies. Below is a conceptual JSON policy for a centralized logging bucket that prevents deletion and ensures all data is encrypted.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnforceEncryption",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::company-audit-logs/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "RestrictDelete",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": "arn:aws:s3:::company-audit-logs/*"
},
{
"Sid": "AllowCloudTrailWrite",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::company-audit-logs/AWSLogs/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}Log Structure and Schema
Standardizing your logs into a structured format like JSON makes them easier for auditors to parse and for your team to search during an audit. A high-quality audit event should look like this:
{
"event_version": "1.0",
"event_time": "2023-10-25T14:30:01Z",
"source_ip": "192.168.1.50",
"actor": {
"id": "USR-9921",
"email": "engineer@company.com",
"role": "SRE-Lead",
"mfa_authenticated": true
},
"action": "database_schema_change",
"resource": {
"type": "rds_instance",
"id": "prod-db-01",
"arn": "arn:aws:rds:us-east-1:123456789012:db:prod-db-01"
},
"request_parameters": {
"command": "ALTER TABLE users ADD COLUMN ssn_encrypted...",
"request_id": "req-882-abc"
},
"response": {
"status": "success",
"code": 200
},
"user_agent": "aws-cli/2.0.0",
"request_context": {
"session_id": "sess-991283",
"region": "us-east-1"
}
}This JSON structure provides everything an auditor needs. It shows the actor, the specific resource, the exact command, the status of the action, and whether MFA was used.
Retention and Lifecycle Management
One of the most common reasons for a SOC 2 "exception" (a finding) is the lack of log retention. For Type II audits, you must demonstrate that your controls were in place throughout the entire period.
- Hot Storage (30-90 days): Keep logs in a searchable format (Elasticsearch, CloudWatch Logs, Splunk) for immediate incident response and operational monitoring.
- Cold Storage (1-7 years): Move logs to low-cost storage like S3 Glacier or GCS Archive. SOC 2 typically requires 1 year, but many enterprise customers or other regulations (like HIPAA or PCI-DSS) may require 7 years.
- Legal Hold: Ensure your logging system supports "legal hold" functionality, preventing the automated deletion of logs if an investigation or audit is ongoing.
To manage this, use lifecycle policies. For example, in AWS, you can set an S3 Lifecycle rule to transition objects to GLACIER_IR (Instant Retrieval) after 90 days and permanently delete them after 365 days. This ensures you meet the SOC 2 requirement without ballooning your storage costs.
Organizing Logs for Frictionless Retrieval
When the auditor arrives, the last thing you want to do is spend a week writing custom scripts to pull data. You should organize your logs so that they are easily accessible based on the controls they support.
1. Centralized Evidence Warehouse
Do not make the auditor log into five different consoles. Centralize your logs into a single "Security Account" or a dedicated compliance data lake. This allows you to grant the auditor (or your internal compliance lead) scoped, read-only access to a single location.
2. Tagging and Categorization
Use metadata tagging to link logs to specific SOC 2 criteria. For example, logs related to access changes can be tagged with Control-AC-1 (Access Control). This mapping makes it easy to prove to an auditor that you have coverage for every control in your System Description.
3. Automated Evidence Collection
Instead of manual exports, use automated tools to pull logs and store them in an "Evidence Folder" per audit period. Tools that automate this process reduce the friction of the audit and ensure that the evidence is collected consistently. This approach aligns with the philosophy of moving beyond screenshots by creating a continuous, verifiable evidence trail.
4. Key Takeaways for Log Organization
- Maintain a Log Map: Document which systems produce which logs and where they are stored.
- Standardize Timezones: Always use UTC across all systems to avoid confusion during event correlation.
- Enable Alerting on Log Gaps: Set up a "dead man's switch" alert. If your log volume drops to zero for a specific critical system, your SRE team should be alerted immediately. A gap in logs is a gap in evidence.
The Role of Automation in Evidence
In a traditional audit, the auditor asks for a sample of 25-40 change tickets and then asks for the logs to prove those changes were authorized. In a modern "automated" audit, you can provide the auditor with a query or a report that covers 100% of the population.
Auditors generally prefer 100% population testing over sampling because it provides a higher level of assurance. By automating your log collection and ensuring they meet the "valid evidence" criteria, you can move toward a model where the audit is almost entirely self-service. You provide the auditor with access to the evidence warehouse, and they can verify the controls themselves without interrupting your engineering team's sprint.
Conclusion
SOC 2 compliance is often viewed as a documentation burden, but for a senior engineer, it is actually a data engineering challenge. The difference between a painful audit and a smooth one lies in the integrity and accessibility of your logs.
To ensure your logs count as valid evidence:
- Ensure they are complete, covering the entire observation period.
- Make them tamper-evident by storing them in a centralized, restricted environment.
- Provide rich context, including the who, what, when, and where of every action.
- Avoid manual curation; any log that has been touched by a human is likely to be rejected.
- Move beyond screenshots and embrace automated, API-driven evidence collection.
By treating your audit logs as a critical piece of infrastructure rather than an afterthought, you not only satisfy the requirements of SOC 2 but also build a more resilient and observable system. When logs are structured, immutable, and continuous, they serve the dual purpose of satisfying auditors and providing your engineering team with the high-fidelity data needed to debug complex production issues. The goal of a tech lead should be to build a system where the "truth" is always recorded, always protected, and always ready for inspection.
This content was generated by AI.