Управление на сигурното прехвърляне на файлове за одити по ISO 27001

Беше 16:47 във вторник, когато Аня, CISO на бързо растяща финтех компания, получи обаждане от онези, които променят програмата за сигурност.

Не беше рансъмуер. Не беше прекъсване на продукционна среда. Обаждаше се главният юрисконсулт, с овладяна спешност в гласа. Младши анализатор беше прикачил грешен файл към имейл по време на интензивен процес на надлежна проверка по сливане и придобиване (M&A). Файлът не беше безобидна презентация. Той съдържаше финансови прогнози, лични данни на клиенти и стратегическа интелектуална собственост. Предвиденият получател беше външен адвокат, но анализаторът беше въвел личен имейл адрес вместо одобрената пощенска кутия на адвокатската кантора.

Единствената причина дружеството да избегне съществен инцидент беше наскоро внедрено правило за предотвратяване на изтичане на данни (DLP). Имейлът беше блокиран, предупреждението беше задействано и екипът по сигурността ограничи събитието, преди файлът да напусне средата.

На следващата сутрин натискът се умножи. Потенциален клиент от сектора на финансовите услуги изпрати въпросник за надлежна проверка по DORA с искане за доказателства за сигурен обмен на ИКТ данни. Клиент поиска от правния екип да докаже, че всички експорти на лични данни към доставчици на поддръжка са криптирани, одобрени и журнализирани. След това звеното за обслужване съобщи, че ръководител на проект е използвал публична връзка за споделяне на файлове, защото порталът за управлявано прехвърляне на файлове бил „твърде бавен“.

Тази последователност от събития е реалността на управлението на сигурното прехвърляне на файлове през 2026 г. Въпросът вече не е дали организацията разполага със SFTP, платформа за управлявано прехвърляне на файлове, облачни инструменти за сътрудничество или криптиране на електронната поща. По-трудният въпрос е дали организацията може да докаже, че чувствителната информация е преминала през одобрени канали, с правилната класификация, оторизация, криптиране, ангажименти от доставчици, регистриране, мониторинг, срок за съхранение и тригери за реагиране при инциденти.

За CISO, мениджъри по съответствие, одитори и бизнес ръководители прехвърлянето на информация вече е въпрос на доказателства на ниво управителен съвет. GDPR изисква отчетност и подходящи технически и организационни мерки за лични данни. NIS2 изисква риск-базирани контроли за киберсигурност, управленски надзор, сигурни комуникации, криптография, контрол на достъпа, обработване на инциденти и сигурност на веригата на доставки. DORA изисква финансовите субекти и доставчиците на ИКТ услуги да демонстрират оперативна устойчивост, управление на трети страни в областта на ИКТ, управление на инциденти и договорен контрол върху критични ИКТ услуги.

ISO/IEC 27001:2022 предоставя гръбнака на системата за управление. ISO/IEC 27002:2022 предоставя езика на контролите. Clarysec превръща този език в оперативни доказателства чрез Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, библиотеката с политики на Clarysec и Zenith Controls: The Cross-Compliance Guide Zenith Controls.

Защо управлението на прехвърлянето на файлове се проваля още преди началото на одита

Повечето организации не се провалят, защото им липсва инструмент за сигурно прехвърляне. Те се провалят, защото имат твърде много пътища за прехвърляне и нямат единен модел на управление.

Типичната среда включва портали за управлявано прехвърляне на файлове, SFTP сървъри, прикачени файлове в електронна поща, споделени връзки в Microsoft 365 или Google Workspace, експорти чрез приложно-програмни интерфейси (API), клиентски портали, сайтове на доставчици за качване на файлове, преносими носители и приложения за съобщения, използвани, когато някой е под натиск. От одитна гледна точка всеки канал повдига едни и същи въпроси:

• Каква информация е преместена?
• Каква класификация е приложена?
• Кой е одобрил прехвърлянето?
• Получателят бил ли е оторизиран?
• Било ли е наложено криптиране?
• Бил ли е достъпът журнализиран и наблюдаван?
• Изисквали ли са договорите с доставчици еквивалентна защита?
• Приложени ли са правилата за срокове за съхранение и изтриване?
• Щеше ли инцидент да бъде открит и ескалиран?

Zenith Blueprint, във фазата Controls in Action, Step 22, Организационни контроли, Контрол 5.14, улавя оперативната реалност:

