# Vészhelyzeti kapcsolattartók: kit kell mikor értesíteni?

> IT-vészhelyzeti kapcsolattartók: kik kerüljenek a listára, kit mikor kell értesíteni, mely adatok kellenek kéznél, és hogyan marad naprakész a lista.

Forrás: https://phpsos.de/hu/blog/notfallkontakte-liste/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Az IT-vészhelyzeti kapcsolattartók listája minden szerepkörhöz megnevez egy személyt helyettesítéssel, az üzemidőn kívüli elérhetőséget, azt az okot, amely miatt értesítik, és azokat az adatokat, amelyeknek híváskor kéznél kell lenniük. Kinyomtatva és egy különálló eszközön is rendelkezésre áll, rendszeresen tesztelik, és bejelentési határidővel rendelkező hatóságokat is tartalmaz. Így éles helyzetben nem vész el idő a keresgélésben.

## A szám, amely senkinél sincs

Egy péntek este, a webshop furcsa átirányításokat mutat, a rendszergazdának gyanúja van. Mi most a teendő? Felhívni a tárhelyszolgáltatót, de melyik szám érvényes az üzemidőn kívül, és milyen ügyfélszám kell? Az ügynökséget, de ki fér ott hozzá a szerverhez? A biztosítót, de hol van a kötvényszám? És ki dönti el, hogy a webshop lekerül-e a hálózatról?

