Security Robot SLA Response: Contractual Obligations

A service level agreement for security robots is not a marketing document. It is the only defensible basis on which a security director can hold position before the board, insurers, and regulators in the event of an incident. Signing a contract that specifies "fast response" and "high availability" leaves nothing actionable. This article supplies the numbers, measurement points, and contract clauses that belong in any operationally viable SLA.

Security Robot SLA Response: What the Contract Must Specify

A negotiation-ready SLA for patrol robots consists of five hard values, each with a defined measurement point.

• Detection time: maximum 8 seconds from sensor trigger to classification in the operational picture. Measured between the raw signal timestamp and the classified event timestamp in the operator dashboard.
• Alarm forwarding to the alarm receiving centre (NSL): maximum 30 seconds from confirmed detection. Measured between classification and ticket receipt at the Notruf- und Serviceleitstelle.
• Escalation to response forces: documented path with names, telephone numbers, and backup contacts. No generic distribution lists. Every entry includes a deputy and a reachability window.
• Patrol unit availability: 98.5 percent per month, measured via telemetry. Scheduled maintenance windows are reported separately and excluded from availability calculations.
• Recovery after failure: replacement unit on-site within 48 hours, software rollback within 4 hours.

These five values belong in the main contract, not in an annex that can be amended later. Operators booking the Robotics-as-a-Service model purchase exactly these commitments, not the hardware.

Why Standard Wachschutz SLAs Are Insufficient

Classic Wachschutz SLAs measure response drive time. The patrol car arrives at the gate in 15 minutes, the Posten handover takes 90 seconds, the report lands the following morning. That logic works for human escalation. It does not work for sensor-based detection.

Robotics shifts latency from people to sensors. The critical question is no longer "How quickly does the Wachmann reach the scene" but "How quickly does the system detect an event and hand it to a verified operator." That requires different measurement points: sensor timestamps, classification duration, verification time windows.

False alarm rate belongs in the SLA. In most proposals it appears only in the brochure. A robot generating 12 false alarms per night with an excellent MTTD statistic is operationally worthless: the NSL becomes desensitised and genuine incidents are lost in the noise.

BDSW industry data identifies personnel costs as the dominant cost factor in the Wach- und Sicherheitsdienst sector. Response quality is not captured in traditional calculations because it was difficult to measure. With RaaS that changes: sensor uptime and data integrity must be governed separately from pure personnel availability. Combining the two produces summary reports with no analytical value. The full cost framework is available in the TCO comparison Wachschutz.

KPIs Every Security Director Anchors in the SLA

5 KPIs are operationally relevant. Everything else is secondary.

1. MTTD (Mean Time To Detect): target below 10 seconds for person detection at the perimeter. Below 6 seconds for vehicles, below 30 seconds for stationary objects.
2. MTTA (Mean Time To Acknowledge): below 60 seconds to NSL confirmation. This is the interval between alarm receipt and qualified human verification.
3. MTTR (Mean Time To Recover): device replacement within 48 hours, software rollback within 4 hours. These two values must be reported separately because they have different triggers.
4. False positive rate: documented quarterly. Threshold fixed contractually, for example fewer than 5 false alarms per 1,000 patrol hours for perimeter deployment.
5. Patrol coverage: percentage of planned waypoints completed per 24-hour cycle. A realistic target is 95 percent, measured via GPS and localisation telemetry.

The separation between availability SLA and response SLA is essential. A robot can be technically available (battery full, sensors green) and still fail operationally (classification incorrect, escalation not triggered). In practice these two dimensions are routinely conflated. The contract must govern them separately and attach distinct penalties to each.

Escalation Chains: From Sensor to Head of Werkschutz

A contract-ready escalation chain has four levels, each with its own timestamp and tamper-proof logging.

• Level 1: automatic classification and live image forwarded to the control room. Trigger: sensor event plus minimum classification confidence (typically 0.75).
• Level 2: human verification at the NSL within 30 seconds. The operator confirms or dismisses. Dismissals are logged regardless.
• Level 3: call to the duty Werkschutz officer or police according to the escalation matrix. The matrix defines the addressee and time window per event type.
• Level 4: written incident documentation within 4 hours of the event. Format: machine-readable, exportable, compatible with internal compliance systems.

Every level is recorded with a timestamp and stored in tamper-proof form. On QR-2 for 24/7 outdoor perimeters, Level 1 classification runs directly on the device; Levels 2 to 4 run in the NSL. On QR-3 with LiDAR and drone detection, an additional sensor layer is introduced that must be prioritised separately within the escalation matrix.