В свързана организация информацията не стои на едно място. Тя се движи между хора, отдели, системи, устройства, партньори и външни субекти. Понякога се движи през защитени тунели с пълна проследимост. Друг път се движи чрез WhatsApp, личен имейл или бързо копиране и поставяне в споделен Google Doc. Контрол 5.14 съществува, за да управлява този поток, като гарантира, че прехвърлянето на информация е сигурно, целенасочено и съобразено с нейната класификация и служебна цел.

Това е същината на управлението на сигурния обмен на информация. Одиторите не питат само: „Използвате ли криптиране?“ Те питат дали движението на информацията е целенасочено, контролирано, съобразено с класификацията и подкрепено с доказателства.

Започнете с обхвата на ISMS, риска и отчетността

Програмата за сигурно прехвърляне на файлове не трябва да започва с избор на инструмент. Тя трябва да започва с обхвата по ISO/IEC 27001:2022, изискванията на заинтересованите страни, оценката на риска и управленската отчетност.

За доставчик на SaaS, финтех компания или регулиран доставчик обхватът на ISMS трябва да включва системите, доставчиците, местоположенията и процесите, през които се движи чувствителна информация. Това обичайно означава експорти на клиентски данни, прикачени файлове към случаи за поддръжка, аналитични извлечения, пакети за отстраняване на проблеми към доставчици, резервни копия, прехвърляни към облачни хранилища, обмен между HR и финанси, стаи за данни за M&A, клиентски портали за доказателства и API-към-API прехвърляния с обработващи лични данни или подизпълнители по обработване.

ISO/IEC 27001:2022 изисква повторяем процес за оценка на риска за информационната сигурност, третиране на риска, Декларация за приложимост и приемане на остатъчния риск от собственик на риска. На практика това се превръща в регистър на риска при прехвърляне, а не в теоретична електронна таблица.

Тук и отчетността на изпълнителното ръководство става практическа. ISO/IEC 27001:2022 изисква висшето ръководство да съгласува информационната сигурност със стратегическата посока, да възлага роли, да осигурява ресурси и да преглежда резултатността. NIS2 подсилва отчетността на управителния орган за мерките за управление на риска в киберсигурността. DORA прави същото за финансовите субекти, като превръща управлението на ИКТ риска и защитата на поверителността, цялостността, автентичността и наличността в управленска отговорност.

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

Картографиране на контролите по ISO/IEC 27002:2022 за сигурно прехвърляне

Контрол 5.14 Прехвърляне на информация по ISO/IEC 27002:2022 е основният контрол, но не може да работи самостоятелно. Чрез Zenith Controls Clarysec картографира сигурното прехвърляне на информация основно към контрол 5.14, силно подкрепен от контрол 8.12 Предотвратяване на изтичане на данни и контрол 8.24 Използване на криптография.

Контрол 5.14 отговаря на управленския въпрос: как може информацията да се прехвърля вътрешно и външно? Контрол 8.12 отговаря на въпроса за изтичането: как предотвратяваме напускането на чувствителни данни през неоторизирани канали? Контрол 8.24 отговаря на въпроса за защитата: как се избира, прилага и управлява криптографията за данни при пренос, данни в покой и, когато е приложимо, данни при използване?

Свързаните контроли създават средата, готова за одит:

Zenith Blueprint, във фазата Controls in Action, Step 22, обяснява ясно очакването за прилагане:

На практика това означава не само да се дефинира „какво е разрешено“, но и да се изградят технически и поведенчески механизми за прилагане на тези очаквания. Например:

✓ Ако „Поверителна“ информация няма право да напуска дружеството без криптиране, тогава системите за електронна поща трябва да прилагат политики за криптиране или да блокират външното изпращане. ✓ Ако прехвърлянията на файлове към външни доставчици са разрешени само чрез защитени портали, тогава връзки към отворени облачни дискове (като публични Dropbox папки) трябва активно да се предотвратяват. ✓ Ако лични данни се прехвърлят през граници, методът трябва да съответства на задълженията за поверителност и правните задължения, а не само на вътрешните предпочитания.

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

Слой на политиките: превръщане на правилата в приложими контроли

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

Политиката на Clarysec за SME Third-Party and Supplier Security Policy Политика за сигурност на трети страни и доставчици - SME посочва в клауза 6.2.3:

Всички данни, споделяни с доставчици, трябва да бъдат защитени чрез криптиране и предавани чрез сигурни протоколи (напр. HTTPS, SFTP).

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

Политиката за SME Data Classification and Labeling Policy Политика за класификация и етикетиране на данни - SME, раздел „Изисквания за управление“, 5.2.3, добавя:

Външното споделяне трябва да бъде изрично оторизирано и журнализирано.

За корпоративни среди Data Classification and Labeling Policy Политика за класификация и етикетиране на данни, клауза 6.3.1, разширява правилото:

Всяко боравене с данни, предаване, достъп, съхранение и унищожаване на информация трябва да съответства на нейното ниво на класификация. Като минимум:

За по-чувствителни класификации клауза 6.3.1.3.2 посочва:

Трябва да бъдат криптирани при пренос и в покой

Корпоративната Remote Work Policy Политика за дистанционна работа свързва това с ежедневното поведение, като изисква от служителите да:

Използват само одобрени решения за споделяне на файлове (напр. M365, Google Workspace с контроли за предотвратяване на изтичане на данни (DLP))

Това е важно, защото много инциденти при прехвърляне възникват при дистанционна работа, правни преговори, търговска надлежна проверка, спешна поддръжка и изпълнение на проекти.

Политиката на Clarysec за SME Cryptographic Controls Policy Политика за криптографски контроли - SME, раздел „Обхват“, клауза 2.2, потвърждава, че управлението на криптирането обхваща повече от бази данни:

Тази политика обхваща данни в покой, данни при пренос и данни при използване. Тя също така управлява криптирането, използвано за резервни копия, електронна поща, външни прехвърляния на данни и публично достъпни уебсайтове.

Политиката за SME Logging and Monitoring Policy Политика за регистриране и мониторинг - SME, „Изисквания за управление“, клауза 5.4.3, идентифицира:

Журнали за достъп: достъп до файлове (особено за чувствителни или лични данни), промени в разрешенията, използване на споделени ресурси

За корпоративни среди Third party and supplier security policy Политика за сигурност на трети страни и доставчици, клауза 6.3.2, изисква:

Всеки достъп на трети страни трябва да бъде журнализиран и наблюдаван и, когато е приложимо, сегментиран чрез бастионен сървър, VPN или Zero Trust шлюзове.

Корпоративната Logging and Monitoring Policy Политика за регистриране и мониторинг включва също мониторинг за:

Външни комуникации и тригери от правила на защитната стена

Накрая, политиката за SME Legal and Regulatory Compliance Policy-sme Политика за правно и регулаторно съответствие - SME предоставя специфична за поверителността предпазна мярка:

Лични данни не трябва да се изпращат по електронна поща или по друг начин да се прехвърлят без криптиране или подходящи предпазни мерки.

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

Един модел на контрол за GDPR, NIS2 и DORA

Управлението на сигурното прехвърляне на файлове е силен пример защо съответствието трябва да бъде интегрирано, а не дублирано.

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

NIS2 изисква мерки за управление на риска, като обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване и поддръжка, оценка на ефективността, киберхигиена, обучение, криптография, контрол на достъпа, управление на активите, MFA когато е приложимо и сигурни комуникации. Тя определя и очаквания за докладване на значими инциденти, включително ранно предупреждение в рамките на 24 часа, уведомление в рамките на 72 часа и окончателен доклад в рамките на един месец.

DORA се прилага от 17 януари 2025 г. за финансови субекти и съответните доставчици на ИКТ услуги от трети страни. Той формализира управлението на ИКТ риска, класификацията на инциденти, тестването на цифровата оперативна устойчивост и ИКТ риска от трети страни. Платформи за прехвърляне на файлове, облачни стаи за данни, SFTP хостинг, портали за обмен на документи и платформи за поддръжка могат да станат релевантни, когато поддържат критични или важни функции.

Стойността на Zenith Controls е, че едни и същи доказателства могат да бъдат индексирани веднъж и картографирани към ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 и COBIT 2019. Ръководството не създава отделни „Zenith контроли“. То помага да се картографират признати контроли и доказателства между рамки.

Изградете пакет с доказателства за сигурно прехвърляне за пет дни

Когато наближава клиентски одит, сертификационен одит или преглед пред регулатор, най-бързият път е да се изгради фокусиран пакет с доказателства около реалната дейност по прехвърляне.

