SOC 2 does not certify a monitoring product or prescribe one universal check interval. It is an examination of a service organization's system description and controls against selected Trust Services Criteria. Security is included in every SOC 2 examination; Availability is an additional category when it is relevant to the organization's commitments and system requirements.
Monitoring matters when it is part of those scoped controls: the auditor evaluates design and, for a Type 2 report, operating effectiveness over the examination period. This guide focuses on evidence—configuration, ownership, alerts, exceptions, incidents, and review—not on claiming that installing uptime monitoring creates SOC 2 compliance. The authoritative starting point is AICPA & CIMA's SOC 2 Trust Services Criteria hub and the current Trust Services Criteria resource.
What Is SOC 2?
SOC 2 (System and Organization Controls 2) is a security framework developed by the American Institute of CPAs (AICPA). It defines criteria for how service organizations handle customer data across five Trust Services Criteria:
- Security — Protection against unauthorized access
- Availability — System is available for operation as agreed
- Processing Integrity — System processing is complete, accurate, and authorized
- Confidentiality — Information designated as confidential is protected
- Privacy — Personal information is collected and used appropriately
In common usage, a Type 1 report addresses control design as of a specified date; a Type 2 report also addresses operating effectiveness over a specified period. Your CPA firm determines the examination period and evidence request—there is no universal 6- or 12-month rule for every engagement.
Monitoring is central to Availability, which is the criterion most directly relevant to web applications.
Scope Monitoring From Commitments and Criteria
The Availability category groups three criteria under A1:
A1.1 — Capacity Management The organization identifies, monitors, and evaluates processing and infrastructure capacity to maintain sufficient capacity to support service commitments.
A1.2 — Environmental Protections and Availability Monitoring The organization monitors the availability of systems and infrastructure to detect threats and security incidents affecting availability.
A1.3 — Recovery and Backup The organization tests recovery procedures, including backups and recovery from incidents.
For an availability control, auditors commonly test whether the control description matches actual operation:
- In-scope systems are monitored as the control states
- Availability alerts exist and are configured
- Alert notifications go to appropriate personnel
- Incidents are detected and responded to in a documented manner
- Monitoring has been operating for the full audit period (Type II)
What Monitoring Evidence Auditors Need
When your auditor asks for monitoring evidence, they typically request:
1) Configuration Evidence
Proof that monitoring is configured and active:
- Screenshots or exports of monitoring checks configured for each production system
- Alert configuration showing who receives alerts and on what channels
- Check interval settings (1-minute or 5-minute checks)
- SSL certificate monitoring configuration
- Uptime SLA targets and corresponding monitoring thresholds
2) Historical Uptime Data
Evidence that your systems have been available as committed:
- Uptime reports for the audit period (often 6-12 months)
- Incident history — when incidents occurred, how long they lasted
- Response times and latency trends
- SLA reports if you have committed availability percentages to customers
Auditors compare your claimed SLA (e.g., 99.9% uptime) against your actual uptime data. Gaps between claimed and actual availability are findings.
3) Incident Response Records
Evidence that incidents were detected and responded to:
- Incident log with timestamps: when detected, acknowledged, resolved
- Alert records showing which alerts fired and when
- Post-mortem documentation for significant incidents
- Evidence that alerts went to the right personnel
4) Monitoring Coverage
Evidence that all relevant systems are monitored:
- List of production services and confirmation each has monitoring
- Health check endpoints on applications
- SSL certificate monitoring for all customer-facing domains
- Database and infrastructure monitoring
Example Availability Controls and Evidence
Continuous Availability Monitoring
Control objective: Monitor the in-scope services and dependencies needed to meet documented availability commitments.
Implementation:
- HTTP/HTTPS checks on selected customer-facing endpoints at a justified cadence
- Health check endpoints on all applications that test internal dependencies
- Database and cache connectivity checks
- Background job health via heartbeat monitoring
- SSL certificate monitoring with 14-day expiry alerts
Evidence produced: Historical uptime records, alert history, check configuration exports.
Alert Configuration and Routing
Requirement: Alerts notify appropriate personnel promptly.
Implementation:
- Define who receives which alerts (by service, by severity)
- Configure multiple alert channels (Email + SMS for critical services)
- Escalation policies — if primary contact does not respond, escalate
- Document the on-call rotation and escalation procedures
Evidence produced: Alert configuration screenshots, on-call schedule records, alert delivery logs.
Incident Detection and Response
Requirement: Incidents are detected, recorded, and responded to with documented procedures.
Implementation:
- Every alert triggers a documented response process (runbook)
- Incidents are logged with start time, detection time, resolution time
- Post-mortems for significant incidents include root cause and corrective actions
- MTTR tracked and reviewed
Evidence produced: Incident log, runbooks, post-mortem documents, resolution timestamps.
Response Time Monitoring
Requirement: System performance is monitored and within committed levels.
Implementation:
- Response time tracking on all production endpoints
- Alerts when response time exceeds defined thresholds
- Historical response time trends for the audit period
Evidence produced: Response time reports, latency trend data.
Customer Communication
Possible control: Communicate qualifying incidents according to the organization's documented process and commitments.
Implementation:
- Public status page showing current system status
- Status page updated during incidents
- Historical incident records publicly visible
- Customer-facing communication during incidents
Evidence produced: Status page history, incident communication records.
SOC 2 Monitoring Checklist
Use this checklist to prepare evidence for the availability controls described in your system and confirmed with your CPA firm:
Continuous Monitoring:
- HTTP/HTTPS checks on all production endpoints (1-minute intervals)
- Health check endpoints on all applications
- SSL certificate monitoring with 14-day expiry alerts
- DNS monitoring on customer-facing domains
- Background job health via heartbeat monitoring
- Database connectivity monitored
Alert Configuration:
- Alerts configured for all production checks
- Critical alerts go to SMS/phone (not email only)
- On-call rotation documented and implemented
- Escalation policy configured
- Alert channels tested and verified
Incident Management:
- Incident log maintained with timestamps
- Runbooks exist for common alert types
- Post-mortem process documented and practiced
- MTTR tracked and reviewed monthly
Evidence Retention:
- Uptime reports retained for at least the audit period (12+ months recommended)
- Alert history retained
- Incident records maintained
- Monitoring configuration documented (screenshots, exports)
Customer Communication:
- Status page configured and public
- Historical incidents visible on status page
- Incident communication process documented
How SOC 2 Maps to Monitoring Features
| SOC 2 Requirement | Monitoring Feature | Evidence Type |
|---|---|---|
| Continuous availability monitoring | HTTP checks every 1 minute | Uptime reports, check history |
| Internal system health | Health check endpoints | Application health logs |
| Certificate management | SSL expiry monitoring | Certificate alert records |
| Performance monitoring | Response time tracking | Latency reports |
| Incident detection | Alert history | Alert delivery timestamps |
| Alert notification | Multi-channel alerts | Alert configuration screenshots |
| Incident response | Escalation policies | Escalation records |
| Background service health | Heartbeat monitoring | Heartbeat history |
| Customer communication | Status page | Status page history |
| Availability SLA evidence | Uptime percentage reports | Monthly uptime reports |
Common SOC 2 Monitoring Exceptions
Exception: A service named in the control was not monitored Internal tools, admin panels, or staging environments are not monitored. Auditors may flag this if these systems handle customer data.
Remediation: Add monitoring for all systems that handle customer data, even internal ones.
Exception: Alert delivery does not match the written control The policy promises an acknowledged escalation path, but evidence shows alerts only reached an unattended mailbox.
Remediation: Align the control wording and actual routing, assign owners, test delivery, and retain acknowledgment or escalation evidence.
Finding: No escalation policy If the primary on-call person does not respond, there is no documented process for escalation.
Remediation: Configure escalation policies with secondary contacts and defined escalation timeframes.
Finding: Uptime data does not match SLA commitments Customer agreements promise 99.9% uptime but actual uptime during the audit period was 98.7%.
Remediation: Align SLA commitments with actual achievable uptime, and address monitoring gaps that allowed incidents to go undetected.
Finding: No documented incident response process Incidents are handled ad-hoc without a documented procedure.
Remediation: Write a basic incident response playbook and runbooks for common alert types. Reference these in your security policies.
Prepare Monitoring for the Examination Period
If you are beginning SOC 2 preparation:
Before the period:
- Configure the monitoring coverage stated by the scoped control and system description
- Configure SSL and DNS monitoring
- Set up multi-channel alerts with SMS escalation
- Create a basic incident log template
- Write your first runbooks
During the period:
- Configure a status page
- Begin tracking MTTR monthly
- Document on-call rotation and escalation policies
- Run a tabletop exercise to test incident response
- Start collecting uptime evidence for the audit period
Throughout the Type 2 examination period:
- Maintain monitoring consistently throughout the period
- Log all incidents with timestamps
- Conduct post-mortems for significant incidents
- Export uptime reports monthly as evidence
- Review and update runbooks based on incidents
How Webalert Helps with SOC 2
Webalert can supply monitoring records to a scoped SOC 2 control, but the organization must retain and review the evidence its control language requires:
- Scheduled monitoring — one-minute checks on paid plans and ten-minute checks on Free
- Response-time history — average, minimum, and maximum charts, with retention determined by plan
- SSL monitoring — Certificate expiry alerts with lead time
- DNS monitoring — Availability monitoring at the infrastructure level
- Multi-channel alerts — Email and Slack on all plans; SMS, webhooks, Discord, and Microsoft Teams on paid plans
- Status pages — Customer-facing availability communication
- Heartbeat monitoring — Background service availability evidence
The canonical pages do not promise full-period report exports or a complete audit-grade alert archive. Export or preserve required evidence through your documented process, verify retention against the audit period, and see features and pricing for current boundaries.
Summary
- Availability controls should be designed from the selected criteria, service commitments, risks, and system description; the auditor tests the control language actually in scope.
- Type II audits cover a 6-12 month period — you need monitoring in place long before the audit starts.
- Auditors look for configuration evidence, historical uptime data, incident records, and alert routing documentation.
- Common findings: no escalation policy, email-only alerts, gaps in monitoring coverage, actual uptime below SLA commitments.
- Put controls in operation before the period begins and confirm the evidence retention window with your CPA firm.
- A status page can support a documented communication control, but SOC 2 does not universally require a public status page.
Monitoring supports specific scoped controls. The SOC 2 opinion depends on the complete system description, selected criteria, control design, and tested operation—not on monitoring alone.