What this page is
A reading aid, not audit or legal advice. Your auditor decides which controls meet a criterion and what evidence is enough. The criteria below are quoted from the AICPA's 2017 Trust Services Criteria (March 2020 printing); the 2022 revision revised the points of focus, not these criterion statements.
Criterion by criterion
- A1.1: “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.”
The server agent in RealUptime Monitor records CPU, memory, load and disk per host with thresholds that alert, and every HTTP check records response time per region. - A1.2: “The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives.”
A heartbeat monitor on each backup job alerts when a backup does not finish: recipes for restic, Borg and borgmatic, Backrest and Proxmox. Uptime checks on a standby or recovery endpoint show it answering. - CC2.3: “The entity communicates with external parties regarding matters affecting the functioning of internal control.”
Its points of focus in the 2017 edition include processes “to communicate relevant and timely information to external parties”, customers among them. A RealUptime Status page publishes incidents and maintenance and emails them to subscribers, with every update timestamped. - CC7.2: “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.”
Uptime, heartbeat and server checks from Monitor, and application exceptions in RealUptime Errors, each with alert rules and an on-call escalation path. - CC7.4: “The entity responds to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate.”
Escalation policies and on-call rotations (Pro and Business) define who is paged and when; the incident timeline records when it opened, every update and when it resolved. - CC9.2: “The entity assesses and manages risks associated with vendors and business partners.”
Its points of focus in the 2017 edition include assessing “the risks that vendors and business partners (and those entities’ vendors and business partners) represent” and periodically assessing their performance. Vendor dependency alerts tell you when a vendor reports an incident, and RealUptime Outages keeps a public record of each vendor's incidents to review against.
Getting the records out
- Monthly SLA reports per monitor, as CSV, on Pro and Business: uptime for the period, from our own checks.
- Every incident with its full update timeline:
GET /api/v1/incidents/export?format=json, or CSV for one row per incident. - The account audit log, exportable as a file, for who changed monitors, status pages, on-call and alert rules.
What RealUptime does not do
It does not write your controls, decide what your auditor accepts, or make you compliant. RealUptime itself does not hold a SOC 2 report today; the trust page says where it stands, and a vendor review of RealUptime should start there. The NIS2 guide covers the EU rules on telling customers about incidents, and links on to DORA.