Ден 1: Създайте регистър на прехвърлянията

Избройте периодичните и високорисковите прехвърляния, включително системни експорти, потоци към доставчици, клиентски портали, работни потоци по електронна поща, модели на облачно споделяне, приложно-програмни интерфейси (API) и преносими носители. Минималните полета трябва да включват име на прехвърлянето, собственик от бизнеса, класификация на данните, индикатор за лични данни, изходна система, получаваща страна, метод на прехвърляне, метод на криптиране, честота, изискване за одобрение, източник на журнали, правило за срок на съхранение, препратка към договор с доставчик и собственик на инцидента.

Ден 2: Картографирайте одобрените методи към класификацията

Използвайте политиките за класификация на Clarysec като източник на правилата. Определете разрешените методи по ниво на класификация.

Ден 3: Съберете доказателства за техническото прилагане

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

Ден 4: Тествайте едно прехвърляне от край до край

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

Ден 5: Добавете тригери за инциденти и връзки към докладването

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

След това картографирайте всеки тригер към критериите за вземане на решение по GDPR, NIS2 и DORA. По GDPR оценете дали лични данни са били неправомерно разкрити, достъпени, изменени, загубени или унищожени. По NIS2 оценете оперативното прекъсване, финансовата загуба и вредите за други лица. По DORA вземете предвид засегнатите клиенти, транзакциите, продължителността, географския обхват, загубата на данни, критичността на услугата и икономическото въздействие.

Споразуменията с доставчици са половината контрол

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

Zenith Blueprint, във фазата Controls in Action, Step 23, Организационни контроли, Контрол 5.20, описва темите в споразуменията с доставчици, които имат значение:

Ключовите области, които обичайно се адресират в споразуменията с доставчици, включват:

✓ Задължения за поверителност, включително обхват, срок и ограничения за разкриване към трети страни; ✓ Отговорности по контрол на достъпа, като кой може да има достъп до вашите данни, как се управляват удостоверителните данни и какъв мониторинг е въведен; ✓ Технически и организационни мерки за защита на данните, криптиране, сигурно предаване, резервни копия и ангажименти за наличност; ✓ Срокове и протоколи за докладване на инциденти, често с дефинирани срокове (напр. „уведомяване в рамките на 24 часа“); ✓ Права на одит, включително честота, обхват и достъп до релевантни доказателства (напр. доклади от тестове за проникване, SoA, сертификации); ✓ Контроли за подизпълнители, изискващи от доставчика да прехвърли еквивалентни задължения за сигурност към своите последващи партньори; ✓ Разпоредби при прекратяване на договора, като връщане или унищожаване на данни, възстановяване на активи и деактивиране на акаунти.

Това е съгласувано с контролите по ISO/IEC 27002:2022 за доставчици, включително 5.19 Информационна сигурност във взаимоотношенията с доставчици, 5.20 Адресиране на информационната сигурност в споразуменията с доставчици, 5.21 Управление на информационната сигурност във веригата за доставки на ИКТ, 5.22 Мониторинг, преглед и управление на промените в услугите на доставчици и 5.23 Информационна сигурност при използване на облачни услуги.

За DORA обменът с доставчици се свързва и с управлението на ИКТ риска от трети страни, регистри на споразуменията за ИКТ услуги, договорни клаузи, права на одит и инспекция, съдействие при инциденти и стратегии за изход. За NIS2 той се свързва със сигурността на веригата на доставки и специфичните за доставчика уязвимости.

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

Не пренебрегвайте физическите носители и офлайн прехвърлянията

Повечето обсъждания за управление на прехвърлянето на файлове се фокусират върху облачни връзки и MFT платформи, но одиторите все още питат за USB устройства, преносими дискове, резервни ленти и носители, изпращани с куриер. Те често се използват при миграции, съдебно производство, форензичен анализ, поддръжка на OT или резервни копия извън обекта.

Zenith Blueprint, във фазата Controls in Action, Step 18, Physical Controls II, Media Management, Контрол 7.10, посочва:

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

За готовност за одит третирайте физическите носители като всеки друг канал за прехвърляне. Пакетът с доказателства трябва да включва инвентар на носителите, запис за криптиране, журнал на веригата на съхранение, проследяване от куриер, потвърждение от получателя, запис за връщане или сертификат за унищожаване.