Sok vállalkozás ismeri az ilyen pillanatokat, és a PHP2Shell hete megsokszorozta őket. A vészhelyzeti terv ideális esetben megvan, de a benne lévő kapcsolattartói lista gyakran a leggyengébb láncszem: elavult, hiányos, vagy csak digitálisan, éppen azon a rendszeren van tárolva, amely most nem elérhető. Hogyan épül fel a terv egésze, azt az [IT-vészhelyzeti terv készítése webszerverekhez](https://phpsos.de/hu/compliance/notfallplan-erstellen/) írja le. Itt magáról a listáról van szó.

## Kik kerüljenek a vészhelyzeti kapcsolattartók listájára?

A következő táblázat a tipikus kapcsolattartókat az értesítésük oka szerint rendezi, és megnevezi, mit érdemes kéznél tartani az első kapcsolatfelvételkor.

| Kapcsolattartó | Mikor értesítse | Mit tartson kéznél |
|---|---|---|
| Vészhelyzeti vezetés (gyakran a cégvezetés) | az incidens minden gyanújánál | rövid helyzetkép, első értékelés |
| IT-felelősök és rendszergazdák | azonnal, műszaki ellenőrzésre | az érintett rendszerek a leltár szerint |
| Tárhelyszolgáltató (vészhelyzeti csatorna) | a szerveren fennálló gyanú esetén, leállításhoz vagy naplókhoz | ügyfélszám, szerződésszám, jelszó a supporthoz |
| Ügynökség vagy fejlesztő | ha az alkalmazás érintett | projektnév, hozzáférések, kapcsolattartó |
| IT-biztonsági szolgáltató | megerősített vagy valószínű behatolás esetén | eddigi megfigyelések, időpontok |
| Adatvédelmi tisztviselő | amint személyes adatok érintettek lehetnek | az adatok fajtái, időszak, rendszerek |
| Kiberbiztosítás | a kötvény előírásai szerint, többnyire korán | kötvényszám, kárbejelentési út |
| Jogi tanácsadás | bejelentési kötelezettségek, zsarolás, felelősségi kérdések esetén | a tényállás, az eddigi lépések |
| Adatvédelmi felügyeleti hatóság | bejelentésköteles adatvédelmi incidensnél, lehetőleg 72 órán belül | a GDPR 33. cikk (3) bekezdése szerinti adatok |
| Kiberbűnözési központi kapcsolattartó pont (ZAC) | bűncselekmény feljelentésekor | bizonyítékok, idővonal |
| BSI | NIS2 szerinti bejelentési kötelezettség esetén | a BSI előírásai szerint |
| Kommunikáció | minden külső tájékoztatás előtt | egyeztetett tények |

Az illetékes ZAC-ot (Zentrale Ansprechstelle Cybercrime, a kiberbűnözés központi kapcsolattartó pontja) a német szövetségi tartomány rendőrségén keresztül találhatja meg; hogyan zajlik a feljelentés, azt a [Feljelentés: a kiberbűnözés központi kapcsolattartó pontjai](https://phpsos.de/hu/compliance/anzeige-polizei-zac/) tartalmazza. Hogy a biztosítók tipikusan milyen határidőket és kötelezettségeket írnak elő, azt a [Kiberbiztosítás: mi számít kár esetén](https://phpsos.de/hu/compliance/cyberversicherung/) írja le.

## Mit kell tartalmaznia minden bejegyzésnek

Egy név és egy telefonszám nem elég. Egy teljes bejegyzés hat kérdésre válaszol:

1. **Szerepkör:** Miért felelős a személy, miről dönthet?
2. **Név és helyettesítés:** Ki ugrik be, ha az első személy nem érhető el?
3. **Elérhetőség:** Telefon, mobilon is, és egy második út. Érvényes-e a szám éjjel és hétvégén is?
4. **Kiváltó ok:** Melyik esemény esetén értesítik ezt a személyt?
5. **Igazolás:** Ügyfélszám, szerződésszám, supportjelszó, hogy a hívás ne az azonosításon hiúsuljon meg.
6. **Állapot:** Mikor ellenőrizték utoljára a bejegyzést?

Az 5. pontot különösen gyakran alulértékelik. A tárhelyszolgáltatók és regisztrátorok telefonon ellenőrzik, jogosult-e a hívó, és ezt joggal teszik. Aki előbb az ügyfél-jelszót keresi, értékes időt veszít. Őrizze az ilyen adatokat biztonságosan, de úgy, hogy a vészhelyzeti vezetés éles helyzetben hozzáférjen.

> **Tipp:**
> A szolgáltatók telefonszámait a szerződésből vagy a hivatalos weboldalról vegye át, soha ne egy e-mailből. A csalók szívesen használják fel az ismert biztonsági helyzeteket „vészhelyzeti számokat” tartalmazó hamis üzenetekhez.

## A sorrend éles helyzetben

Nem mindenkire van egyszerre szükség. Lépcsőzetes eljárás vált be: először a vészhelyzeti vezetés és a műszaki csapat, hogy első értékelés szülessen, és dönteni lehessen a megfékezésről. Ezután a tárhelyszolgáltató, az ügynökség és a biztonsági szolgáltató a műszaki munkához. Amint személyes adatok érintettek lehetnek, az adatvédelmi tisztviselő, mert az adatvédelmi incidens tudomásra jutásától számítva fut a GDPR 33. cikke szerinti határidő. A biztosító és a jogi tanácsadás korán következik, mielőtt fontos döntések születnek. A külső kommunikáció a legvégén jön, és csak egyeztetett tényekkel.

Hogy az első riasztás után mely lépések következnek, azt a [Ellenőrzőlista egy feltörés után](https://phpsos.de/hu/ratgeber/checkliste-nach-dem-hack/) foglalja össze. Ez az oldal általános útmutatást ad; a bejelentési kötelezettségeket és a jogi kérdéseket az adatvédelmi tisztviselővel és az ügyvéddel tisztázza.

Tervezzen emellett be egy második kommunikációs utat. Ha a levelezőszerver érintett, vagy fennáll a gyanú, hogy egy támadó belső postafiókokat olvas, az egyeztetésnek külön csatornán kell folynia, például telefonon vagy egy előre létrehozott csoporton keresztül egy másik szolgáltatásban. Ezt a csatornát előre rögzítse, és vegye fel a listára. Éles helyzetben új utat keresni időt vesz el, és bizonytalanságot okoz abban, melyik üzenet valódi.

## A lista élő állapotban tartása

A kapcsolattartói listák észrevétlenül elavulnak. A munkatársak váltanak, a szolgáltatók módosítják a vészhelyzeti számokat, a szerződések lejárnak. Tervezzen ezért évente két rögzített ellenőrzési időpontot, és minden váltásnál egy alkalmi időpontot. Egy rövid próbahívás az üzemidőn kívül a legmegbízhatóbban megmutatja, hogy egy vészhelyzeti csatorna valóban működik-e. Kérdezze meg közben azt is, hogy a személy tudja-e, hogy rajta van a listán, és mit várnak tőle éles helyzetben.

## Hogyan segít konkrétan a PHP SOS?

- Önnel együtt elkészítjük a műszaki vészhelyzeti kapcsolattartók listáját, és megvizsgáljuk, hogy a tárhelyszolgáltatóknak és az ügynökségeknek ténylegesen van-e vészhelyzeti csatornájuk.
- Rögzítjük, mely adatoknak kell kéznél lenniük az egyes kapcsolattartókhoz, hogy egy hívás azonnal hatásos legyen.
- Kísérjük a riasztás próbafuttatását, és a hiányosságokat beépítjük az Ön dokumentumaiba.
- Éles helyzetben műszaki kapcsolattartóként az [incidenskezelés](https://phpsos.de/hu/leistungen/incident-response/) keretében szerepelünk az Ön listáján.

**Összegzés:** Egy jó kapcsolattartói lista rövid, teljes és tesztelt. Ez dönti el, hogy egy incidens első órái cselekvéssel vagy keresgéléssel telnek-e.


## Gyakori kérdések

**Kik kerüljenek az IT-vészhelyzeti kapcsolattartók listájára?**  
Belül a vezetés, az IT, az adatvédelmi tisztviselő és a kommunikáció, kívül a tárhelyszolgáltató, az ügynökség, az IT-biztonsági szolgáltató, a kiberbiztosítás, a jogi tanácsadás, az illetékes adatvédelmi felügyeleti hatóság és a szövetségi tartománya kiberbűnözési központi kapcsolattartó pontja (Zentrale Ansprechstelle Cybercrime), NIS2-kötelezettség esetén ezenkívül a BSI.

**Hol őrizzem a vészhelyzeti kapcsolattartókat?**  
Legalább két helyen, amelyek közül az egyik a saját IT nélkül is elérhető, például kinyomtatva a vészhelyzeti mappában és egy különálló eszközön. Az a lista, amely csak a levelezőpostafiókban vagy az érintett szerveren van, vészhelyzetben nem áll rendelkezésre.

**Milyen gyakran kell ellenőrizni a listát?**  
Évente legalább kétszer, valamint minden személyzeti vagy szolgáltatóváltás után. Egy rövid próbahívás megmutatja, hogy a számok helyesek-e, és hogy az érintettek tudják-e, hogy rajta vannak a listán.

**Az adatvédelmi felügyeleti hatóságot mindig értesíteni kell?**  
Nem minden incidensnél. A GDPR 33. cikke személyes adatok védelmének megsértése esetén bejelentést ír elő, lehetőleg 72 órán belül, kivéve, ha az valószínűleg nem jár kockázattal az érintettekre nézve. Az értékelést az adatvédelmi tisztviselővel végezze el; ez az oldal nem jogi tanácsadás.

## Források

- [GDPR 33. cikk](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Rendőrség: a ZAC-ok áttekintése](https://www.polizei.de/)
- [BSI](https://www.bsi.bund.de/)