SOC 2 audits scrutinize how your organization manages the availability, security, and confidentiality of the systems you operate on behalf of customers. For SaaS companies going through SOC 2 Type I or Type II audits, uptime monitoring is not optional — it is direct evidence for the Availability Trust Services Criterion, and its absence creates a significant audit finding.
This guide covers what SOC 2 requires for availability, how the Trust Services Criteria for Availability map to monitoring requirements, how uptime monitoring evidence supports Type II audits, how to structure incident logging and response time documentation, status page requirements, and how to use Vigilmon monitoring data as audit evidence throughout your SOC 2 program.
What Is SOC 2?
SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of CPAs (AICPA). A SOC 2 report provides independent third-party attestation that your organization has controls in place that satisfy one or more of the Trust Services Criteria (TSC):
- Security (CC) — required in all SOC 2 audits; covers logical access, change management, risk assessment, incident response, and monitoring
- Availability (A) — covers whether systems are available for operation and use as committed or agreed
- Confidentiality (C) — covers whether information designated as confidential is protected
- Processing Integrity (PI) — covers whether system processing is complete, valid, accurate, timely, and authorized
- Privacy (P) — covers collection, use, retention, disclosure, and disposal of personal information
Most SaaS companies pursuing SOC 2 include both Security and Availability criteria, since customers rely on their platform being available as a prerequisite to security being meaningful.
SOC 2 Type I vs. Type II
Type I audits assess whether your controls are suitably designed as of a point in time. An auditor reviews your documented controls, policies, and technical configurations and opines on whether the design is appropriate.
Type II audits assess whether your controls operated effectively over a period of time — typically 6 to 12 months. The auditor reviews evidence that controls were actually executed during the audit period: logs, monitoring data, alert history, incident records, and review documentation.
Uptime monitoring evidence is most critical for Type II audits: you need to demonstrate that you continuously monitored system availability, detected failures promptly, responded to alerts, and documented incidents throughout the audit window.
Trust Services Criteria for Availability
The AICPA's Trust Services Criteria for Availability are organized under the "A" category. The specific criteria most relevant to uptime monitoring:
A1.1 — Current Processing Capacity
The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
This criterion requires evidence that you track system capacity and availability over time. Uptime monitoring provides this evidence: check history, response time trends, and alert records demonstrate continuous monitoring of system behavior and capacity.
Evidence Vigilmon provides for A1.1:
- Check history showing system availability over the audit period
- Response time history showing performance trends
- Alert history showing when capacity or availability thresholds were breached
A1.2 — Environmental Protections and Recovery
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.
This criterion covers backup and recovery processes, including monitoring of backup jobs. Heartbeat monitoring for backup jobs directly addresses this criterion — you have evidence that backup processes were continuously monitored and failures were detected promptly.
Evidence Vigilmon provides for A1.2:
- Heartbeat monitor history for backup jobs showing continuous monitoring
- Alert records demonstrating backup job failure detection
- Documentation of heartbeat window configuration (shows deliberate design of monitoring coverage)
A1.3 — Recovery Plan Testing
The entity tests recovery plan procedures supporting system availability to meet its objectives.
This criterion requires evidence of disaster recovery and incident response testing. Monitoring data contributes context: incident records that show detected outages, documented response times, and resolution documentation demonstrate that recovery procedures exist and were activated.
Evidence Vigilmon provides for A1.3:
- Incident history with detection time, alert firing time, and resolution time
- Alert routing records showing escalation procedures were followed
- Response time benchmarks demonstrating detection speed
Security Criteria Related to Monitoring
The Security (CC) category also contains criteria with direct monitoring implications:
CC7.2 — System Monitoring
The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
CC7.2 specifically requires monitoring for anomalies — including availability anomalies. Uptime monitoring with alert history provides evidence that system behavior was continuously observed and deviations were detected and analyzed.
Evidence Vigilmon provides for CC7.2:
- Continuous check history demonstrating ongoing monitoring
- Alert records showing anomaly detection
- Documentation of alert responses showing anomaly analysis
CC9.1 — Risk Mitigation
The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.
Uptime monitoring is a risk mitigation activity for the business disruption risk of service unavailability. The existence of uptime monitoring, documented alert procedures, and incident response processes satisfies this criterion as evidence of deliberate risk mitigation.
Availability Evidence Structure for SOC 2 Type II Audits
A SOC 2 Type II auditor reviewing your Availability controls will test whether monitoring was in place, continuous, and effective throughout the audit period. Here's how uptime monitoring data maps to audit evidence:
Evidence Category 1: Continuous Monitoring Coverage
What auditors look for: Were systems monitored continuously throughout the audit period? Were monitoring configurations documented and maintained?
Vigilmon evidence:
- Export of check history for the full audit period (typically 6–12 months) showing a continuous record of checks
- Screenshot or export of monitoring configuration showing which systems were monitored, at what intervals, and with what alert thresholds
- Documentation of when monitors were created and any configuration changes during the audit period
Best practice: At the start of your SOC 2 audit period, document your monitoring configuration — list all monitored endpoints, check intervals, and alert routing. If you add or change monitors during the audit period, record why. Auditors want to see intentional design, not ad hoc configuration.
Evidence Category 2: Incident Detection and Response
What auditors look for: When availability incidents occurred, were they detected promptly? Was there a documented response? Were incidents logged?
Vigilmon evidence:
- Alert history showing when alerts fired, when services recovered, and the duration of each incident
- Webhook/notification logs showing that alert notifications were delivered to on-call personnel
- Incident response documentation correlating Vigilmon alerts with internal incident ticket creation and resolution
Best practice: For every Vigilmon alert that fires during your audit period, create a corresponding incident ticket (in Jira, Linear, PagerDuty, or your incident management tool) that records: detection time (from Vigilmon alert), acknowledgment time, root cause analysis, and resolution time. This creates an auditable incident log with timestamps.
Evidence Category 3: System Availability Metrics
What auditors look for: What was your system's actual availability during the audit period? Did it meet the availability commitments in your service agreements?
Vigilmon evidence:
- Uptime percentage calculated from check history (Vigilmon's check history allows you to calculate uptime percentage for any period)
- Response time history showing performance trends
- SSL certificate monitoring showing certificates were maintained without expiry
Best practice: Calculate uptime percentage quarterly during your audit period and document it. If your customer contracts include SLA commitments (e.g., 99.9% uptime), this documentation demonstrates SLA compliance and gives auditors quantitative evidence of availability performance.
Evidence Category 4: Backup and Job Monitoring
What auditors look for: Are backup processes monitored? Are critical background jobs monitored for failures?
Vigilmon evidence:
- Heartbeat monitor history for backup jobs showing continuous monitoring
- Alert history for heartbeat failures showing detection of backup job failures
- Configuration documentation showing heartbeat windows are appropriately sized
Best practice: Create a named heartbeat monitor for each of your backup jobs, data export jobs, and any other background process required for availability or data integrity. The monitor name should clearly identify the process being monitored (e.g., "daily-database-backup", "weekly-config-export").
Building an Audit-Ready Monitoring Program
Monitoring Inventory
Your SOC 2 audit will begin with auditors asking what systems and services you operate. Before the audit period starts, create a monitoring inventory document that maps each significant system to its Vigilmon monitors:
| System | Monitor Type | Check Interval | Alert Channel | |---|---|---|---| | Production web application | HTTP (health endpoint) | 1 minute | PagerDuty | | API gateway | HTTP (health endpoint) | 1 minute | PagerDuty | | Database (primary) | TCP | 1 minute | PagerDuty | | Database (replica) | TCP | 5 minutes | Slack | | Cache layer | TCP | 1 minute | PagerDuty | | Daily backup job | Heartbeat | 24h window | PagerDuty | | Data export pipeline | Heartbeat | 4h window | PagerDuty | | All production SSL certificates | SSL expiry | N/A (30-day alert) | Slack |
This inventory becomes a control document that demonstrates the scope of your monitoring coverage.
Alert Response Procedures
SOC 2 auditors look for evidence that alerts are defined procedures, not ad hoc responses. Document your alert response procedures:
Production Service DOWN (Vigilmon consensus alert)
1. On-call engineer acknowledged via PagerDuty within 5 minutes
2. Initial status update posted to #incidents Slack channel
3. Root cause investigation begins
4. Status page updated if outage duration exceeds 5 minutes
5. Incident ticket created in issue tracker with Vigilmon alert timestamp
6. Customer communication if outage duration exceeds 15 minutes
7. Post-incident review within 48 hours of resolution
8. Incident log updated with timeline, root cause, and corrective actions
Heartbeat Monitor EXPIRED (backup job)
1. On-call engineer paged via PagerDuty
2. Backup job logs reviewed for errors
3. Backup job re-triggered if failure confirmed
4. Root cause documented in incident ticket
5. Backup completion verified before heartbeat acknowledged
These documented procedures satisfy CC7.2 (anomaly analysis) and demonstrate that monitoring alerts result in structured responses rather than being ignored.
Status Page as Availability Evidence
Many SOC 2 audit frameworks expect companies to communicate availability information to customers. A public or private status page that reflects your uptime monitoring data provides:
- Customer-visible availability information during incidents
- A published record of past incidents (incident history)
- Demonstration that availability management is customer-facing, not just internal
Configure your status page to reflect Vigilmon alert status. When Vigilmon detects and confirms an outage, your status page should update to reflect the incident. When services recover, the status page should return to operational status.
For SOC 2 purposes, the status page serves two functions:
- Customer communication (satisfies the "communication to customers about availability" expectation in the Availability criteria)
- Audit evidence (a timestamped public record of incidents that auditors can review independently)
Incident Logging and Response Time Documentation
What to Record for Each Incident
For SOC 2 Type II audits, every availability incident needs a corresponding log entry. At minimum, document:
| Field | Source | Example | |---|---|---| | Incident ID | Internal ticketing system | INC-2026-0143 | | Detection time | Vigilmon alert timestamp | 2026-03-12 14:23:05 UTC | | Acknowledgment time | PagerDuty acknowledgment | 2026-03-12 14:26:11 UTC | | Affected system | Vigilmon monitor name | Production API Gateway | | Impact description | Engineer assessment | API endpoints returning 503 | | Root cause | Post-incident analysis | Database connection pool exhausted | | Resolution time | Vigilmon recovery timestamp | 2026-03-12 14:51:43 UTC | | Incident duration | Calculated | 28 minutes 38 seconds | | Corrective action | Engineering decision | Connection pool limit increased, auto-scaling configured | | Post-incident review | Review doc link | INC-2026-0143-PIR.md |
Time-to-Detection as a Control Effectiveness Metric
SOC 2 auditors evaluating your Availability controls will assess how quickly your monitoring detects incidents. Time-to-detection is calculated as: incident start time (when the outage actually began) minus detection time (when Vigilmon fired the alert).
For uptime monitoring with 1-minute check intervals, your time-to-detection is at most 1–2 minutes (one check interval plus alert delivery time). This is a strong control effectiveness metric: "Our monitoring detects service unavailability within 2 minutes of occurrence."
Document this metric explicitly for your audit:
- "Our production systems are checked every minute from multiple geographic probe locations."
- "Alert notifications are delivered via PagerDuty within 30 seconds of consensus confirmation."
- "Maximum time-to-detection is approximately 90 seconds (one check interval plus notification delivery time)."
Response Time SLA Evidence
If your customer contracts include SLA commitments (uptime percentages, maximum incident duration, response time commitments), your monitoring data must demonstrate compliance.
Uptime SLA example: 99.9% monthly uptime = maximum 43.8 minutes of downtime per month.
From Vigilmon check history, calculate your monthly uptime percentage:
Monthly uptime % = (Total checks - Failed checks) / Total checks × 100
Example: 43,200 checks in June (1 per minute × 60 × 24 × 30)
28 failed checks (one outage of ~28 minutes)
Uptime: (43,200 - 28) / 43,200 × 100 = 99.94%
Export this calculation quarterly and retain it as SLA compliance evidence.
SOC 2 Monitoring Quick Reference
Availability criteria monitoring requirements:
- [ ] All production services monitored with documented check intervals
- [ ] Monitoring covers HTTP/HTTPS endpoints, TCP ports, and critical SSL certificates
- [ ] Backup jobs and critical background processes monitored via heartbeat
- [ ] Alert routing documented: who gets paged, under what conditions
- [ ] Check interval supports time-to-detection SLA commitments (1-minute for critical systems)
Incident logging requirements:
- [ ] Every Vigilmon alert that fires creates a corresponding incident record
- [ ] Incident records include: detection time, acknowledgment time, root cause, resolution time
- [ ] Incident duration calculated and recorded
- [ ] Post-incident reviews conducted and linked to incident records
- [ ] Incident log retained for audit period plus retention period (typically 12+ months)
Audit evidence package:
- [ ] Monitoring configuration export (list of monitors, check intervals, alert routing)
- [ ] Check history export for full audit period
- [ ] Alert history export for full audit period
- [ ] Heartbeat monitor history for backup and critical background jobs
- [ ] Uptime percentage calculation by month for the audit period
- [ ] Incident log with timestamps for all availability incidents
- [ ] Status page incident history for the audit period
- [ ] Alert response procedure documentation
SOC 2 control mapping:
- A1.1 (Capacity monitoring): Vigilmon check history + response time history
- A1.2 (Recovery infrastructure): Heartbeat monitoring for backup jobs
- A1.3 (Recovery plan testing): Incident records with detection and response times
- CC7.2 (System monitoring): Check history demonstrating continuous monitoring
- CC9.1 (Risk mitigation): Monitoring program as availability risk mitigation documentation
Common SOC 2 Monitoring Gaps
Monitoring Only Started When the Audit Began
A Type II audit covers a period — typically 6 to 12 months. If monitoring was implemented the day before the audit period started, you have minimal evidence of continuous control operation. Implement monitoring well before your target audit period and retain all data from the start.
Vigilmon helps here: Vigilmon retains check history and alert history for your full usage period. Historical data for the audit window is available for export at any time.
No Heartbeat Monitoring for Backup Jobs
Auditors reviewing the A1.2 criterion (recovery infrastructure) specifically look for evidence that backup processes are monitored. Many teams monitor their web endpoints thoroughly but have no monitoring for backup jobs, export jobs, or data integrity checks. These silent failures are a common audit finding.
Fix: Create a Vigilmon heartbeat monitor for every scheduled backup or recovery-related job. The heartbeat history becomes your A1.2 evidence.
Alerts That Nobody Responded To
If Vigilmon fired alerts during the audit period and there's no corresponding incident ticket, acknowledgment record, or post-incident documentation, those unacknowledged alerts become negative evidence — they show your monitoring detected a problem but your response procedures weren't followed.
Fix: Every Vigilmon alert must result in a documented response. Use PagerDuty to enforce acknowledgment tracking and automatically create incident tickets when alerts fire.
No Response Time Documentation
Auditors testing A1.1 (capacity monitoring) look for evidence that you track not just availability but performance. Response time history demonstrates that you monitor performance trends, not just binary up/down status.
Vigilmon helps here: Vigilmon's response time history is built in. Export response time data alongside availability check history as part of your audit evidence package.
Monitoring Configuration That Doesn't Match Systems in Scope
If your SOC 2 audit scope includes five production services and your monitoring covers two of them, the gap between scope and coverage is an audit finding. Auditors will ask for evidence of monitoring for every system in your audit scope.
Fix: Before your audit period begins, enumerate your systems in scope and verify Vigilmon monitors exist for each one. Your monitoring inventory document should match your SOC 2 system scope documentation.
Conclusion
SOC 2 Type II audits require evidence that your availability controls operated continuously and effectively throughout the audit period. Uptime monitoring is the primary source of that evidence: check history demonstrates continuous monitoring, alert records demonstrate anomaly detection, and incident logs demonstrate response.
The monitoring architecture — 1-minute checks for production systems, heartbeat monitoring for backup jobs, SSL certificate monitoring, consensus-based alerting that eliminates false positives, and documented alert response procedures — directly satisfies the Availability Trust Services Criteria and several Security criteria that include monitoring requirements.
Teams that implement uptime monitoring specifically to support SOC 2 audits often discover that they also reduce actual downtime duration: the monitoring that generates audit evidence also catches real incidents faster. The investment in SOC 2-ready monitoring pays operational dividends beyond the audit itself.
Try Vigilmon free at vigilmon.online — no agents, no credit card, multi-region consensus alerting, heartbeat monitoring for backup jobs, response time history, and SSL certificate monitoring. All with the check history and alert history your SOC 2 auditors will need.
Tags: #soc2 #compliance #monitoring #uptime #audit #availability #vigilmon #devsecops #sre #trustservicescriteria #2026