The most common gap in existing contracts: Level 3 is stored as a telephone list with no deputy rule and no escalation path when the primary contact is unreachable. A contract that provides no backup contact for a 03:47 call will not hold up in court.

SLA Requirements Under NIS-2 and the KRITIS-Dachgesetz

The NIS-2 Directive requires initial notification of security-relevant incidents within 24 hours. Security robots in this context are a technical measure under Article 21 and must demonstrably support the notification chain. Concretely: the SLA must produce logs from which detection time, verification time, and escalation time can be read unambiguously. The format must feed directly into internal notification processes.

The KRITIS-Dachgesetz requires operators to document physical and organisational protective measures. Effectiveness must be demonstrated. An SLA that delivers only status messages ("system running") does not satisfy this requirement. Audit-capable logs are required: event ID, timestamp, classification, escalation path, final assessment.

The KritisV governs the obligations of KRITIS operators including documentation requirements. Without structured data from the robotics system, no audit-ready documentation is possible. Board liability attaches when an SLA breach leads to an incident that is not reported or is reported late. The legal mechanics are set out in detail in Board liability under NIS-2. An overview of the full requirements is available in the NIS-2 compliance overview.

EN ISO 13482, which defines safety requirements for personal care robots, serves as a technical reference for mobile service robotics. It does not apply directly but provides the argumentative framework for risk assessments.

Penalties and Service Credits: Market Standards

Without penalties an SLA is a declaration of intent. Market-standard practice uses tiered service credits tied to monthly availability.

• 10 percent service credit on the monthly fee when availability falls below 98 percent.
• 25 percent credit when availability falls below 95 percent in a given month.
• Extraordinary termination right after three consecutive months with SLA breach.
• Liquidated damages for failed escalation: to be defined contractually; typical range €5,000–25,000 per event, depending on site risk profile.
• No penalty without clear measurement methodology and reporting accessible to both parties.

The penalty level must match the damage risk of the site. A flat 10 percent clause at a KRITIS site with potential eight-figure losses is symbolic. Conversely, six-figure contractual penalties for a logistics yard are disproportionate and will not be enforced in a dispute.

Penalties require a trigger. The trigger is the documented deviation in the monthly SLA report, not a subjective assessment by the security director.

Measurement: How SLA Compliance Is Actually Demonstrated

An SLA is only as good as its measurement methodology. Telemetry from the robot supplies sensor timestamps; the NSL supplies processing timestamps. Both data sources must be NTP-synchronised to millisecond precision and fed into a shared reporting system.

• Monthly SLA report covering all incidents, response times, and deviations. Format must be structured, not PDF-only.
• Third-party audit at the client's request, at minimum once per year. The auditor is nominated by the client; costs are split or borne by the provider according to the contract.
• Data export in open formats (JSON, CSV). No proprietary black-box reports.
• Client dashboard with real-time KPIs and historical trend analysis. Read access for at least three named persons per site.

Quarero provides this dashboard as standard. It displays MTTD, MTTA, MTTR, false positive rate, and patrol coverage to day-level granularity with full historical records. An operator who cannot pull their own figures from the system before a monthly KPI meeting has chosen the wrong provider.

Contract Negotiation: The Most Common Mistakes

5 mistakes recur across RaaS contract negotiations.

1. SLA without measurement point. "Fast response," "high availability," and "industry-standard quality" are not contractual commitments. Every value requires a definition, a measurement point, and a measurement interval.
2. Penalty level without reference to the site's damage risk. A risk analysis before contract signature determines a sensible penalty level. The provider's standard contract does not.
3. No rule for scheduled maintenance windows. Maintenance must be announced, time-limited, and reported separately. Without this, quarterly "planned maintenance" erodes the 98.5 percent commitment.
4. No definition of escalation authority during failure. If the robot goes offline and the NSL has no site access: who takes over? Which Wachdienst stands in? This handover rule must be fixed in writing.
5. Force majeure not clearly bounded. An overly broad force majeure clause nullifies every SLA claim. Strikes, supply shortages, and cyberattacks are not force majeure in the strict sense. The clause must be narrowly defined.

A sixth, less frequently addressed point: the reporting format must be specified in the contract. Accepting that the provider reports "in an appropriate form" will produce a PDF that cannot be processed by any automated system.

Next Step

An operationally viable SLA does not come from a standard contract. It comes from a site-specific risk analysis and negotiation over the metrics set out here. The move from classic Wachschutz to sensor-supported patrol operations means negotiating not over hourly rates but over response times, availability, and log quality.

Complete contract clauses, KPI definitions, and a sample report are part of the Robotics-as-a-Service model. Operators who want to calculate the values for a specific site can submit a pilot enquiry.