Компании из Казахстана, Узбекистана, Грузии и Кыргызстана всё чаще работают с европейскими банками, финтех-партнёрами и маркетплейсами — а значит, сталкиваются с требованиями DORA к цифровой устойчивости. Хорошая новость: чтобы подружиться с DORA, не нужно изобретать велосипед. Два практичных стандарта — ISO 22301 и ISO/IEC 27035 — закрывают большую часть ожиданий регулятора через понятные процессы и роли.
Что DORA ждёт от бизнеса простыми словами
DORA (Digital Operational Resilience Act) фокусируется не на бумажной безопасности, а на способности компании выдерживать ИТ-сбои и киберинциденты, быстро восстанавливаться и управлять рисками у подрядчиков. На практике обычно проверяют:
- есть ли управляемая модель ИКТ-рисков и непрерывности;
- умеете ли вы обнаруживать, классифицировать и разбирать инциденты;
- проводите ли тестирования и учения;
- контролируете ли критичных поставщиков (облака, аутсорс, дата-центры).
Если представить бизнес как авиакомпанию, то DORA хочет видеть не только ремень безопасности (политики), но и тренировки экипажа, чек-листы, чёрные ящики и регулярные проверки самолёта.
ISO 22301: скелет непрерывности бизнеса под требования DORA
ISO 22301 строит систему управления непрерывностью бизнеса (BCMS): от анализа рисков и BIA до планов восстановления и регулярных упражнений. Это напрямую помогает закрыть ожидания DORA по устойчивости и восстановлению сервисов.
Перед тем как внедрять процедуры, важно зафиксировать, что именно вы защищаете и сколько простоя допустимо. В ISO 22301 это формализуется через ключевые артефакты:
- BIA (Business Impact Analysis): какие процессы критичны, какие зависимости (люди, ИТ, поставщики), какие последствия простоя;
- RTO/RPO: целевое время восстановления и допустимая потеря данных;
- стратегии непрерывности: резервирование, альтернативные площадки, ручные процедуры;
- планы реагирования и восстановления: кто что делает, в какой последовательности, как коммуницировать клиентам и партнёрам;
- упражнения и тесты: чтобы план работал не только в презентации.
После этого у вас появляется управляемая база для обучение по управлению непрерывностью бизнеса — и для демонстрации зрелости перед партнёрами/аудиторами.
Подробнее о структуре и применении стандарта тут.
ISO/IEC 27035: порядок в реагировании на киберинциденты
Если ISO 22301 отвечает на вопрос «как жить, когда всё ломается», то ISO/IEC 27035 — «как правильно разрулить инцидент и сделать выводы». Для DORA это критично, потому что регулятор ожидает дисциплины: выявление → оценка → реагирование → восстановление → улучшения.
Стандарт помогает построить система управления инцидентами информационной безопасности, где нет хаоса из чатов и звонков «кому-то из ИТ», а есть роли, критерии и метрики. В такую систему обычно входят:
- правила обнаружения и регистрации событий (SOC/логирование/служба поддержки);
- классификация и приоритизация (что считать серьёзным инцидентом);
- сценарии реагирования (ransomware, утечка, компрометация учёток, DDoS);
- коммуникации и эскалации (руководство, юристы, PR, партнёры);
- post-incident review: причины, уроки, корректирующие действия.
И да, это то самое управление инцидентами ИБ, которое экономит деньги и нервы: чем быстрее вы локализуете проблему, тем меньше простой и репутационный ущерб.
Практика внедрения ISO/IEC 27035: подробнее.
Как ISO 22301 и ISO 27035 вместе обеспечивают соблюдение ключевых требований DORA в отношении операционной устойчивости
По отдельности стандарты сильны, а вместе дают связку «устойчивость + реагирование»:
- ISO 22301 задаёт критичные сервисы, допустимые простои и сценарии восстановления.
- ISO/IEC 27035 задаёт механизм реагирования на киберинциденты, который часто и является триггером планов непрерывности.
- DORA требует регулярной проверки готовности — оба стандарта опираются на упражнения, тесты и цикл улучшений.
После внедрения у компании появляется «единый язык» между бизнесом, ИТ и безопасностью — и меньше ситуаций, когда один отдел считает инцидент «мелочью», а другой уже теряет клиентов.
Быстрый план внедрения для компаний региона
Чтобы не утонуть в документах, начните прагматично. Команда Систем Менеджмент обычно рекомендует такой маршрут:
- провести короткий gap-анализ под DORA и текущие практики;
- описать критичные сервисы и зависимости (BIA, RTO/RPO);
- запустить процесс реагирования на инциденты: роли, классификация, плейбуки;
- связать реагирование с планами восстановления (кто и когда включает BCP/DR);
- провести учение (table-top) и зафиксировать улучшения.
Это даёт быстрый эффект: даже одно качественное учение часто выявляет узкие места лучше, чем месяцы обсуждений.
Если вы работаете с финансовыми партнёрами в ЕС или хотите заранее подготовиться к запросам клиентов и аудиторов, Систем Менеджмент поможет выстроить процессы, провести обучение и подготовить доказательную базу под проверку.