Към съдържанието
PN Scripts

Сигурност

Регистър на нарушенията по ОРЗД и срокът от 72 часа: какво да записвате и как да броите часовете

  • PN Scripts
  • 8 мин четене

Тук посочваме правилата така, както са обнародвани; това не е правен съвет. Дали конкретен инцидент трябва да се съобщи, преценявате вие и вашият консултант.

Лаптоп, забравен във влака, фактура, изпратена на грешния клиент, споделена папка, която една седмица е била публична, искане за откуп на сървъра в офиса. Всяко от тези неща е нарушение на сигурността на личните данни по ОРЗД и всяко пуска часовник: в повечето случаи надзорният орган трябва да научи за него до 72 часа. Малките фирми обикновено откриват две неща в същия ден. Първо, никой не е записал кога е открит проблемът, така че никой не знае кога изтичат 72-та часа. Второ, ОРЗД иска и регистър на нарушенията, които не се съобщават, а такъв няма. Тук показваме какво изисква регламентът, какво да записвате и как да броите 72-та часа правилно, с кратък пример на Python.

#Какво изисква ОРЗД

  • Уведомете надзорния орган без ненужно забавяне и когато е осъществимо, не по-късно от 72 часа след като сте разбрали за нарушението, освен ако няма вероятност то да породи риск за правата и свободите на хората. По-късното уведомление трябва да посочва причините за забавянето (чл. 33, пар. 1). В България органът е Комисията за защита на личните данни (КЗЛД).
  • Обработващият, например хостинг доставчикът или счетоводната фирма, която прави заплатите, ви уведомява без ненужно забавяне, след като разбере (чл. 33, пар. 2). Договорът ви с него трябва да казва как.
  • Уведомлението описва най-малко естеството на нарушението с приблизителните категории и броя на засегнатите хора и записи, лице за контакт, вероятните последици и предприетите или предложените мерки (чл. 33, пар. 3). Каквото още не е известно, може да се подаде на етапи (чл. 33, пар. 4).
  • Документирайте всяко нарушение, съобщено или не: фактите, последиците и предприетите действия, така че органът да може да провери какво сте направили (чл. 33, пар. 5).
  • Съобщете на засегнатите хора без ненужно забавяне, когато има вероятност нарушението да породи висок риск за тях (чл. 34, пар. 1), освен ако е налице някое от изключенията на чл. 34, пар. 3, например данни, които са били криптирани и неразбираеми за получилия ги.

#Кога тръгва часовникът

72-та часа текат от момента, в който администраторът е разбрал. Насоките на Европейския комитет по защита на данните за уведомяване при нарушения казват, че администраторът е разбрал, когато има разумна степен на сигурност, че инцидент със сигурността е довел до засягане на лични данни. Кратка проверка, за да се установи това, е допустима, но трябва да започне веднага. Насоките дават примери: изгубена USB памет с некриптирани данни е известна в момента, в който се забележи, че липсва, защото достъпността на данните е загубена, дори да не може да се каже дали някой ги е прочел; клиент, който препраща чужди данни с доказателство, ви кара да разберете веднага.

Затова първото поле в регистъра не е „дата на нарушението“, а „кога разбрахме“, с часа и часовата зона, а второто е как сте разбрали.

#Какво да записвате

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

  • кога разбрахте, как и кой го откри;
  • какво се случи и откога, ако е известно;
  • видовете засегнати данни и хора и приблизително колко са;
  • вероятните последици за тези хора;
  • мерките, за да го спрете и да намалите последиците;
  • оценения риск и защо: няма вероятен риск, риск или висок риск;
  • дали и кога е уведомен органът, входящият номер и причините, ако е със закъснение;
  • дали са уведомени засегнатите хора, кога и как, или на кое изключение сте се позовали;
  • обработващият, ако има такъв, и кога ви е уведомил.

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

#72 часа са часове, а не дни

Регламентът брои часове. Почивните и празничните дни влизат в тях, така че нарушение, открито в петък следобед, трябва да се съобщи до понеделник следобед. Има и по-скрит капан: когато часовникът се мести, три календарни дни не са 72 часа. Бройте в UTC и превръщайте обратно:

import math
from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo

SOFIA = ZoneInfo("Europe/Sofia")


def deadline(aware_at: datetime) -> datetime:
    """72 hours after the controller became aware, counted in real hours (through UTC)."""
    return (aware_at.astimezone(timezone.utc) + timedelta(hours=72)).astimezone(SOFIA)


def status(aware_at: datetime, risk: str, notified_at: datetime | None, now: datetime) -> str:
    """risk: "unlikely" (record only), "risk" (notify the authority) or "high" (also tell the people)."""
    if risk == "unlikely":
        return "No notification needed: keep it in the register with the reasons."
    due = deadline(aware_at)
    if notified_at is None:
        if now.timestamp() > due.timestamp():
            return f"OVERDUE since {due:%d.%m %H:%M}: notify now and give the reasons for the delay."
        hours = (due.timestamp() - now.timestamp()) / 3600
        return f"Notify the authority by {due:%d.%m %H:%M} ({hours:.1f} h left)."
    late = (notified_at.timestamp() - due.timestamp()) / 3600
    if late <= 0:
        return "Notified in time."
    return f"Notified {math.ceil(late)} h late: the notification must give the reasons for the delay."

