Your prospective enterprise customer sends a security questionnaire. Question 42: "Do you continuously monitor the availability of your systems?" Question 43: "Do you have documented procedures for detecting and responding to service incidents?"
If your answer to both is "we check manually," that is a deal blocker. Enterprise buyers require SOC 2 compliance because it proves you have the controls, monitoring, and processes to protect their data and maintain service availability.
SOC 2 is not just a checkbox audit. The Availability Trust Services Criteria require continuous monitoring, documented incident response procedures, and evidence that your monitoring actually works. This guide covers what SOC 2 requires from a monitoring perspective and how to build a monitoring setup that satisfies auditors and actually protects your service.
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
SOC 2 Type I is a point-in-time assessment (controls exist). SOC 2 Type II is a period assessment — typically 6-12 months — that proves controls were operating effectively over time. Enterprise buyers almost always require Type II.
Monitoring is central to Availability, which is the criterion most directly relevant to web applications.
The Availability Criterion and What Auditors Check
The SOC 2 Availability criterion (A1) has three core requirements:
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 A1.2 specifically, auditors look for evidence that:
- Systems are continuously monitored
- 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
Monitoring Controls to Implement for SOC 2
Continuous Availability Monitoring
Requirement: Monitor all production systems continuously.
Implementation:
- HTTP/HTTPS uptime checks on every customer-facing endpoint — 1-minute intervals
- 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.
Status Page
Requirement: Customers are informed of availability incidents.
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 verify your monitoring setup satisfies SOC 2 Availability requirements:
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 Audit Findings Related to Monitoring
Finding: No continuous monitoring for some services 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.
Finding: Alert notifications go only to email Email is not considered sufficient for critical systems because delivery is not guaranteed and response time is unpredictable.
Remediation: Add SMS or phone call escalation for critical service alerts.
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.
Starting Your SOC 2 Monitoring Program
If you are beginning SOC 2 preparation:
Months 1-2:
- Set up continuous monitoring on all production services
- Configure SSL and DNS monitoring
- Set up multi-channel alerts with SMS escalation
- Create a basic incident log template
- Write your first runbooks
Months 3-6:
- 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
Months 7-12 (Type II audit 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 provides the monitoring infrastructure and evidence that SOC 2 auditors require:
- Continuous monitoring — 60-second checks on all production endpoints
- Historical uptime reports — Export uptime data for the full audit period
- Alert history — Complete record of when alerts fired and were resolved
- SSL monitoring — Certificate expiry alerts with lead time
- DNS monitoring — Availability monitoring at the infrastructure level
- Multi-channel alerts — SMS and email for audit-compliant alert notification
- Status pages — Customer-facing availability communication
- Heartbeat monitoring — Background service availability evidence
- Response time data — Performance monitoring evidence
See features and pricing for details.
Summary
- SOC 2 Availability criteria require continuous monitoring, alert configuration, incident response procedures, and historical evidence.
- 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.
- Start your monitoring program at least 12 months before your target SOC 2 audit date to have sufficient evidence.
- A status page is required evidence of customer-facing availability communication.
SOC 2 compliance is not just about having monitoring. It is about proving it has been running continuously, alerting correctly, and producing evidence for the full audit period.