Service levels & support
Operating on the platform means carrying a service level agreement. Two standardised profiles exist. The Leistungsbeschreibung (Anlage 1) of your procedure determines which profile applies to your application, and whether individual parameters (availability, RTO or RPO in particular) are agreed differently.
The two profiles at a glance
| Standard | KRITIS | |
|---|---|---|
| Availability per calendar month¹ | 99.9 % | 99.99 % |
| Support coverage | 10×5, Mon–Fri 08:00–18:00 CET | 24/7/365 by ticket and telephone |
| Planned maintenance windows | ≤ 4 h/month, announced ≥ 5 working days ahead | ≤ 2 h/month, announced ≥ 10 working days ahead and coordinated with GovTech |
| Typical RTO | 8–24 hours | 1–4 hours |
| Typical RPO | 1–4 hours | 5–30 minutes |
| Root cause analysis (S1/S2) | within 10 working days | within 5 working days |
¹ Excluding planned maintenance windows.
The KRITIS profile applies when the Leistungsbeschreibung says so for your Fachanwendungsbereich, and only if your architecture, backup and failover design can actually sustain it.
Availability figures account for GovTech's own obligations, above all running the platform. Where availability suffers because of a malfunction on GovTech's side, that is not held against you.
Severity model
Every incident is classified S1–S4. The initial classification is made by GovTech; reclassification is only permitted with a justification recorded in the ticket. A security incident is always S1.
| Severity | Definition | Examples |
|---|---|---|
| S1 | Total failure of the application, failure for several sites/tenants, or an incident with immediate functional or data-protection relevance | Login impossible; suspected data leak |
| S2 | A core function severely impaired for many users or a whole site/tenant, without total failure | High error rate; performance collapse |
| S3 | A secondary function or individual users affected; a workaround exists | Partial function disrupted |
| S4 | Cosmetic or purely informational, no operational impact | Cosmetic issue; service request |
Response times per profile
What you commit to per severity:
Standard profile
| Severity | Response | Mitigation / workaround | Recovery / fix |
|---|---|---|---|
| S1 | ≤ 60 min | ≤ 4 h | ≤ 24 h |
| S2 | ≤ 4 h | ≤ 1 working day | ≤ 3 working days |
| S3 | ≤ 1 working day | — | ≤ 10 working days |
| S4 | ≤ 3 working days | — | next release |
KRITIS profile
| Severity | Response | Mitigation / workaround | Recovery / fix |
|---|---|---|---|
| S1 | ≤ 15 min | ≤ 2 h | ≤ 6 h |
| S2 | ≤ 60 min | ≤ 8 h | ≤ 24 h |
| S3 | ≤ 4 h | — | ≤ 5 working days |
| S4 | ≤ 3 working days | — | next release |
RTO and RPO
The concrete RTO (recovery time objective) and RPO (recovery point objective) values for your application are fixed in your contract. The typical target corridors:
- Standard: RTO 8–24 hours · RPO 1–4 hours
- KRITIS: RTO 1–4 hours · RPO 5–30 minutes
You demonstrate the technical feasibility of your RTO/RPO values during the integration test. The demonstrated values are then contractually fixed; a blanket, after-the-fact appeal to architectural constraints is excluded.
Monthly service reports
Once in operation, you deliver a monthly service report covering at minimum:
- Availability (actual vs. target)
- Incidents (count, by severity)
- MTTR (mean time to repair)
- Releases in the reporting period
- Security findings
For every S1 and S2 incident, a root cause analysis follows within the profile deadline (10 working days Standard, 5 working days KRITIS).
Service credits
Missing the response, mitigation, recovery or patch deadlines triggers a service credit model; the concrete credit rates and thresholds are set in the contract documents. Repeated or serious breaches, particularly around S1/S2 incidents and critical or high vulnerabilities, can escalate further, up to extraordinary termination rights.
General guidance. The binding requirements, including all figures on this page, are in the contract documents of your procedure, which may contain further or more specific requirements.