# Отговорност на ръководството при пропуски в ИТ сигурността

> Отговорност на управителя при пропуски в ИТ сигурността, обяснена общо: задължения за грижа, NIS2 и как да документирате решенията си по чист начин.

Източник: https://phpsos.de/bg/compliance/geschaeftsfuehrer-haftung/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** ИТ сигурността е сред задачите на ръководството. За отговорност на управителя при пропуски в ИТ сигурността се говори най-вече когато известни рискове не са третирани адекватно, отговорностите не са уредени или решенията не са взети проследимо. При ситуации като PHP2Shell помага ясно, документирано решение въз основа на наличните факти. Тази страница е обща информация и не представлява правен съвет.

> **Важно:**
> Не е правен съвет: въпросите за отговорността зависят силно от конкретния случай, правната форма и договорните уредби. Поискайте конкретните въпроси да бъдат оценени от адвокат по дружествено право.

## Отговорност на управителя и ИТ сигурност: общата рамка

За управителите на GmbH § 43 GmbHG (германски закон за дружествата с ограничена отговорност) изисква грижата на добросъвестен търговец. За членовете на управителния съвет на акционерно дружество § 93 AktG (германски закон за акционерните дружества) съдържа сходно правило; § 91, ал. 2 AktG освен това изисква подходящи мерки за ранно разпознаване на развития, застрашаващи съществуването на дружеството. От тези общи задължения в специализираната дискусия се извежда, че и ИТ рисковете трябва да се управляват адекватно.

За предприемаческите решения съществува свобода на преценката. Който взема решение въз основа на адекватна информация и в интерес на дружеството, по т.нар. Business Judgment Rule по правило действа в съответствие със задълженията си, дори решението по-късно да се окаже неблагоприятно. От това следва практически извод: решаващо често е не толкова резултатът, колкото въпросът дали решението е взето информирано и проследимо.

## Какво добавя NIS2

За фирмите, попадащи под NIS2, отговорността на ръководството е уредена изрично. Ръководството трябва да одобрява мерките за управление на риска, да следи изпълнението им и да се обучава по киберсигурност. В Германия транспонирането става чрез NIS2UmsuCG (германски закон). Дали Вашата фирма е засегната и какви задължения важат в детайл, вижте в данните на BSI (Федерална служба за информационна сигурност на Германия). Общ преглед дава [NIS2 и сигурност на уеб сървърите](https://phpsos.de/bg/compliance/nis2/).

Към това се добавят задължения от защитата на данните. По ОРЗД фирмата трябва да предприема подходящи технически и организационни мерки и да оценява, документира и при нужда да съобщава нарушенията на сигурността на личните данни по чл. 33.

## Какво изисква от ръководството ситуация като PHP2Shell

PHP2Shell обхваща две критични уязвимости в самия PHP (CVE-2026-109618 и CVE-2026-109619, и двете с CVSS v4.0 9,2). BSI обяви ниво на предупреждение 3 (оранжево) и препоръча незабавна актуализация, а ако това не е възможно, уеб сървърите да се изключат временно от мрежата. За ръководството така възниква типично претегляне: оборот и достъпност срещу висок, публично известен риск.

Никой не изисква управителите сами да пачват сървъри. Може да се очаква обаче да вземат ситуацията под внимание, да изяснят отговорностите, да поискат доклад и да вземат решение. Въпроси, които ръководството трябва да си зададе:

- Кои от нашите системи ползват PHP и кой отговаря за тях, вътрешно или при доставчика на услуги?
- Внесени ли са актуализациите и рестартирани ли са процесите и има ли доказателство за това?
- Ако не: защо не, какви временни мерки са в действие и изключваме ли системата от мрежата?
- Има ли данни за проникване и кой преценява евентуалните задължения за уведомяване?

## Документиране на решенията

Запишете накратко писмено обзора на ситуацията, вариантите, решението и обосновката, с дата и час. Такъв протокол не е нужно да е дълъг. Той показва по-късно, че ръководството е било информирано и е претеглило. Това важи изрично и за решението дадена система да продължи да работи ограничено време въпреки риска.

| Съдържание | Пример |
|---|---|
| Обзор на ситуацията | BSI ниво на предупреждение 3, пачове налични от 21.10.2026 г. |
| Засегнати системи | Магазин, клиентски портал, вътрешна инсталация на уики |
| Варианти | пач веднага, временни мерки, изключване от мрежата |
| Решение | Магазинът е пачнат, уикито офлайн до актуализацията |
| Обосновка и отговорни лица | Доказателство от доставчика на услуги, контрол от ръководителя на ИТ |

Пачът не премахва вече внесен зловреден софтуер. Решението дали да се търсят следи също принадлежи в протокола.

## Организирайте трайно вместо да импровизирате при истински случай

Най-добрата превенция е ясна организация: определен отговорник за информационната сигурност, процедура за актуализации на сигурността, редовни доклади до ръководството, тестван [ИТ авариен план](https://phpsos.de/bg/compliance/notfallplan-erstellen/) и независима проверка през разумни интервали. Като методическа рамка е подходящ IT-Grundschutz на BSI.

Към организацията спада и докладите да се оформят така, че ръководството да ги разбира. Често е достатъчен кратък, редовен доклад с малко данни: колко системи са на актуално състояние, къде има изключения и защо, какви инциденти или почти-инциденти е имало, какви решения предстоят. Който получава такива доклади, задава въпроси и фиксира резултатите, може по-късно да покаже, че надзорът действително е бил осъществяван. Това важи независимо дали техниката е вътрешна, или при доставчик на услуги.

## Как помага PHP SOS конкретно?

- Изготвяме разбираем обзор на ситуацията с Вашите уеб сървъри за ръководството, с ясни варианти.
- Изпълняваме избрания вариант и предоставяме писмено техническо доказателство.
- Чрез [одит на сигурността или тест за проникване](https://phpsos.de/bg/leistungen/sicherheitsaudit-penetrationstest/) създаваме независима основа за Вашите решения.
- С [договор за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/) уреждаме трайно актуализациите и докладите.


## Често задавани въпроси

**Отговаря ли управителят лично за хакерска атака?**  
Самата атака не обосновава лична отговорност. За отговорност се говори най-вече когато са нарушени задължения за грижа, например когато известни рискове са пренебрегнати или отговорностите не са уредени. Дали това е така в конкретния случай, преценява само правна консултация.

**Мога ли напълно да прехвърля ИТ сигурността на ИТ отдела или на доставчик на услуги?**  
Задачите могат да се делегират, но отговорността за избора, оборудването и надзора остава при ръководството. Поискайте редовни доклади и записвайте какви решения на какво основание са взети.

**Какво променя NIS2 в отговорността на ръководството?**  
NIS2 изисква от ръководството на засегнатите фирми да одобрява мерките за управление на риска, да следи изпълнението им и да участва в обучения. Подробностите следват от германския закон за транспониране и от данните на BSI.

**Помага ли D&O застраховка?**  
Застраховката за отговорност на членовете на управителни органи може да покрива определени рискове от отговорност на ръководството, но условията се различават силно. Изяснете обхвата с Вашия брокер или застраховател.

## Източници

- [BSI](https://www.bsi.bund.de/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [ОРЗД, чл. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)