Анализ на въздействието върху бизнеса за ISO 27001, NIS2 и DORA
Одиторският въпрос, който разкрива реалния пропуск в непрекъснатостта
Понеделник сутрин е и Maria, CISO на бързо растяща FinTech компания, се подготвя за заседание на комитета по риска към съвета. Темата е кратка: „Готовност за DORA и NIS2: преглед на BIA“.
Екипът ѝ е изградил това, което повечето ръководители очакват да видят. Налице са сертифицирана ISO/IEC 27001:2022 ISMS, наръчници за реагиране при инциденти, екранни снимки за резервни копия, доклади за уязвимости, въпросници за доставчици, схеми на облачна архитектура и актуализиран регистър на риска. Корпоративните клиенти изпращат въпросници по NIS2. Клиенти от финансовия сектор включват клаузи по DORA в договорите. Надзорният одит по ISO/IEC 27001:2022 е само след месец.
Тогава външният одитор задава въпроса, който променя разговора:
„Ако платформата ви за въвеждане на клиенти е недостъпна 18 часа, кои регулирани услуги са засегнати, кои доставчици участват, какъв е одобреният приоритет за възстановяване и къде са доказателствата, че бизнесът е приел RTO и RPO?“
В залата настъпва тишина.
Графикът за резервно копиране казва едно. Планът за аварийно възстановяване казва друго. Договорът с доставчика включва SLA за наличност, но няма доказателства от тест за възстановяване. Регистърът на риска споменава наличност, но не обяснява защо една услуга трябва да се възстанови по-бързо от друга. Ръководството е одобрило политиката за сигурност, но не и въздействието върху бизнеса от прекъсване.
Това е проблемът с анализа на въздействието върху бизнеса през 2026 г.
Анализът на въздействието върху бизнеса, или BIA, вече не е електронна таблица, приложена към план за непрекъснатост. Той е доказателственият мост между бизнес услугите, ИКТ активите, доставчиците, приоритетите за възстановяване, RTO/RPO, праговете за инциденти, тестването на устойчивостта и отчетността пред съвета. За организациите, които съгласуват ISO/IEC 27001:2022 с непрекъснатост по NIS2 и ИКТ устойчивост по DORA, BIA е мястото, където съответствието става оперативно.
Най-силните организации вече имат много от правилните контроли. Слабостта им е проследимостта. BIA превръща разпръснатите доказателства в готова за одит история: какво е важно, защо е важно, колко бързо трябва да се възстанови, кои зависимости го поддържат, какво е тествано, какво се е провалило, какво е подобрено и кой е одобрил остатъчния риск.
Защо старите таблици за BIA вече са риск
NIS2 и DORA промениха тона на съответствието в областта на непрекъснатостта. Те не разглеждат непрекъснатостта на дейността, аварийното възстановяване, реагирането при инциденти, устойчивостта на доставчиците и управлението като отделни документи. Очакването е те да работят като единна система.
За субектите по NIS2, Article 21 изисква технически, оперативни и организационни мерки за управление на рисковете за мрежовите и информационните системи и за предотвратяване или минимизиране на въздействието на инцидентите върху получателите на услуги и други услуги. Минималните мерки включват анализ на риска, обработване на инциденти, непрекъснатост на дейността, включително управление на резервните копия, аварийно възстановяване и кризисно управление, сигурност на веригата на доставки, обработване на уязвимости, оценка на ефективността на контролите, обучение, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите, MFA и сигурни комуникации.
NIS2 Article 20 пренася въпроса в заседателната зала на съвета. Органите на управление трябва да одобряват мерките за управление на риска за киберсигурността, да наблюдават внедряването им и могат да носят отговорност за нарушения. Това означава, че неподкрепен с доказателства четиричасов RTO не е просто техническо несъответствие. Това е управленска слабост.
DORA се прилага от 17 януари 2025 г. и създава единна рамка на ЕС за управление на ИКТ риска, докладване на инциденти, тестване на цифровата оперативна устойчивост, управление на ИКТ риска от трети страни, договорни изисквания и надзор върху критични доставчици на ИКТ услуги от трети страни. За финансовите субекти и за доставчиците на технологии, които ги поддържат по договор, DORA превръща оперативната устойчивост в структурирано изискване за доказателства.
DORA Articles 5 and 6 изискват управление и документирана рамка за управление на ИКТ риска. Articles 7 to 14 обхващат надеждни и устойчиви ИКТ системи, идентифициране на активи и зависимости, защита, откриване, ИКТ непрекъснатост на дейността, резервни копия, възстановяване, възстановяване на услуги, извличане на поуки след инцидент, осведоменост, обучение и кризисна комуникация. Articles 24 to 26 изискват тестване на цифровата оперативна устойчивост за финансови субекти, които не са микропредприятия. Articles 28 to 30 формализират ИКТ риска от трети страни, регистрите на договори за ИКТ услуги, стратегии за изход, нива на обслужване, права на одит и изисквания за извънредни ситуации.
ISO/IEC 27001:2022 предоставя гръбнака на системата за управление. Нейните клаузи изискват организацията да дефинира контекст, заинтересовани страни, правни и договорни задължения, обхват, лидерство, политика, роли, оценка на риска, третиране на риска, Декларация за приложимост, оперативно планиране, оценка на изпълнението и непрекъснато подобрение.
Липсващото звено често е BIA. Без него плановете за непрекъснатост не са ясно основани на риска, целите за резервно копиране не са одобрени от бизнеса, доставчиците не са съпоставени с критичните услуги и ръководството не може надеждно да докаже, че решенията за устойчивост са взети въз основа на въздействието върху бизнеса.
BIA като контролна равнина за доказателства за устойчивост
Защитимият BIA отговаря на седем въпроса, които одитори, регулатори, клиенти и съвети задават все по-често:
- Кои бизнес услуги са критични?
- Кои ИКТ активи, хранилища на данни, хора, доставчици и комунални услуги поддържат всяка услуга?
- Какво е оперативното, финансовото, правното, договорното, клиентското, свързаното с безопасността и репутационното въздействие от прекъсване във времето?
- Какъв е Maximum Tolerable Downtime, или MTD?
- Какви са одобрените Recovery Time Objective, или RTO, и Recovery Point Objective, или RPO?
- Правят ли резервните копия, резервираността, облачните услуги, доставчиците, осигуряването с персонал и комуникационните механизми тези цели постижими?
- Организацията тествала ли е пътя за възстановяване и прегледала ли е резултатите?
Корпоративната Политика за непрекъснатост на дейността и аварийно възстановяване на Clarysec P32 Политика за непрекъснатост на дейността и аварийно възстановяване формулира изискването ясно:
Анализът на въздействието върху бизнеса (BIA) се извършва поне веднъж годишно за всички критични бизнес звена и се преглежда при съществени промени в системи, процеси или зависимости. Резултатите от BIA трябва да определят: 5.2.1. Максимално допустим период на прекъсване (MTD) 5.2.2. Целеви стойности за време за възстановяване (RTO) 5.2.3. Целеви точки за възстановяване (RPO) 5.2.4. Критични зависимости (системи, доставчици, персонал)
Тази клауза дава на одиторите практическа отправна точка. Тя също предотвратява често срещания пропуск, при който планът за непрекъснатост на дейността, планът за аварийно възстановяване, графикът за резервно копиране, регистърът на доставчиците и процесът за реагиране при инциденти използват различно определение за „критичен“.
Същата политика изисква интегриран управленски подход:
Организацията трябва да поддържа интегрирана система за управление на непрекъснатостта на дейността (BCMS), съгласувана с ISO 22301 и ISO/IEC 27001, като осигурява интеграция на: 5.1.1. Анализ на въздействието върху бизнеса (BIA) 5.1.2. Оценка на риска за сигурността при заплахи за непрекъснатостта 5.1.3. Планове за непрекъснатост на дейността (BCP) 5.1.4. ИКТ планове за аварийно възстановяване (DRP) 5.1.5. Програми за тестване и упражнения 5.1.6. Документация и непрекъснато подобрение
Това е разликата между съответствие по контролен списък и устойчивост, готова за одит. BIA не е еднократен документ. Той става част от доказателствената верига на ISMS и BCMS.
Как ISO/IEC 27001:2022 превръща BIA в одитируеми доказателства
ISO/IEC 27001:2022 не изисква всяка организация да използва израза „анализ на въздействието върху бизнеса“ във всяка клауза, но неговите изисквания правят доказателствата от BIA изключително ценни.
Клаузи 4.1 до 4.4 изискват организацията да разбира вътрешните и външните въпроси, заинтересованите страни, правните и регулаторните задължения, договорните изисквания, интерфейсите, зависимостите и обхвата на ISMS. BIA често е най-практичното доказателство за тези интерфейси и зависимости. Той показва коя облачна услуга, платежен процесор, доставчик на идентичност, телекомуникационен доставчик, управлявана услуга за сигурност, център за данни или външно възложен екип за поддръжка осигурява критична услуга.
Клаузи 5.1 до 5.3 изискват лидерство от висшето ръководство, осигуряване на ресурси, комуникация, възлагане на роли и докладване. BIA дава на ръководството бизнес основание за инвестиции в непрекъснатост. Без него целите RTO и RPO са технически желания, а не одобрени бизнес изисквания.
Клаузи 6.1.1 до 6.1.3 изискват повторяема оценка и третиране на риска за информационната сигурност. Организацията трябва да идентифицира рисковете за поверителност, цялостност и наличност, да анализира последиците и вероятността, да определи нивата на риск, да приоритизира третирането, да избере контроли, да сравни избраните контроли с Annex A, да изготви Декларация за приложимост, да създаде План за третиране на риска и да получи одобрение от собственика на риска. BIA засилва частта „последици“ в оценката на риска. Той обяснява защо двучасово прекъсване на една система е допустимо, докато двучасово прекъсване на друга създава вреда за клиентите, регулаторна експозиция, нарушение на договор или сериозно въздействие върху приходите.
Annex A предоставя каталога с контроли. За BIA и непрекъснатостта най-релевантните контроли от ISO/IEC 27001:2022 Annex A включват:
| Контрол от ISO/IEC 27001:2022 Annex A | Правилно наименование на контрола | Релевантност за BIA |
|---|---|---|
| A.5.29 | Информационна сигурност по време на прекъсване | Гарантира, че контролите за поверителност, цялостност и наличност остават ефективни при деградирали операции |
| A.5.30 | ИКТ готовност за непрекъснатост на дейността | Гарантира, че ИКТ способностите поддържат одобрените цели за непрекъснатост на дейността |
| A.8.13 | Резервно копиране на информация | Подпомага възстановяването и постигането на RPO чрез защитени процеси за резервно копиране |
| A.8.14 | Резервираност на съоръженията за обработка на информация | Подпомага целите за възстановяване, които не могат да бъдат постигнати само чрез възстановяване от резервно копие |
| A.8.15 | Регистриране | Запазва видимостта, възможността за разследване и доказателствата по време на прекъсване |
| A.8.16 | Дейности по мониторинг | Открива деградация, инциденти и статус на възстановяването |
| A.5.19 | Информационна сигурност във взаимоотношенията с доставчици | Свързва риска, свързан с доставчици, със зависимостите на критичните услуги |
| A.5.20 | Адресиране на информационната сигурност в споразумения с доставчици | Гарантира, че договорите включват очаквания за сигурност и непрекъснатост |
| A.5.21 | Управление на информационната сигурност във веригата за доставка на ИКТ | Адресира ИКТ риска във веригата на доставки за критични услуги |
| A.5.22 | Мониторинг, преглед и управление на промените в услугите на доставчици | Поддържа зависимостите от доставчици актуални при промени в услугите |
| A.5.23 | Информационна сигурност при използване на облачни услуги | Гарантира управление на изискванията за облачна зависимост, изход и устойчивост |
| A.5.24 | Планиране и подготовка за управление на инциденти по информационна сигурност | Свързва сценариите за прекъсване с планираната способност за реагиране |
| A.5.25 | Оценка и решение относно събития по информационна сигурност | Подпомага оценката на сериозността на инциденти чрез въздействието върху услугата |
| A.5.26 | Реагиране при инциденти по информационна сигурност | Насочва действията за реагиране според критичността за бизнеса |
| A.5.27 | Извличане на поуки от инциденти по информационна сигурност | Връща извлечените поуки обратно в BIA, BCP, DRP и третирането на риска |
| A.5.28 | Събиране на доказателства | Запазва доказателства по време на инциденти и операции по възстановяване |
| A.5.31 | Правни, законови, регулаторни и договорни изисквания | Свързва целите за устойчивост със задължения като NIS2, DORA, GDPR и клиентски договори |
В Zenith Controls: Ръководство за междурегулаторно съответствие Zenith Controls, Clarysec профилира контрол 5.30 от ISO/IEC 27002:2022, ИКТ готовност за непрекъснатост на дейността, като коригиращ контрол, фокусиран върху наличността, съпоставен с концепцията за киберсигурност Respond, оперативната способност за непрекъснатост и областта на сигурността, свързана с устойчивостта. Контрол 5.29, информационна сигурност по време на прекъсване, е профилиран като превантивен и коригиращ, защитаващ поверителност, цялостност и наличност. Контрол 8.13, резервно копиране на информация, е профилиран като коригиращ, поддържащ цялостност и наличност чрез възстановяване.
Това разграничение е важно. BIA не трябва да пита само: „Можем ли да възстановим?“ Той трябва да пита и: „Можем ли да останем защитени по време на прекъсване?“ При ransomware събитие, прекъсване на облачна услуга, отказ на доставчик или инцидент в център за данни организацията все още се нуждае от контрол на достъпа, регистриране, мониторинг, запазване на доказателства, сигурни комуникации и мерки за защита на поверителността.
Практически модел на доказателствата за BIA
Силен BIA свързва езика на бизнеса с техническите доказателства. Clarysec обичайно структурира модела на доказателствата в пет слоя.
| Слой на доказателствата | Какво доказва | Типични артефакти |
|---|---|---|
| Критичност на бизнес услугите | Организацията разбира кои услуги са най-важни и защо | Каталог на услугите, бележки от работни срещи за BIA, точкова оценка на въздействието, одобрение от ръководството |
| Картографиране на зависимостите | Критичните услуги са свързани с ИКТ активи, данни, доставчици, хора и комунални услуги | CMDB, регистър на активите, карта на приложенията, регистър на доставчиците, карта на потоците от данни |
| Цели за възстановяване | MTD, RTO и RPO са одобрени и реалистични | Регистър на BIA, BCP, DRP, график за резервно копиране, съпоставяне със SLA на доставчици |
| Внедряване на контролите | Техническите и организационните контроли поддържат целите за възстановяване | Конфигурация на резервни копия, дизайн на резервираността, мониторинг, контрол на достъпа, наръчници за инциденти |
| Валидация и подобрение | Способността за възстановяване е тествана и пропуските се проследяват | Тест за възстановяване, доклад за превключване при отказ, настолно упражнение, журнал за коригиращи действия, План за одит |
Този модел на доказателствата работи, защото следва начина, по който мислят одиторите. Първо питат какво е критично. След това питат какво го поддържа. После питат кой е одобрил целта за възстановяване. След това питат дали техническите механизми и механизмите при доставчиците могат да постигнат целта. Накрая питат дали организацията е тествала и подобрила способността.
NIST CSF 2.0 е полезен като комуникационен слой. Методът с CSF профили насърчава организациите да дефинират обхват, да събират входни данни като политики, приоритети на корпоративния риск, регистри на BIA, изисквания за киберсигурност, стандарти, процедури, предпазни мерки и работни роли, да създават текущи и целеви профили, да анализират пропуски, да изготвят приоритизиран план за действие, да внедряват този план и да актуализират профила. Това почти напълно съответства на начина, по който BIA трябва да захранва пътна карта за междурегулаторно съответствие.
Едноседмично BIA упражнение, което създава реални доказателства
Да приемем, че доставчик на SaaS поддържа клиенти от сектора на финансовите услуги. Платформата му поддържа въвеждане на клиенти, проверка на документи и клиентски уведомления. Самият той не е банка, но клиентите му изпращат договорни искания, произтичащи от DORA, и въпросници за доставчици по NIS2.
Фокусирано едноседмично упражнение може бързо да създаде полезни доказателства.
Ден 1: Идентифициране на критични услуги и времеви прозорци на въздействие
Започнете с услугите, а не със сървърите. Включете собственици на бизнес процеси, ИТ, сигурност, правен отдел, поддръжка, защита на личните данни и управление на доставчици.
| Бизнес услуга | Въздействие след 4 часа | Въздействие след 24 часа | Потенциален регулаторен или договорен тригер |
|---|---|---|---|
| Портал за въвеждане на клиенти | Забавено откриване на нови акаунти, увеличаване на заявките към поддръжката | Въздействие върху приходите, нарушение на SLA, клиентска ескалация | Искане от клиент по DORA за непрекъснатост, възможно уведомление за клиентски инцидент |
| Работен процес за проверка на идентичност | Необходими са ръчни обходни процедури | Натрупване на неизпълнени задачи, забавяне на прегледите за измами, репутационен ущърб | Притеснение по GDPR относно наличността и цялостността на лични данни |
| Услуга за клиентски уведомления | Деградирали комуникации | Невъзможност за уведомяване на потребители по време на инцидент | Очакване по NIS2 за комуникация с получатели на услуги |
| Административен API за корпоративни клиенти | Оперативно прекъсване за клиентите | Нарушение на договор, претоварване на service desk | Преглед на доставчик от клиент по NIS2 или DORA |
Тази рамка е важна. Регулаторите и клиентите разпознават услуги и функции. Приложенията са важни, защото поддържат тези услуги.
Ден 2: Картографиране на зависимостите
За всяка услуга картографирайте приложения, бази данни, инфраструктура, облачни услуги, доставчици на идентичност, мониторинг, инструменти за резервно копиране, хора, доставчици и поддържащи комунални услуги.
| Услуга | ИКТ актив | Данни | Доставчик | Вътрешен собственик | Въпрос, свързан с непрекъснатостта |
|---|---|---|---|---|---|
| Работен процес за проверка на идентичност | API за проверка и хранилище за документи | Документи за самоличност, журнали за одит | Доставчик на IDV SaaS, облачно хранилище | Ръководител на платформата | SLA на доставчика има цел за наличност, но няма доказателства от тест за възстановяване |
| Услуга за клиентски уведомления | Платформа за имейл/SMS | Данни за контакт, шаблони на съобщения | Доставчик на съобщения | Клиентски операции | Не е конфигуриран алтернативен доставчик |
| Административен API | Kubernetes клъстер, база данни, API шлюз | Клиентска конфигурация, журнали | Облачен доставчик, DNS доставчик | Инженерен мениджър | Тестът за възстановяване обхваща базата данни, но не и конфигурацията на API шлюза |
Тук BIA започва да създава стойност. Той разкрива невидимия път за възстановяване, включително зависимостите, които често се пропускат в технически DR план.
Ден 3: Одобряване на MTD, RTO и RPO
Собственикът на бизнес процеса предлага MTD. ИТ и сигурността валидират дали предложените RTO и RPO са технически постижими. Ръководството одобрява крайните цели.
За по-малки организации Политиката за непрекъснатост на дейността и аварийно възстановяване - SME на Clarysec P32S Политика за непрекъснатост на дейността и аварийно възстановяване - SME дава същата дисциплина на по-опростен език. Тя изисква BCP/DR планове, които определят подхода за възстановяване на основните функции:
Управителят (GM) трябва да одобрява и поддържа планове за непрекъснатост на дейността и аварийно възстановяване (BCP/DRP), които ясно определят подхода на организацията за възстановяване на основните функции.
Тя също изисква планът да включва:
приоритизирани услуги и системи (критични бизнес функции)
И:
Целеви стойности за време за възстановяване (RTO) и целеви точки за възстановяване (RPO) за всяка система
Ключът не е прекомерната документация. Ключът е проследимост, одобрение и доказателства, че целите за възстановяване се основават на реално въздействие върху бизнеса.
Ден 4: Съгласуване на резервните копия с въздействието върху бизнеса
Много организации се провалят тук. BIA може да задава четиричасов RPO, докато резервните копия се изпълняват на всеки 24 часа. Или инструментът за резервно копиране защитава продукционните бази данни, но не и конфигурация, тайни, хранилища за инфраструктура като код, обектно хранилище, DNS записи, настройки на идентичност или конфигурация на API шлюз.
Политиката за резервно копиране и възстановяване на Clarysec P15 Политика за резервно копиране и възстановяване изисква Главен график за резервно копиране, обвързан с резултатите от BIA:
Трябва да се поддържа Главен график за резервно копиране и той да се преглежда ежегодно. Той трябва да посочва: 5.1.1 Честота на резервно копиране (например ежедневни инкрементални резервни копия и седмични пълни резервни копия) 5.1.2 Срокове за съхранение по система или тип данни 5.1.3 Изисквания за шифроване и данни за местоположението на съхранение 5.1.4 Цели RTO/RPO, свързани с резултатите от оценката на въздействието върху бизнеса
Тази клауза е одиторско злато. Тя принуждава дизайна на резервните копия да отразява въздействието върху бизнеса, а не удобството за съхранение.
Ден 5: Тестване на един път за възстановяване и идентифициране на коригиращи действия
Не тествайте всичко наведнъж. Изберете една критична услуга и проведете фокусиран тест за възстановяване. Възстановете базата данни. Изградете отново конфигурацията на приложението. Валидирайте автентикацията. Потвърдете, че журналите са налични. Проверете способността за клиентски уведомления. Запишете изразходваното време, загубата на данни, дефектите, решенията и коригиращите действия.
В Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint, фазата Controls in Action, Step 23, разглежда организационните контроли, включително ИКТ готовност за непрекъснатост на дейността. Тя задава въпроса, който всеки одиторски екип трябва да зададе:
Могат ли вашите системи да поддържат целите ви за непрекъснатост на дейността, когато светлините примигнат, когато мрежите прекъснат, когато настъпи бедствие?
Същата стъпка дава практическа инструкция:
Проверете дали целевите стойности за време за възстановяване (RTO) и целевите точки за възстановяване (RPO) за критичните системи са съгласувани с очакванията за непрекъснатост на дейността (5.30). Проведете поне един технически тест за възстановяване или симулация на превключване при отказ и документирайте резултатите.
Това е разликата между това да имате BIA и това да имате защитими доказателства за BIA. Целта не е само документирана. Тя е тествана.
Съпоставяне на доказателствата от BIA с NIS2, DORA, GDPR, NIST и COBIT 2019
Добре изграден BIA става актив за междурегулаторно съответствие. Един набор от доказателства може да отговори на много въпроси.
| Перспектива на съответствие | Какво поддържа BIA | Доказателства за представяне |
|---|---|---|
| ISO/IEC 27001:2022 | Контекст, обхват, оценка на риска, третиране, контроли за непрекъснатост и доставчици от Annex A | Регистър на BIA, оценка на риска, SoA, BCP/DRP, доклади от тестове, одобрения от ръководството |
| NIS2 | Непрекъснатост на дейността, управление на резервни копия, аварийно възстановяване, кризисно управление, сигурност на веригата на доставки, управление на активите, въздействие на инциденти | Карта на критичните услуги, зависимости от доставчици, RTO/RPO, тестове за непрекъснатост, прагове за инциденти |
| DORA | Рамка за ИКТ риск, стратегия за цифрова оперативна устойчивост, критични или важни функции, тестване на устойчивостта, ИКТ риск от трети страни | Карта на ИКТ активи и зависимости, програма за тестване, регистър на договори за ИКТ услуги, стратегия за изход |
| GDPR | Наличност, цялостност, отчетност, оценка на нарушение, защита на личните данни | Класификация на въздействието върху данните, доказателства за възстановяване, критерии за ескалация по защита на личните данни, валидиране на възстановяване на данни |
| NIST CSF 2.0 | Резултати Govern, Identify, Protect, Detect, Respond, Recover и CSF профили | Текущ и целеви профил, анализ на пропуски, POA&M, критичност на доставчиците, изпълнение на възстановяването |
| COBIT 2019 | Управление на ползи, риск, ресурси, непрекъснатост, изпълнение на доставчиците, уверение | Докладване към съвета, приемане на риска, собственост върху услугата, мониторинг на контролите, одитни констатации |
GDPR често се пренебрегва в дискусиите за BIA. Въпреки това GDPR Article 5 изисква личните данни да се обработват с цялостност и поверителност, включително защита срещу случайна загуба, унищожаване или повреда чрез подходящи технически или организационни мерки. Отчетността изисква администраторът да доказва съответствие. Ако платформа за лични данни не може да бъде възстановена в одобрен и тестван срок, рискът за защитата на личните данни засяга наличността, цялостността, оценката на нарушение и доверието на клиентите.
Докладването на инциденти по NIS2 добавя още едно измерение. Article 23 изисква значимите инциденти да се уведомяват без ненужно забавяне, включително ранно предупреждение в рамките на 24 часа, уведомление за инцидент в рамките на 72 часа и финален доклад в рамките на един месец. BIA помага за класифициране на степента на сериозност, защото дефинира засегнатите услуги, получателите на услуги, оперативното прекъсване и потенциалното трансгранично въздействие.
Класификацията на инциденти по DORA също отчита засегнати клиенти или трансакции, продължителност, географски обхват, загуби на данни, критичност на засегнатите услуги и икономическо въздействие. Това са полета в BIA. Ако BIA е слаб, класификацията на инцидента става субективна в най-неподходящия момент.
Непрекъснатостта при доставчиците е мястото, където BIA среща договорната реалност
За NIS2 и DORA непрекъснатостта при доставчиците вече не е по избор. NIS2 Article 21 включва сигурност на веригата на доставки и изисква внимание към уязвимости на доставчици, качество и устойчивост на продукти, практики на доставчиците за киберсигурност и процедури за сигурна разработка. DORA изисква ИКТ рискът от трети страни да се управлява в рамката за управление на ИКТ риска, включително регистри на договори за ИКТ услуги, надлежна проверка, риск от концентрация, стратегии за изход, права на одит и достъп, съдействие при инциденти, нива на обслужване и изисквания за извънредни ситуации.
Корпоративната Политика за непрекъснатост на дейността и аварийно възстановяване изисква:
Зависимости от трети страни и веригата на доставки 6.5.1. Договорите с критични доставчици трябва да включват задължения за непрекъснатост и ангажименти за време за възстановяване. 6.5.2. Ключовите доставчици на услуги трябва, при поискване, да доказват периодично тестване на непрекъснатостта и участие в учения за инциденти.
Версията за SME също изисква:
точки за контакт с доставчици по въпроси на непрекъснатостта
Това малко поле може да бъде решаващо при реален инцидент. Ако планът ви за възстановяване казва „свържете се с поддръжката на облачния доставчик“, но никой не знае пътя за ескалация, договорната референция, процеса по степен на сериозност или контакта извън работно време, RTO е фикция.
| Доставчик | Поддържана услуга | Критичност | Договорен ангажимент за възстановяване | Налични доказателства | Пропуск |
|---|---|---|---|---|---|
| Облачен доставчик | Хостинг на основната платформа | Критична | Наличност в множество зони, SLA за поддръжка | Архитектурна схема, табло на услугата | Няма документиран регионален тест за превключване при отказ |
| Доставчик на идентичност | Административна и клиентска автентикация | Критична | SLA за наличност | SOC доклад на доставчика, статус страница | Няма алтернативна процедура за автентикация |
| Доставчик на съобщения | Клиентски уведомления | Висока | SLA за наличност | Договор и контакти за инциденти | Няма тестван резервен доставчик |
| Доставчик на управлявани услуги за сигурност | Откриване и реагиране | Висока | SLA за мониторинг и ескалация | Месечен доклад, наръчник | Не е включен в упражнение за непрекъснатост |
Тази таблица не заменя управлението на риска, свързан с доставчици. Тя прави риска, свързан с доставчици, оперативен.
Как одиторите ще тестват вашия BIA
Одитор по ISO/IEC 27001:2022 обикновено започва с обхвата, контекста, оценката на риска, третирането на риска, Декларацията за приложимост, контролите от Annex A, документираната информация, оперативното планиране, оценката на изпълнението и подобрението. Той ще сравни BIA с оценката на риска и SoA. Ако A.5.30, A.5.29 или A.8.13 са включени, ще поиска доказателства за внедряване и тестване.
Преглеждащ по DORA ще се фокусира върху критични или важни функции, ИКТ активи, ИКТ зависимости от трети страни, тестване на устойчивостта, класификация на инциденти, договорни изисквания, стратегии за изход и надзор от управителния орган. Той ще очаква BIA да е съгласуван с рамката за управление на ИКТ риска, стратегията за цифрова оперативна устойчивост, ИКТ плановете за непрекъснатост на дейността, плановете за реагиране и възстановяване и програмата за тестване.
Надзорен орган по NIS2 ще поиска мерки за непрекъснатост на дейността, управление на резервни копия, аварийно възстановяване, кризисно управление, сигурност на веригата на доставки, управленско одобрение и способност за докладване на значими инциденти. BIA трябва да докаже, че тези мерки се основават на въздействието върху услугите и одобрени приоритети.
Оценител по NIST CSF 2.0 ще попита как BIA информира Current Profile, Target Profile, анализа на пропуски и плана за действие. Той ще разгледа резултатите от Govern за правни, регулаторни, договорни, рискови, ролеви, политически, надзорни решения и решения, свързани с риска от доставчици. Ще разгледа също резултатите Identify, Protect, Detect, Respond и Recover.
Одитор по COBIT 2019 или в стил ISACA обикновено ще се фокусира върху управлението. Кой е собственик на услугата? Кой е приел риска? Съгласувани ли са целите с корпоративните цели? Наблюдават ли се доставчиците? Балансирани ли са ползите, рискът и ресурсите? Проследяват ли се коригиращите действия до приключване?
Политиката за одит и мониторинг на съответствието на Clarysec Политика за одит и мониторинг на съответствието прави BIA част от цикъла за планиране на одита:
Риск-базиран План за одит трябва да бъде разработван и одобряван ежегодно, като се вземат предвид: 5.2.1 Резултатите от най-скорошните оценки на риска и анализа на въздействието върху бизнеса (BIA) 5.2.2 Предходни одитни констатации и статус на коригиращите действия 5.2.3 Промени в процеси, ИТ инфраструктура, системи или доставчици 5.2.4 Външни задължения като DORA Article 25 или клиентски договори
Това е стъпка към зрелост, която много организации пропускат. BIA не трябва да стои извън уверението. Той трябва да води плана за одит.
Често срещани пропуски в BIA, откривани при реални оценки
Едни и същи слабости се появяват многократно.
Първо, BIA изброява приложения, а не услуги. Клиентите и регулаторите се интересуват от прекъсване на услугите. Приложенията са важни, защото поддържат тези услуги.
Второ, целите RTO и RPO се копират от шаблони. Четиричасов RTO може да звучи разумно, докато тест за възстановяване не покаже, че са нужни девет часа за повторно изграждане на интеграция с идентичност, възстановяване на конфигурация, възстановяване на данни, валидиране на цялостта и повторно активиране на мониторинга.
Трето, резервните копия не са свързани с въздействието върху бизнеса. Честотата, срокът за съхранение, шифроването, местоположението на съхранение, приоритетът за възстановяване и тестването трябва да отразяват одобрените цели за възстановяване.
Четвърто, доставчиците се третират като елементи от въпросници, а не като зависимости за възстановяване. Ангажиментите за непрекъснатост от доставчици, контактите за ескалация, доказателствата за възстановяване и участието в учения за инциденти трябва да бъдат обвързани с критичните услуги.
Пето, липсва одобрение от ръководството. По NIS2 и DORA управленската отчетност е изрична. По ISO/IEC 27001:2022 лидерството, ролите, одобрението от собственик на риска и докладването на изпълнението са основни изисквания.
Шесто, тестването е твърде тясно. Възстановяването на един файл е полезно, но не доказва възстановяване на услуга. Пътят за възстановяване на критична услуга може да включва DNS, идентичност, тайни, инфраструктура като код, API шлюзове, мониторинг, регистриране, ескалация към доставчици, комуникация с клиенти и преглед от гледна точка на защитата на личните данни.
Zenith Blueprint, във фазата Controls in Action, Step 19, формулира одиторското очакване за резервните копия:
Тествате ли резервните си копия?
Отговорът трябва да бъде „да, с доказателства“, като тези доказателства трябва да се свързват обратно с BIA.
Пакетът доказателства за BIA, готов за одит
Практическата програма за BIA трябва да създава кратък пакет доказателства, който може да се използва за одити, клиентска надлежна проверка, докладване към съвета и подобряване на устойчивостта.
| Елемент от доказателствата | Цел | Собственик |
|---|---|---|
| Методология на BIA и критерии за точкова оценка | Доказва, че процесът е повторяем и обективен | Ръководител по риска или устойчивостта |
| Регистър на критичните услуги | Идентифицира какво организацията трябва да защити и възстанови първо | Собственици на бизнес процеси |
| Карта на зависимостите | Свързва услугите с ИКТ активи, данни, доставчици, персонал и комунални услуги | ИТ, сигурност, операции |
| Записи за одобрение на MTD, RTO и RPO | Доказват, че целите за възстановяване са одобрени от бизнеса | Собственици на бизнес процеси и ръководство |
| Съпоставяне между BIA и регистъра на риска | Свързва анализа на въздействието с оценката на риска за сигурността | Собственик на риска |
| Съпоставяне между BIA и Декларация за приложимост | Свързва нуждите от непрекъснатост с контролите от ISO/IEC 27001:2022 Annex A | Мениджър на ISMS |
| Съпоставяне между BIA и графика за резервно копиране | Показва, че конфигурацията на резервните копия поддържа очакванията за RPO и RTO | ИТ операции |
| Преглед на непрекъснатостта при доставчиците | Потвърждава, че критичните доставчици имат ангажименти и контакти за възстановяване | Управление на доставчици |
| Записи за актуализация на BCP/DRP | Показват, че плановете отразяват текущите услуги и зависимости | Собственик на непрекъснатостта |
| Доклад от тест за възстановяване или превключване при отказ | Доказва, че способността за възстановяване е валидирана | ИТ, сигурност, собственик на бизнес процес |
| План за коригиращи действия | Проследява пропуските до приключване | Собственици на контроли |
| Доказателства от преглед от ръководството | Показват надзор и одобрение от съвета или ръководството | Изпълнителен спонсор |
Този пакет разказва последователна история. Той също прави устойчивостта измерима.
Следваща стъпка: превърнете BIA в доказателства за съответствие
Maria не се нуждае от по-голяма електронна таблица. Тя се нуждае от жива доказателствена верига.
Започнете с една критична услуга. Картографирайте нейните ИКТ активи, данни, хора, доставчици и комунални услуги. Одобрете MTD, RTO и RPO. Съгласувайте графика за резервно копиране. Проверете ангажиментите на доставчиците за възстановяване. Проведете един тест за възстановяване. Запишете пропуските. Актуализирайте плана за третиране на риска. Представете резултата на ръководството.
След това повторете.
Clarysec може да помогне за ускоряване на този процес чрез Политиката за непрекъснатост на дейността и аварийно възстановяване, Политиката за непрекъснатост на дейността и аварийно възстановяване - SME, Политиката за резервно копиране и възстановяване, Политиката за одит и мониторинг на съответствието, Zenith Blueprint и Zenith Controls.
Вашият BIA не трябва да бъде документ за рафта, създаден за одит. Той трябва да бъде оперативното доказателство, че най-важните ви услуги могат да преживеят прекъсване, да отговорят на клиентските и регулаторните очаквания и да се възстановят в границите, които ръководството ви действително е одобрило.
Ако организацията ви се подготвя за надзорен одит по ISO/IEC 27001:2022, клиентско уверение по NIS2, прегледи по DORA на ИКТ доставчици от трети страни или докладване за устойчивост на ниво съвет, започнете с това да направите BIA защитим. Изтеглете политиките на Clarysec за непрекъснатост и одит, прегледайте пътната карта за внедряване Zenith или заявете оценка на доказателствата за устойчивост, за да превърнете разпръснатите контроли в една история, готова за одит.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
