ITSM processes & support interfaces

Once your application is live, support runs through shared processes: one ticket system, defined update rhythms, a fixed escalation ladder and structured change management.

One ticket system for everything

All incidents and requests are recorded in GovTech's ticket system. It is the single point of contact for Bedarfsträger (public-sector customers), and you are addressable in it. There is no separate vendor-side ticketing channel toward customers.

• The initial severity classification is made by GovTech, against the criteria of the severity model.
• Reclassification is only permitted with a justification recorded in the ticket.

During an incident

Your obligations, in order:

1. Accept the incident within the response time of your SLA profile
2. Provide an initial diagnosis
3. Develop a workaround or mitigation
4. Deliver a permanent fix
5. For S1/S2: run an incident review with root cause analysis within the profile deadline

Status updates until stabilised:

Severity	Update frequency
S1	at least every 60 minutes for the first two hours, then at least every 2 hours
S2	at least every 4 hours

Escalation ladder

Escalation is automatic and time-based:

Trigger	Escalates to
S1 unresolved > 60 min	Your team lead and GovTech operations management
S1 unresolved > 4 h	Management level of both parties
S2 unresolved > 4 h	Your team lead

The escalation roles are named with role and reachability.

Change management

Every change to your application in operation is classified and documented:

Class	Description	Typical examples
Standard change	Pre-approved, low-risk, routine	Routine patches, template-based configuration changes
Normal change	Planned, with risk analysis and approval	Feature releases, larger updates
Emergency change	Unplanned immediate action	Hotfixes during S1 incidents or security situations

Every change carries, at minimum: a risk analysis, a rollback plan, test evidence, a communication plan and a schedule.

Emergency changes are permitted during S1 incidents or security-relevant situations and are documented and reviewed afterwards.

---

Guidance, not contract

General guidance. The binding requirements are in the contract documents of your procedure, which may contain further or more specific requirements.