What an Auditor Asks That Your SLA Report Cannot Answer

An auditor rarely argues with your uptime percentage. They ask where it came from. Most SLA reports answer the first question and not the second.

The number at the top of an SLA report is a claim: 99.95 percent, this quarter, on the record. An auditor, a customer’s procurement team, or a regulator working through DORA or NIS2 obligations does not usually challenge the number itself. They ask a harder question. How do you know?

That question is not pedantry. DORA has applied since January 17, 2025, with reporting deadlines of four hours, 72 hours, and one month for major incidents. NIS2 is pulling well over a hundred thousand companies across the EU into reporting duties, an estimated 30,000 to 40,000 in Germany alone, and only about 39 percent of those had registered by the March 2026 deadline (German transposition figures, BSI, 2026). The people asking for your availability evidence in 2026 are working against those frameworks, and they are trained to test a claim rather than accept it. Three gaps show up again and again. Here is how to find them in your own report before someone else does.

The question behind the number

Availability is an awkward thing to measure honestly, because the system being measured is often the system doing the measuring, and the report is frequently assembled after the fact from memory, Slack threads, and CSV exports. So an auditor works backward from the percentage: which windows counted as downtime, which were excluded and why, and who recorded the timestamps. A report that cannot answer those three cleanly does not get marked wrong. It gets marked unreliable, which is worse, because now every other number on the page is in doubt.

Gap one: rounded windows

Many reports tidy outages into round numbers. A window becomes “about 15 minutes,” or anything under 10 minutes is dropped as noise. It reads cleanly and it cannot be reconstructed, which is the problem. An auditor cannot recompute a percentage from a window that has been smoothed.

The stakes are arithmetic. A 99.95 percent target over a 91-day quarter leaves about 65 minutes of downtime budget across 131,040 minutes. A single window rounded the wrong way can hide a real breach or invent one. If a 7-minute, 12-second incident is logged as “roughly 15 minutes,” you have overstated your own downtime by almost eight minutes for no reason; round it down to zero and you have quietly erased evidence a regulator may later reconcile against a customer complaint.

How to close it. Record the real boundaries, to the second, and let the percentage fall out of them. The window is the window. It is not prettier at 15 minutes, and it is not defensible.

Gap two: silent exclusions

Every serious SLA calculation excludes something: announced maintenance, force-majeure windows, a dependency outside your control. Exclusions are legitimate. Silent exclusions are not.

The tell an auditor looks for is an exclusion that cannot be tied to an announcement made before the window opened. A maintenance window pulled out of the math with no record of when it was announced is indistinguishable from retroactive editing, and once one exclusion looks retroactive, all of them do. That is how a good uptime number turns into a credibility problem.

How to close it. Every exclusion carries its own announcement timestamp and its real start and end. Excluded time is shown on the report, labeled as excluded, not deleted from it. The reader should be able to see the maintenance window, see when it was announced, and agree that leaving it out was decided in advance rather than after the outcome was known.

Gap three: self-reported measurement

The third gap is the one teams least expect, because it is not about the math. It is about the vantage point. If your availability data comes from a single probe, or worse from the same infrastructure that failed, an auditor has a fair objection: you cannot tell your own network problem apart from a real service outage, and a person assembling the timeline afterward cannot prove the timestamps were not adjusted to fit.

How to close it. Measure from outside the monitored system, and confirm across independent locations before counting an incident. When probes on more than one continent agree that a service is unreachable, “was it us or them” has an answer that does not depend on goodwill. Let the monitoring system stamp each event as it happens rather than reconstructing the sequence later. The difference an auditor cares about is not sophistication. It is that the record was written by a machine at the time, not by a person after the fact. This is also why the measurement methodology, not just the result, belongs in a document you can share.

What a report that holds up looks like

Three properties, and they are unglamorous: real window boundaries, exclusions that are visible and pre-announced, and measurement taken from outside the system and confirmed across regions. None of this makes your uptime higher. It makes your uptime checkable, which is the only version an auditor will sign off on. A flattering number you cannot defend is worth less than an honest one you can.

An artifact, not a screenshot

This is easier to see than to describe, so we publish a full one. The sample SLA report records a single quarter for a demo service, and every number in it adds up.

Read one line closely. A check fails in Frankfurt at 02:40:42. The incident does not open there. Thirty seconds later, probes in New Jersey and Singapore agree the service is unreachable, quorum confirms, and the incident opens at 02:41:12. That confirmation is the start of the counted window, 02:41:12 to 02:48:24, not the first failed check and not a rounded minute. The 90-minute maintenance window later that month is excluded, but it stays on the report with the timestamp of its announcement, so an auditor can see it was planned rather than explained away. Gross availability is 99.925 percent; after the one curated exclusion it is 99.994 percent. Hand it to a customer, an auditor, or a regulator, and they can recompute every step.

To be clear about scope: a monitoring product does not make anyone DORA or NIS2 compliant. Classification, filing, and the deadlines stay your responsibility. What a tool can do is produce the availability evidence those frameworks keep asking for, in a form that survives a second reader.

If your current report cannot answer the three questions above, that is worth knowing now, while the only cost is a slightly less flattering number. You can start monitoring free or walk through the product first. No sales call to see how the record is kept.