Engineering teams building SaaS products, healthcare applications, or enterprise software eventually face a compliance audit. And almost every auditor — for SOC 2, HIPAA, or ISO 27001 — will ask about availability monitoring.
The good news: if you already have uptime monitoring in place, you're likely closer to compliance than you think. The bad news: "we have an uptime monitor" and "we have documentation that satisfies an auditor" are different things. This guide covers both.
Why Availability Monitoring Appears in Compliance Frameworks
All three major frameworks include requirements around system availability and operational monitoring, because availability isn't just a business metric — it's a security control.
- Breaches often start with availability failures. DDoS attacks, ransomware, and misconfigured infrastructure all manifest as availability issues before they're identified as security incidents.
- SLA commitments require evidence. Customers, enterprise buyers, and regulated-industry partners frequently require availability guarantees backed by documented monitoring.
- Downtime can constitute a compliance violation itself. Under HIPAA, prolonged unavailability of protected health information systems can be reportable.
Understanding why auditors ask about monitoring helps you give better answers — and build better monitoring.
SOC 2 Type II: The Availability Trust Service Criterion
SOC 2 is built around five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most SOC 2 audits focus on Security (CC series), but the Availability TSC (A-series controls) directly addresses monitoring.
Relevant controls
A1.1 — Current processing capacity and usage The organization monitors current processing capacity and usage. Your monitoring solution should track whether services are operating within expected capacity bounds, not just whether they're up.
A1.2 — Environmental threats and system availability The organization monitors environmental threats that could impair the availability of the system. This includes external monitoring that checks your services from outside your infrastructure — internal-only monitoring can miss failures that affect external users but not internal systems.
CC7.2 — Anomaly and event monitoring The organization monitors system components and operations and identifies anomalies. Your uptime monitoring should generate documented alerts, and those alerts should be responded to and logged.
CC7.3 — Evaluation of security events When anomalies occur, they're evaluated and responded to. This requires that you can demonstrate, for the audit period, that alerts were generated, acknowledged, and resolved.
What auditors want to see
For SOC 2 Type II (which covers a period of time, typically 6–12 months), auditors aren't just checking that monitoring exists. They're checking that it worked continuously, that alerts were generated when they should have been, and that incidents were responded to.
Evidence they may request:
- Monitoring configuration showing coverage of in-scope systems
- Alert history demonstrating continuous monitoring over the audit period
- Incident logs linking alerts to response actions and resolution timestamps
- Downtime reports showing system availability percentages
- Evidence that monitoring worked (e.g., alerts fired during a known incident)
HIPAA: System Activity Review and Availability
HIPAA's Security Rule (45 CFR Part 164) contains specific technical safeguard requirements relevant to availability monitoring.
Relevant requirements
164.308(a)(1) — Risk Analysis and Risk Management Covered entities must conduct risk analysis that includes identifying threats to the confidentiality, integrity, and availability of ePHI (electronic protected health information). Availability threats must be documented and mitigated.
164.308(a)(6) — Security Incident Procedures Covered entities must implement procedures to identify and respond to security incidents. Prolonged unavailability of systems containing ePHI can itself be a security incident requiring documentation and, in some cases, breach notification.
164.312(a)(2)(ii) — Automatic Logoff This is a technical safeguard related to system access, but it's indicative of the broader principle: systems containing ePHI must be actively monitored and controlled.
164.308(a)(8) — Evaluation Covered entities must periodically evaluate how well their security measures protect ePHI. External uptime monitoring, with documented alert history, contributes to this evaluation.
What HIPAA auditors want to see
HIPAA audits focus on demonstrating that you have implemented reasonable and appropriate safeguards. For availability monitoring:
- Evidence that availability of ePHI systems is monitored continuously
- Documented procedures for responding to availability incidents
- Alert history from the monitoring period
- Evidence of response to downtime events affecting ePHI systems
- Business associate agreements (BAAs) with any third-party monitoring vendors who may receive system metadata
Note the BAA requirement: if your uptime monitoring vendor receives any patient data or system information that could be considered ePHI, you need a signed BAA with them.
ISO 27001: Information Security Management and Monitoring
ISO 27001 is a risk-based standard organized around an Information Security Management System (ISMS). Unlike SOC 2 and HIPAA, it's more principle-based — you define controls based on your risk assessment, then demonstrate they work.
Relevant controls (Annex A)
A.12.1.3 — Capacity Management Systems must be monitored and capacity planned to ensure required performance. This implies tracking availability and performance trends over time.
A.12.4.1 — Event Logging Log events that are relevant to security and operations. Uptime monitoring alerts are security-relevant events and should be logged with timestamps and outcomes.
A.12.6.1 — Management of Technical Vulnerabilities Monitoring for known vulnerabilities includes monitoring that systems are operating correctly — a system with an active exploit may manifest as an availability event first.
A.17.1.1–17.1.3 — Business Continuity ISO 27001 requires that you have continuity planning that addresses availability. External monitoring provides the detection layer for business continuity events.
A.16.1.2–16.1.5 — Security Incident Management Incidents must be identified, reported, and managed. Your monitoring system is part of the identification layer.
What ISO 27001 auditors want to see
ISO 27001 audits evaluate whether your ISMS controls are documented, implemented, and effective.
- Policy documents defining availability monitoring requirements
- Monitoring configuration with evidence it covers in-scope assets
- Procedure documents for responding to availability alerts
- Records demonstrating that monitoring was active and alerts were handled
- Integration of monitoring data into your security event management process
Using Vigilmon for Compliance Evidence
Vigilmon generates several types of evidence directly useful for compliance audits.
Downtime reports
Vigilmon maintains a historical record of outages: when they started, when they resolved, duration, and which regions detected the failure. For SOC 2 availability calculations, you can generate uptime percentages over the audit period.
Export formats: Vigilmon's dashboard shows historical uptime data per monitor. For formal compliance reporting, take screenshots or export data at regular intervals — monthly snapshots during the audit period are a good cadence.
Alert history
Every alert Vigilmon generates is timestamped. For auditors asking "how do you know when your system goes down and what do you do about it?" — your Vigilmon alert history, combined with your incident response records, demonstrates the detection-to-response chain.
To make this auditor-ready:
- Connect Vigilmon alerts to a Slack channel dedicated to incidents
- Use that Slack channel's message history as your alert log
- Document your response to each alert in an incident tracking system (Linear, Jira, PagerDuty)
Multi-region monitoring as evidence of robustness
Vigilmon's multi-region consensus checks — where alerts only fire when multiple geographic probes agree on an outage — demonstrate a monitoring architecture that avoids false positives and is robust to single-region infrastructure failures. This is relevant to ISO 27001's capacity management and SOC 2's availability controls.
SSL certificate monitoring
SSL certificate expiry is a compliance-relevant availability failure. An expired certificate takes your HTTPS service offline for all users. Vigilmon monitors certificate expiry and alerts you before certificates expire — typically at 30 days and 7 days out.
For HIPAA systems, SSL certificate monitoring demonstrates that you're actively managing the availability of encrypted connections protecting ePHI in transit.
Building a Compliance-Ready Monitoring Practice
Document everything before the audit
Auditors need to see that monitoring existed and worked throughout the audit period, not just that monitoring exists now. For a 12-month SOC 2 Type II audit:
- Stand up your monitoring tool at least 12 months before the audit
- Configure it to cover all in-scope systems
- Set up alert routing to create a documented trail
- Run a tabletop exercise or real incident response and document it
Define your uptime SLA in writing
For SOC 2 specifically, if you commit to 99.9% uptime in your terms of service, document how that number is tracked and verified. Vigilmon's historical uptime percentage becomes the evidence that you met (or didn't meet) that commitment.
Classify what you're monitoring
Auditors need to understand which systems are in scope. Create a simple mapping:
| System | Contains ePHI/In-scope data? | Monitored by | Alert channel | |---|---|---|---| | API (api.yourapp.com) | Yes | Vigilmon | #incidents-soc2 | | Admin portal (admin.yourapp.com) | Yes | Vigilmon | #incidents-soc2 | | Marketing site (yourapp.com) | No | Optional | #general-monitoring |
Establish an incident response procedure
Having monitoring is not enough if you can't demonstrate a consistent response process. A minimal documented procedure:
- Alert fires in Vigilmon → delivered to Slack channel
- On-call engineer acknowledges within 15 minutes
- Incident tracked in [your ticketing system] with start time, response actions, resolution time
- Post-incident summary written for outages exceeding 30 minutes
This procedure, applied consistently, is what turns monitoring from "something we have" into "something we can demonstrate to an auditor."
Quick Compliance Checklist
- [ ] External monitoring covers all in-scope systems
- [ ] Monitoring has been active for the full audit period
- [ ] Alert history is exportable and retained
- [ ] Downtime reports show uptime percentages
- [ ] SSL certificate monitoring is active
- [ ] Alert routing creates a documented response trail
- [ ] Incident response procedure is written down
- [ ] BAAs in place with any third-party monitoring vendors (HIPAA)
- [ ] Monitoring configuration is documented in your ISMS (ISO 27001)
- [ ] Monitoring scope is mapped to in-scope assets
Conclusion
Compliance audits can feel like bureaucratic overhead, but availability monitoring requirements exist for good reasons: systems that go unmonitored tend to fail in ways that affect users, data, and security — often simultaneously.
The practical path is: stand up reliable external monitoring early, route alerts through documented channels, maintain your alert history, and build an incident response habit that creates paper trails. When the auditor asks "how do you know when your systems are down?" — you have a real answer backed by real evidence.
Start building your compliance-ready monitoring stack with Vigilmon — free tier includes multi-region monitoring, SSL certificate checks, historical uptime reports, and Slack/webhook alert delivery.
Tags: #devops #security #compliance #soc2 #hipaa #iso27001 #monitoring