System Operations
AOT availability, ingestion health, telemetry latency, processing capacity, storage pressure, alerting thresholds, and customer-facing monitoring commitments are measured and escalated when thresholds are exceeded.
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
The team can see whether the service and its critical processing paths are healthy, detect customer-impacting degradation early, and route actionable alerts to someone who can respond.
First SOC 2 program
Monitor a few customer-critical journeys, service errors, latency, queue depth, storage, and dependency health. Put actionable thresholds on an owned on-call route and record the resulting incidents or tuning decisions.
As the company scales
Use service objectives, synthetic checks, dependency telemetry, capacity signals, alert ownership, and trend reviews to distinguish real customer risk from noise across regions and product components.
Map the customer actions and background processing paths whose failure would materially affect availability, including the dependencies needed for each path.
You should end up with: Prioritized service and dependency map
Choose availability, error, latency, saturation, queue, ingestion, storage, and dependency measures that reveal whether each critical path works.
You should end up with: Health-signal catalog with owners and data sources
Define warning and urgent conditions using observed behavior and business impact, then document who receives each alert and what first response is expected.
You should end up with: Approved thresholds and alert-routing matrix
Trigger safe test conditions or synthetic failures to confirm alerts fire, reach the correct person, contain enough context, and create a durable response record.
You should end up with: Alert-path test with timing and findings
Review customer impact, missed conditions, noisy alerts, capacity pressure, and recurring failures; assign improvements and retain the decision record.
You should end up with: Dated monitoring review and action tracker
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.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Critical services and customer journeys are measured over a defined period using signals that expose availability, error, latency, and saturation conditions.
Include this context
Service and environment
Include this context
Covered period
Include this context
Availability or health measure
Include this context
Data source
Include this context
Threshold or objective
Include this context
Last refresh
Weak evidence to avoid
A current uptime percentage with no service boundary, underlying data source, date range, or threshold.
Confirm what the record proves
Independent or service-level checks ran at known intervals and recorded whether critical endpoints or workflows responded as expected.
Include this context
Check name
Include this context
Target and environment
Include this context
Check interval
Include this context
Expected result
Include this context
Execution timestamp
Include this context
Observed result
Weak evidence to avoid
A green status badge that does not identify the tested target, interval, response condition, or history.
Confirm what the record proves
The team monitors event flow, queue depth, delay, failures, and backlog conditions that could degrade processing or hide service problems.
Include this context
Pipeline or queue
Include this context
Metric name
Include this context
Covered period
Include this context
Expected range
Include this context
Observed value
Include this context
Source
Weak evidence to avoid
One current message count without trend history, expected range, queue identity, or processing delay.
Confirm what the record proves
Monitoring conditions have documented trigger values, severity, ownership, and escalation behavior tied to practical service impact.
Include this context
Alert name
Include this context
Signal and scope
Include this context
Trigger condition
Include this context
Severity
Include this context
Route or owner
Include this context
Effective version
Weak evidence to avoid
A vendor-default alert enabled without an owner, service scope, business rationale, or effective date.
Confirm what the record proves
Triggered service conditions were acknowledged, assessed, escalated when needed, and resolved with an attributable operating record.
Include this context
Ticket ID
Include this context
Trigger and detected time
Include this context
Affected service
Include this context
Owner
Include this context
Impact and decision
Include this context
Resolution time
Weak evidence to avoid
A chat message saying the service recovered with no linked alert, owner, impact assessment, timestamps, or ticket.
Type 1
The current critical-service map, active health checks, monitoring thresholds and routes, and a recent alert-path test or monitoring review showing the design in use at the review date.
Type 2
Every availability, performance, ingestion, capacity, or dependency alert generated by the covered monitoring rules during the review period, plus every scheduled monitoring review and alert-path test due during that period, including acknowledged, escalated, tuned, failed, and missed occurrences.
Export alert history directly from every covered monitoring platform and reconcile each alert ID to its on-call or incident disposition; separately reconcile the monitoring-review and test calendar to completed records, preserving failed, missed, and rescheduled items rather than omitting them.
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: The team can see whether the service and its critical processing paths are healthy, detect customer-impacting degradation early, and route actionable alerts to someone who can respond.
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.
Export alert history directly from every covered monitoring platform and reconcile each alert ID to its on-call or incident disposition; separately reconcile the monitoring-review and test calendar to completed records, preserving failed, missed, and rescheduled items rather than omitting them.
The current critical-service map, active health checks, monitoring thresholds and routes, and a recent alert-path test or monitoring review showing the design in use at the review date.
Every availability, performance, ingestion, capacity, or dependency alert generated by the covered monitoring rules during the review period, plus every scheduled monitoring review and alert-path test due during that period, including acknowledged, escalated, tuned, failed, and missed occurrences.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Critical services and customer journeys are measured over a defined period using signals that expose availability, error, latency, and saturation conditions.
For each selected record, confirm it demonstrates Independent or service-level checks ran at known intervals and recorded whether critical endpoints or workflows responded as expected.
For each selected record, confirm it demonstrates The team monitors event flow, queue depth, delay, failures, and backlog conditions that could degrade processing or hide service problems.
For each selected record, confirm it demonstrates Monitoring conditions have documented trigger values, severity, ownership, and escalation behavior tied to practical service impact.
For each selected record, confirm it demonstrates Triggered service conditions were acknowledged, assessed, escalated when needed, and resolved with an attributable operating record.
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.