System Operations
Required logs, review activities, retention requirements, integrity controls, and evidence production expectations are defined and implemented for security, operational, audit, and customer-support records.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Security and operational events are recorded, protected, and kept long enough for the team to investigate incidents, explain important activity, and show that monitoring actually occurred.
First SOC 2 program
Start with the logs that answer who accessed production, what changed, what failed, and what security alerts fired. Send them to one searchable location, restrict deletion, and alert when a critical source stops reporting.
As the company scales
Maintain a risk-ranked log-source inventory with named owners, required events, retention settings, health monitoring, access controls, and periodic coverage reconciliation across products and environments.
List the authentication, privileged activity, configuration change, deployment, security detection, data-access, and service-health events needed to investigate the in-scope service.
You should end up with: Logging requirements mapped to systems and event types
Record each source, environment, owner, destination, expected event volume, and collection method, then verify events arrive with useful timestamps and identities.
You should end up with: Current log-source inventory with ingestion validation
Limit who can alter or delete logs, separate administrative duties where practical, and configure retention based on investigation, customer, and review needs.
You should end up with: Approved access and retention configuration
Alert on missing sources, ingestion delay, unexpected volume changes, parsing failures, and storage limits; route failures to an accountable owner.
You should end up with: Log-health alerts and resolved failure tickets
Reconcile expected sources to active ingestion, document gaps and decisions, and retain dated exports or review records that show the process ran.
You should end up with: Periodic coverage review with evidence package
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
The team has identified the required security and operational log sources, their owners, and whether each source is actively collected.
Include this context
Source system
Include this context
Environment
Include this context
Required event types
Include this context
Owner
Include this context
Log destination
Include this context
Collection status
Weak evidence to avoid
A list of logging tools with no environments, owners, event scope, or active-collection status.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Log records have configured retention and access protections that match the team's documented investigation and review needs.
Include this context
Source or storage tier
Include this context
Configured retention
Include this context
Effective date
Include this context
Deletion permissions
Include this context
Configuration owner
Include this context
Configuration evidence
Weak evidence to avoid
A screenshot of a default retention value that does not identify the source, effective date, or who can delete records.
Confirm what the record proves
Required events are searchable and the team can review ingestion health, security activity, and operating signals for a defined scope and period.
Include this context
Named data sources
Include this context
Environment
Include this context
Query or dashboard purpose
Include this context
Date range
Include this context
Filters
Include this context
Last refreshed time
Weak evidence to avoid
A link to a live dashboard with no preserved date range, filters, source list, or export.
Confirm what the record proves
The team preserved period-specific event or review records that can be traced to the covered sources and extraction method.
Include this context
Export timestamp
Include this context
Covered period
Include this context
Included sources
Include this context
Query or extraction method
Include this context
Exporter
Include this context
Evidence location
Weak evidence to avoid
A cropped screenshot of one event with no source, query, covered period, or extraction details.
Type 1
The current required-source inventory, configured retention and access settings, active connector status, and a recent dated coverage review showing the logging process is designed and in use at the review date.
Type 2
Every scheduled log-coverage or retention review due during the review period and every collection-health exception generated for a required source, including missed reviews, outages, investigations, and resolutions.
Reconcile every source marked required in the inventory to an active connector and retained event sample, then reconcile the scheduled review calendar and log-health alert history to review records or resolved exception tickets; explain every unmatched source, date, or alert ID.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Security and operational events are recorded, protected, and kept long enough for the team to investigate incidents, explain important activity, and show that monitoring actually occurred.
Compare the documented owner with the intended role (Security Operations / Engineering / Infrastructure), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.
Reconcile every source marked required in the inventory to an active connector and retained event sample, then reconcile the scheduled review calendar and log-health alert history to review records or resolved exception tickets; explain every unmatched source, date, or alert ID.
The current required-source inventory, configured retention and access settings, active connector status, and a recent dated coverage review showing the logging process is designed and in use at the review date.
Every scheduled log-coverage or retention review due during the review period and every collection-health exception generated for a required source, including missed reviews, outages, investigations, and resolutions.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The team has identified the required security and operational log sources, their owners, and whether each source is actively collected.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Log records have configured retention and access protections that match the team's documented investigation and review needs.
For each selected record, confirm it demonstrates Required events are searchable and the team can review ingestion health, security activity, and operating signals for a defined scope and period.
For each selected record, confirm it demonstrates The team preserved period-specific event or review records that can be traced to the covered sources and extraction method.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.