In short: A list of IT emergency contacts names, for each role, a person with a deputy, how to reach them outside business hours, the occasion on which they are informed, and the details to have ready when calling. It exists as a printout and on a separate device, is tested regularly and also includes authorities with notification deadlines. That way no time is lost searching in an emergency.
The number nobody has
A Friday evening, the shop shows strange redirects, the admin has a suspicion. What now? Call the host, but which number applies outside business hours, and which customer number is needed? The agency, but who there has access to the server? The insurer, but where is the policy number? And who decides whether the shop goes offline?
Many companies know such moments, and the PHP2Shell week multiplied them. Ideally an emergency plan exists, but the contact list within it is often the weakest link: outdated, incomplete or stored only digitally on exactly the system that is unavailable at that moment. How the plan as a whole is structured is described in Creating an IT emergency plan for web servers. This page is about the list itself.
Who belongs on the list of emergency contacts?
The following table arranges the typical contacts by the occasion on which they are informed and states what to have ready for the first contact.
| Contact | When to inform | What to have ready |
|---|---|---|
| Emergency lead (often management) | on any suspicion of an incident | brief situation, first assessment |
| IT managers and admins | immediately, for technical review | affected systems according to the inventory |
| Host (emergency channel) | on suspicion on the server, for shutdown or logs | customer number, contract number, support password |
| Agency or developer | if the application is affected | project name, access, contact person |
| IT security provider | on a confirmed or probable intrusion | observations so far, times |
| Data protection officer | as soon as personal data might be affected | types of data, period, systems |
| Cyber insurer | according to the policy terms, usually early | policy number, claims reporting route |
| Legal counsel | for notification duties, extortion, liability questions | facts of the case, steps taken so far |
| Data protection supervisory authority | for a reportable data breach, if possible within 72 hours | details under Art. 33(3) GDPR |
| Central cybercrime contact point (ZAC, German police) | when filing a criminal complaint | evidence, timeline |
| BSI | where there is a notification duty under NIS2 | as specified by the BSI |
| Communications | before any external information | agreed facts |
You can find the competent central cybercrime contact point (ZAC) through the police of your German federal state; how filing a complaint works is explained under Filing a complaint: central cybercrime contact points. The deadlines and obligations that insurers typically set are described in Cyber insurance: what counts in a claim.
What every entry must contain
A name and a phone number are not enough. A complete entry answers six questions:
- Role: What is the person responsible for, what may they decide?
- Name and deputy: Who steps in if the first person cannot be reached?
- Reachability: Phone, including mobile, and a second route. Does the number also apply at night and at weekends?
- Trigger: On which event is this person informed?
- Authentication: Customer number, contract number, support password, so that the call does not fail at the identity check.
- Status: When was the entry last checked?
Point 5 in particular is often underestimated. Hosts and registrars check by phone whether the caller is authorised, and rightly so. Anyone who first has to look for the customer password loses valuable time. Store such details securely, but in a way that the emergency lead can access them in an emergency.
Take service providers' phone numbers from the contract or the official website, never from an email. Fraudsters like to exploit known security situations for fake messages with “emergency numbers”.
The order in an emergency
Not all contacts are needed at the same time. A staged approach has proven its worth: first the emergency lead and technical staff, so that a first assessment emerges and a decision on containment can be made. Then the host, agency and security provider for the technical work. As soon as personal data might be affected, the data protection officer, because from the moment a data breach becomes known, the deadline under Art. 33 GDPR is running. Insurer and legal counsel follow early, before important decisions are made. External communication comes last and only with agreed facts.
The steps that follow the first alert are summarised in the checklist after a hack. This page gives general guidance; notification duties and legal questions are to be clarified with the data protection officer and a lawyer.
Also plan a second communication route. If the mail server is affected or there is a suspicion that an attacker is reading internal mailboxes, coordination should run over a separate channel, for example by phone or via a group set up beforehand on another service. Define this channel in advance and include it on the list. Looking for a new route in an emergency costs time and creates uncertainty about which message is genuine.
Keeping the list alive
Contact lists go stale quietly. Staff change, service providers alter their emergency numbers, contracts expire. Therefore schedule two fixed review dates a year and an ad hoc review at every change. A short test call outside business hours shows most reliably whether an emergency channel really works. Also ask whether the person knows they are on the list and what is expected of them in an emergency.
How does PHP SOS help?
- Together with you, we create the list of technical emergency contacts and check whether hosts and agencies actually have an emergency channel.
- We define which details must be ready for each contact so that a call has an immediate effect.
- We accompany a test run of the alerting and work the gaps into your documents.
- In an emergency, we are on your list as the technical contact through incident response.
Conclusion: A good contact list is short, complete and tested. It decides whether the first hours of an incident are spent acting or searching.
Frequently asked questions
Who belongs on a list of IT emergency contacts?
Internally management, IT, the data protection officer and communications; externally the host, agency, IT security provider, cyber insurer, legal counsel, the competent data protection supervisory authority and the central cybercrime contact point (ZAC) of the German federal state concerned, and, where NIS2 obligations apply, the BSI (German Federal Office for Information Security) as well.
Where do I keep the emergency contacts?
In at least two places, one of which is reachable without your own IT, for example printed in the emergency folder and on a separate device. A list that exists only in the mailbox or on the affected server is not available in an emergency.
How often should the list be checked?
At least twice a year and after every change of staff or service provider. A short test call shows whether numbers are correct and whether the people know they are on the list.
Must the data protection supervisory authority always be informed?
Not for every incident. Art. 33 GDPR requires a notification in the case of a personal data breach, if possible within 72 hours, unless it is unlikely to result in a risk to the data subjects. You make the assessment together with the data protection officer; this page is not legal advice.