# Договори с ИТ доставчици: ясно уреждане на задълженията за сигурност

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

Източник: https://phpsos.de/bg/blog/dienstleistervertrag-sicherheit/  
Актуалност: 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 постави: кой е отговорен?

На 21.10.2026 г. в 16:00 ч. германско време проектът PHP публикува пачовете. BSI (Федералната служба за информационна сигурност на Германия) препоръча незабавна актуализация или, където това не е било възможно, временно изключване на уеб сървърите от мрежата. В много фирми след това не започна работата, а търсенето на отговорност. Агенцията сочеше към хостинг доставчика, хостинг доставчикът към договора, а в договора пишеше „поддръжка по обем на работата“.

Такива пропуски в договорите не са единичен случай. Много договори с агенции и доставчици са сключени, когато е ставало дума за изграждане на уебсайт, а не за сигурната му експлоатация през години. Критична уязвимост в средата за изпълнение на PHP, която не засяга нито CMS, нито кода на приложението, тогава лесно пада между всички столове.

## Какво трябва да урежда договорът с ИТ доставчик за сигурността

Следващият преглед назовава точките, които на практика са се оказали важни. Той не замества юридическа проверка, но помага да се разпознаят пропуски в съществуващия договор.

| Точка за уреждане | Какво трябва да се фиксира | Връзка с PHP2Shell |
|---|---|---|
| Обхват на услугата | Кои слоеве се обслужват: операционна система, среда за изпълнение на PHP, уеб сървър, CMS, добавки, собствен код | Средата за изпълнение на PHP често липсваше в изброяването |
| Срокове за актуализации | степенувани по тежест, с правило за изключения при извънредни случаи | критична уязвимост с CVSS v4.0 9,2 |
| Рестарт и доказателство | Актуализациите се считат за изпълнени едва след рестарт на всички процеси, с писмен документ | нови файлове сами не затварят уязвимостта |
| Информиране | активно известяване при критични уязвимости, с оценка и план | много клиенти трябваше сами да питат |
| Съдействие при инциденти | Подкрепа при анализ, запазване на доказателства, възстановяване, лице за контакт | търсене на следи след пача |
| Журнали | вид, съхранение, предоставяне при поискване | специализираната преса препоръча журналите да се запазят от 20.10. |
| Достъпи | лични акаунти, двуфакторно удостоверяване, списък на всички достъпи | кой всъщност имаше достъп? |
| Подизпълнители | кой още участва, информиране при смяна | хостинг доставчикът на хостинг доставчика |
| Край на жизнения цикъл на софтуера | Указание своевременно преди края на поддръжката, план за миграция | PHP 8.2 приключва на 31.12.2026 г. |
| Напускане | Предаване на данни, документация и достъпи, отнемане на правата | смяна след инцидент |

## Срокове и доказателства: точките, които имат най-голямо значение

Сроковете са същината. Формулировка като „своевременно“ в най-лошия случай не помага. Договорете срокове, разделени по тежест, и определете по какво се измерва тежестта, например по оценката на производителя или на BSI. За извънредни положения трябва да важи правило за спешни случаи: кой е достъпен, кой решава дали една система временно се изключва от мрежата и как се таксува допълнителната работа.

Също толкова важно е доказателството. При PHP2Shell показаният номер на версията често казваше малко, защото дистрибуциите и хостинг доставчиците внасят корекциите като backport. Надеждният документ назовава състоянието на пакета, момента на инсталиране и рестарта на всички PHP процеси. Какви данни точно са от значение, описва [Как да попитате хостинг доставчика си за състоянието на пачовете](https://phpsos.de/bg/ratgeber/hoster-patch-status-erfragen/). Включете тези данни в договора като задължително съдържание.

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

## Достъпи, подизпълнители и напускане

Доставчиците се нуждаят от достъпи и точно те са чест път за атака. Уредете всяко лице да получава собствен акаунт, двуфакторното удостоверяване да е задължително, където технологията го позволява, и по всяко време да можете да поискате актуален списък на всички достъпи. Напусналите служители на доставчика трябва своевременно да бъдат премахнати от всички системи.

Ако самият доставчик работи с партньори, например център за данни или специализиран екип за форензика, трябва да знаете това. Ако някой от тези партньори обработва лични данни, се добавят задължения във връзка със защитата на данните. Повече по темата има в статията [Обработване на данни по поръчка, когато доставчици имат достъп до сървъри](https://phpsos.de/bg/blog/auftragsverarbeitung-serverzugriff/).

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

## Проверка на съществуващите договори: така действате

Не е нужно да преговаряте наново всички договори. За начало е достатъчна прагматична последователност:

1. Съберете всички договори с агенции, хостинг доставчици и ИТ доставчици, които засягат уебсайтове или сървъри.
2. Сверете всеки договор с таблицата по-горе и маркирайте отворените точки.
3. Повдигнете най-важните пропуски писмено пред доставчика, като започнете с обхвата на услугата, сроковете и доказателството.
4. Фиксирайте резултатите като допълнително споразумение и ги дайте на юридическа проверка.
5. Прехвърлете матрицата на задачите в плана за спешни случаи.

За ръководството тази стъпка е и въпрос на грижа. Който ясно урежда отговорностите и документира решенията, стои по-добре, ако по-късно бъдат задавани въпроси. Основания по темата предлага [Отговорност на ръководството при пропуски в ИТ сигурността](https://phpsos.de/bg/compliance/geschaeftsfuehrer-haftung/). Типичното разпределение на задачите при обслужвани сървъри описва [Managed Server: изяснете отговорността](https://phpsos.de/bg/server/managed-server/).

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

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

**Заключение:** Един добър договор не предотвратява уязвимост, но предотвратява във възникнал случай да се губи време с въпроса за отговорността. Тази страница е обща информация и не е правна консултация.


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

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

**Нуждая ли се допълнително от споразумение за обработване на данни (AVV)?**  
Ако доставчикът обработва лични данни по поръчка или може да има достъп до тях, по правило е необходим договор за обработване на данни по чл. 28 от ОРЗД. Той не замества договора за услуги, а го допълва. Изяснете това със своето длъжностно лице по защита на данните.

**Какви срокове за актуализации за сигурност са обичайни?**  
Твърди стойности няма. Смислено е степенуване според тежестта, например отделни срокове за критични, високи и останалите уязвимости. Важно е сроковете да са писмени и да съдържат правило за изключения при извънредни случаи като PHP2Shell.

**Какво се случва с достъпите, когато договорът приключи?**  
Това трябва да урежда договорът: връщане или изтриване на данни, предаване на данни за достъп и документация, отнемане на всички достъпи на доставчика и потвърждение за това.

## Източници

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [php.net: поддържани версии](https://www.php.net/supported-versions.php)