Как одиторите тестват управлението на сигурното прехвърляне на файлове

Зряла програма за сигурно прехвърляне трябва да издържа на различни одитни перспективи. Едни и същи доказателства могат да бъдат интерпретирани различно от одитор по ISO/IEC 27001:2022, оценител по NIST CSF, проверяващ по COBIT 2019, проверяващ по DORA или одитор по поверителността, фокусиран върху GDPR.

Изводът е прост: не създавайте дублиращи се папки с доказателства за всяка регулация. Създайте един модел за доказателства за сигурно прехвърляне, след което го картографирайте към съответните задължения.

Често срещани констатации при одити на сигурно прехвърляне

В SaaS, финтех, професионални услуги и регулирани доставчици Clarysec многократно вижда едни и същи слабости:

• SFTP акаунти се споделят между персонал на доставчика
• Служебните акаунти никога не изтичат
• Външното споделяне е активирано глобално в облачните инструменти за сътрудничество
• Публични връзки са разрешени за поверителни файлове
• DLP съществува, но не е настроено спрямо класификациите на данните
• Криптирането на електронна поща е незадължително и се управлява от потребителя
• Договорите с доставчици споменават поверителност, но не и доказателства за сигурно прехвърляне
• Журналите се събират, но не се преглеждат
• Одобренията за прехвърляне остават в чат съобщения вместо в системи за билети
• Срокът за съхранение на качвания в клиентски портали е неясен
• Физическите носители се третират като изключение извън ISMS
• Наръчниците за реагиране при инциденти не включват сценарии за погрешно насочено прехвърляне на файлове или компрометирана MFT платформа

Всяка слабост създава регулаторно напрежение. По GDPR тя отслабва отчетността и защитимостта при нарушение. По NIS2 тя подкопава управлението на риска и обработването на инциденти. По DORA тя застрашава управлението на ИКТ риска от трети страни и доказателствата за оперативна устойчивост.

Контролен списък за управление на сигурното прехвърляне на файлове през 2026 г.

Използвайте този контролен списък преди следващия си одит по ISO/IEC 27001:2022, клиентски преглед на сигурността, оценка на готовността за DORA, брифинг пред управителния съвет по NIS2 или искане за доказателства по GDPR.

• Имаме ли пълен регистър на периодичните прехвърляния на чувствителна информация?
• Картографирани ли са методите за прехвърляне към нивата на класификация?
• Външните прехвърляния изрично оторизирани и журнализирани ли са?
• Управляват ли се последователно MFT, SFTP, защитени портали, приложно-програмни интерфейси (API), електронна поща и облачни връзки?
• Налага ли се криптиране при прехвърляния на поверителни, ограничени и лични данни?
• Контролират ли се прикачените файлове в електронна поща чрез криптиране, DLP или одобрени алтернативи?
• Записани ли са задълженията на доставчиците при прехвърляне в договорите?
• Достъпите на трети страни журнализират ли се, наблюдават ли се и преглеждат ли се периодично?
• Журнализират ли се достъпът до файлове, промените в разрешенията и използването на споделени ресурси?
• Съхраняват ли се журналите за прехвърляне достатъчно дълго за разследвания и одити?
• Интегрирани ли са аномалните прехвърляния в реагирането при инциденти?
• Можем ли да класифицираме дали инцидент при прехвърляне задейства докладване по GDPR, NIS2 или DORA?
• Тестваме ли контролите за прехвърляне чрез вътрешен одит или самооценка на контролите?
• Имаме ли доказателства за преглед от ръководството и приемане от собственик на риска?

Ако отговорът на някой от тези въпроси е неясен, проблемът вероятно не е технологията. Проблемът е управлението.

От реакция към устойчивост, готова за одит

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

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

Clarysec помага на организациите да изградят този модел на доказателства чрез Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls и шаблони за политики, съгласувани с ISO/IEC 27001:2022, като Политика за класификация и етикетиране на данни, Политика за сигурност на трети страни и доставчици, Политика за криптографски контроли - SME, Политика за регистриране и мониторинг - SME и Политика за дистанционна работа.

Ако се подготвяте за сертификация по ISO/IEC 27001:2022, готовност за DORA, управленско докладване по NIS2 или искане за доказателства по GDPR, започнете с един въпрос: можете ли да докажете къде е отишла вашата чувствителна информация през миналия месец?

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