Пуснахме го за нарушение, открито в петък, 23 октомври 2026 г., в 16:30 ч. в София. Лятното часово време свършва в неделя, 25 октомври, когато часовникът се връща от 04:00 на 03:00 ч., затова срокът е понеделник, 26 октомври, в 15:30 ч. Три дни по календара дават 16:30 ч., а това са 73 реални часа. В събота в 10:00 ч. примерът казва „Notify the authority by 26.10 15:30 (54.5 h left)“ (уведомете до 15:30 ч., остават 54,5 часа); уведомление в понеделник в 18:10 ч. е „3 часа закъснение“, с напомняне, че уведомлението трябва да посочи причините; а нарушение, оценено като без вероятен риск, остава само в регистъра с мотивите. В Python е важно да изваждате времена в секунди, а не обекти datetime: две datetime с един и същ обект за часова зона се сравняват по стенния часовник, а не по реалното време.

Таблицата има същия проблем, защото датите и часовете в нея нямат часова зона. Добавите ли три дни в клетка, закъснявате с час в последния уикенд на октомври и подранявате с час в последния уикенд на март. Или го отбележете в таблицата, или пазете колоната със срока в UTC.

#Оценка на риска

Дали да уведомите зависи от риска за хората, а не от размера на инцидента. Насоките предлагат да гледате вида на нарушението, вида и количеството на данните, колко лесно се идентифицират хората, колко тежки могат да са последиците, специалните категории данни, уязвимите лица и колко души са засегнати; ENISA публикува методика за оценка на тежестта. Изпратен имейл с поръчката на един клиент е различно нещо от изтекъл списък с пациенти. Записвайте мотивите и в двата случая.

#Регистър, който следи срока вместо вас

Направихме Pazilka, комплект документи по ОРЗД за малкия бизнес в България, на български и английски. Таблицата с регистри за Excel и LibreOffice съдържа дейностите по обработване, нарушенията, исканията на субектите и сроковете за съхранение и се проверява сама с обикновени формули: за всяко нарушение показва срока от 72 часа, дали е спазен и с колко часа е пропуснат, просрочените отворени нарушения и висок риск без уведомяване на засегнатите. Към нея има осем шаблона на документи, сред тях процедура при нарушение с образец за уведомление, който събира съдържанието по чл. 33, пар. 3. Листът с нарушенията брои 72-та часа в реално време през UTC, така че срокът му е верен и в уикендите, когато се сменя часовото време. Тестван е, като LibreOffice изчислява 22 таблици и всяка проверка се сравнява с независим модел на Python, правното съдържание не е преглеждано от юрист и е обявен като „Очаквайте скоро“.

За другия часовник по ОРЗД, едномесечния срок за отговор на искания за достъп и изтриване, вижте ръководството ни за исканията по ОРЗД в Laravel.

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

Броят ли се почивните дни в 72-та часа?

Да. ОРЗД брои часове, а не работни дни, така че нарушение, открито в петък в 16:30 ч., трябва да се съобщи до понеделник в 16:30 ч., или в 15:30 ч., ако през този уикенд часовникът е върнат назад.

Трябва ли да записвам нарушение, което не съобщавам?

Да. Чл. 33, пар. 5 изисква да документирате всяко нарушение на сигурността на личните данни с фактите, последиците и предприетите действия, а насоките препоръчват да запишете и защо сте решили да не уведомите.

Какво да правя, ако нямам всички подробности до 72 часа?

Уведомете с каквото знаете и изпратете останалото на етапи, без по-нататъшно ненужно забавяне. Ако уведомите след 72 часа, посочете причините за забавянето.

Кога трябва да съобщя на засегнатите хора?

Когато има вероятност нарушението да породи висок риск за тях, освен ако е налице изключение по чл. 34, пар. 3, например криптиране, което е направило данните неразбираеми.

#Източници

Още по темата

Още по темата

Коментари

Коментари

Напишете първия коментар.

Оставете коментар

Следваща стъпка

pnscripts.com/bg/contact

Пишете на екипа

Попитайте за статия или ни разкажете за проект, който искате да изградим. Отговаряме до един работен ден.

Пишете ни

Семейството PN Scripts

Другите сайтове на PN Scripts

Хостингът, игрите и блогът имат свои сайтове, поддържани от същата компания.

  • pnscripts.com

    PN Scripts

    Софтуерно инженерство

    Уеб и мобилни приложения, API и игри по поръчка, плюс нашите продукти и плъгини с отворен код.

  • games.pnscripts.com

    Игри

    Игри и игрови сървъри

    Домът на игрите на PN Scripts: безплатни браузърни игри, които се играят веднага, а игровите сървъри предстоят.

  • hosting.pnscripts.com

    Хостинг

    Хостинг и инфраструктура

    Споделен хостинг, KVM VPS, самостоятелни сървъри и домейни от същата компания, която изработва проекта ви.

  • blog.pnscripts.com

    Блог

    Статии и бележки

    Практични статии за разработка на софтуер, хостинг, отворен код и игри, писани от хората, които ги създават.

    Вие сте тук