Що таке політика інформаційної безпеки і навіщо вона
Коли компанія вперше стикається з ISO/IEC 27001, один із перших документів, який від неї просять, — це політика інформаційної безпеки. І тут багато хто робить однакову помилку: гуглить чужу політику, копіює її PDF, міняє назву фірми у шапці й вважає, що справу зроблено. Аудитор бачить такі документи наскрізь за пару хвилин.
Політика інформаційної безпеки — це короткий документ, у якому керівництво компанії заявляє, що і як воно захищає, і задає правила гри для всіх працівників. Не інструкція з паролів і не технічний регламент, а верхньорівнева заява про наміри: які дані для нас критичні, хто за них відповідає, яких принципів ми дотримуємося. З неї починається вся система управління інформаційною безпекою, тож від того, наскільки чесно й точно вона написана, залежить решта.
У стандарті ISO/IEC 27001 вимоги до цього документа зібрані в пункті 5.2 «Політика». Далі розберемо, що саме він вимагає, яка структура працює на практиці, і покажемо скелет по розділах, який ви зможете адаптувати під свою компанію замість того, щоб копіювати чужий. А якщо потрібен ширший контекст, повний посібник з ISO/IEC 27001 проводить через увесь шлях до сертифікації.
Політика інформаційної безпеки за ISO/IEC 27001: пункт 5.2
Пункт 5.2 стандарту — це не рекомендація, а обов'язкова вимога з основної частини ISO/IEC 27001 (розділи 4–10). Її не можна виключити чи обґрунтовано пропустити, як окремі контролі з Annex A. Причому відповідальність тут персональна: політику встановлює саме вище керівництво, а не айтівідділ і не запрошений консультант. Це принциповий момент. Підпис директора під політикою означає, що безпека має підтримку згори, без якої вона просто не працює.
Стандарт формулює вимоги у двох частинах. Перші чотири пункти (a–d) стосуються змісту документа, останні три (e–g) — того, чи він живий: можна ідеально сформулювати принципи, але якщо політику ніхто не бачив, вимога не виконана. Саме на пунктах e–g найчастіше сиплються компанії, що поставилися до політики формально. Ось повний перелік простими словами.
| Вимога пункту 5.2 | Що це означає на практиці |
|---|---|
| a) відповідає призначенню організації | Політика написана під вашу компанію, а не скопійована: відображає ваш бізнес, ваші дані й ваші ризики |
| b) містить цілі або задає рамку для них | Політика або прямо перелічує цілі безпеки, або встановлює, як їх ставити (зв'язок із пунктом 6.2) |
| c) містить зобов'язання виконувати вимоги | Компанія зобов'язується дотримуватися застосовних вимог — законів, договорів, регуляторних норм |
| d) містить зобов'язання до постійного покращення | Політика декларує, що система не застигає, а вдосконалюється з часом |
| e) доступна як задокументована інформація | Політика існує у вигляді документа — затвердженого, з версією і датою |
| f) доведена до персоналу всередині компанії | Про політику знають і мають до неї доступ працівники, а не лише керівництво |
| g) доступна зацікавленим сторонам, за потреби | Клієнти, партнери чи регулятори можуть отримати політику, коли це доречно |
Яка мета політики інформаційної безпеки
Питання «навіщо взагалі ця політика» виникає майже завжди, і відповідь на нього визначає, вийде документ живим чи мертвим. Метою політики інформаційної безпеки є задати єдиний напрям для всіх рішень щодо захисту інформації в компанії й показати, що керівництво цей напрям підтримує. Простіше кажучи, це компас: коли працівник чи менеджер не знає, як діяти в неоднозначній ситуації, він звіряється з політикою.
Якщо розкласти детальніше, метою політики інформаційної безпеки є:
- задати напрям і принципи — що для компанії означає захист інформації і яких правил вона дотримується;
- закріпити відповідальність керівництва — політику затверджує топменеджмент, тож безпека перестає бути «проблемою айтівідділу»;
- дати рамку для цілей — з політики випливають конкретні, вимірювані цілі інформаційної безпеки;
- пов'язати безпеку із законами й договорами — через зобов'язання виконувати застосовні вимоги;
- запустити механізм покращення — політика фіксує, що система переглядається й розвивається.
Зверніть увагу: жодна з цих цілей не про технології. Політика не каже «встановіть антивірус X». Вона задає рівень, нижче якого компанія не опускається, а конкретні заходи вже підбираються під ризики.
Одна політика чи багато: пункт 5.2 і топікові політики
Тут ховається плутанина, на якій спотикаються майже всі новачки. У стандарті слово «політика» трапляється у двох різних місцях, і це не одне й те саме.
Пункт 5.2 вимагає одну верхньорівневу політику інформаційної безпеки — той самий короткий документ від керівництва, про який ідеться в цій статті. А контроль 5.1 з Annex A («Політики інформаційної безпеки», у множині) — це вже набір топікових, деталізованих політик під конкретні теми: політика контролю доступу, політика використання паролів, політика роботи з постачальниками, політика чистого столу.
Співвідношення просте: верхньорівнева політика (5.2) задає загальний напрям, а топікові політики (Annex A 5.1) розкривають його в деталях під окремі напрями. Одна «парасолька» і багато конкретних документів під нею. Плутати їх не варто: аудитор чекає обидва рівні, але верхньорівнева політика — одна, і вона має лишатися стислою.
Пункт 5.2 і Annex A 5.1: не сплутайте два рівні політик
Найчастіша помилка — намагатися вмістити в один документ і загальні принципи, і всі детальні правила. Верхньорівнева політика за пунктом 5.2 має лишатися короткою: дві-три сторінки, які прочитає й зрозуміє будь-який працівник. Усе технічне й детальне виносять в окремі топікові політики (контроль доступу, криптографія, використання активів), що відповідають контролю 5.1 з Annex A. Терміни цієї галузі, зокрема саме визначення «політики», формалізовано в стандарті-словнику ISO/IEC 27000.
Структура політики інформаційної безпеки: скелет по розділах
Тепер найпрактичніше — з чого фізично складається документ. Стандарт не диктує жорсткого шаблону: він каже, що політика має містити (пункти a–g), але не як її форматувати. За роки практики склалася структура, яка закриває всі вимоги 5.2 і при цьому лишається читабельною.
Вісім розділів політики інформаційної безпеки
Ось скелет, який можна взяти за основу й наповнити своїм змістом. Це не файл для завантаження, а структура: ви просто відтворюєте ці розділи у власному документі й пишете про свою компанію, а не про абстрактну «організацію».
| Розділ політики | Що в ньому написати | Вимога 5.2 |
|---|---|---|
| 1. Призначення й сфера дії | Навіщо документ і на кого поширюється: підрозділи, працівники, підрядники, системи | a |
| 2. Принципи безпеки | Що компанія захищає — конфіденційність, цілісність, доступність — і базові принципи | a |
| 3. Цілі інформаційної безпеки | Самі цілі або рамка для їх постановки; зв'язок із пунктом 6.2 | b |
| 4. Ролі та відповідальність | Хто відповідає: керівництво, власник СУІБ, працівники. Персональна, а не абстрактна | a |
| 5. Зобов'язання щодо вимог | Дотримання законів, договорів, регуляторних норм | c |
| 6. Управління ризиками | Посилання на процес оцінки й обробки ризиків — як компанія вирішує, що захищати | b |
| 7. Зобов'язання до покращення | Заява, що система переглядається й вдосконалюється | d |
| 8. Затвердження й перегляд | Хто затвердив, дата, версія, періодичність перегляду. Підпис керівництва обов'язковий | e |
Чого у верхньорівневій політиці бути не повинно
Вісім розділів — це орієнтир, а не догма. Маленька IT-компанія вмістить усе на двох сторінках, велика фінустанова розгорне до п'яти-шести. Головне правило: кожен розділ має нести сенс. Якщо ви не можете пояснити, навіщо в політиці той чи інший абзац, — його там бути не повинно.
І навпаки, є речі, яким у верхньорівневій політиці не місце. Конкретні налаштування паролів, списки дозволених програм, покрокові процедури реагування — усе це живе в топікових політиках і регламентах. Якщо запхати їх у головний документ, він розбухне до непридатного стану, а міняти його доведеться щоразу, коли зміниться дрібна технічна деталь. Політика має бути стабільною; деталі нехай змінюються нижче.
Коротка політика працює краще за товсту
Спокуса написати політику на двадцять сторінок, щоб «виглядало серйозно», грає проти вас. Що довший документ, то менше шансів, що його хтось прочитає, а вимога 5.2(f) якраз про те, щоб політику знали працівники. Хороша верхньорівнева політика вміщується на двох-трьох сторінках і читається за п'ять хвилин. Деталі — у топікових політиках і процедурах. Аудитор радше похвалить стислий документ, який люди справді розуміють, ніж товстий том, у який ніхто не заглядав після затвердження.
Від політики до сертифіката ISO/IEC 27001
Політика — це перший документ вашої системи управління інформаційною безпекою, але далеко не останній крок. Якщо ви готуєтеся до сертифікації, ми проведемо вас через оцінку ризиків, вибір контролів і аудит — від першої діагностики до сертифіката, який визнають клієнти в ЄС і США.
Підготовка до сертифікації ISO/IEC 27001Політика й управління ризиками інформаційної безпеки
Політика не висить у повітрі — вона спирається на управління ризиками інформаційної безпеки, і це зв'язок, який аудитори перевіряють особливо прискіпливо. Логіка така: спершу ви оцінюєте, що може піти не так із вашими даними, потім вирішуєте, що з цим робити, і лише тоді політика закріплює загальні принципи цих рішень.
Тому в політиці має бути розділ, який посилається на процес управління ризиками: хто його проводить, як часто, за якою методикою. Не сам аналіз ризиків — він живе в окремих документах, — а згадка про те, що компанія системно ним займається. Це і є практичне втілення вимоги 5.2(b): політика задає рамку, а конкретні цілі й заходи випливають з оцінки ризиків.
Зв'язка виглядає так: політика декларує намір керувати ризиками, оцінка ризиків показує, де саме загрози, обробка ризиків обирає контролі з Annex A, а Декларація застосовності фіксує вибір. Якщо в політиці немає й згадки про ризики, вона відірвана від реальної системи, і це видно одразу. Докладніше про те, як влаштована вся ця система, — у посібнику із сертифікації СУІБ.
Як написати політику інформаційної безпеки крок за кроком
Зберемо все в порядок дій. Ось як виглядає написання політики від чистого аркуша до підписаного документа.
- Зберіть контекст. Перш ніж писати, з'ясуйте, які дані компанія обробляє, чого вимагають клієнти й закони, де межі майбутньої системи. Без цього політика вийде абстрактною.
- Проведіть попередню оцінку ризиків. Навіть груба картина загроз підкаже, які принципи варто закріпити в політиці.
- Напишіть чернетку за скелетом вище. Вісім розділів, кожен — кілька абзаців простою мовою. Пишіть так, щоб зрозумів не лише безпечник, а й бухгалтер.
- Погодьте з керівництвом. Це не формальність: топменеджмент має не просто підписати, а зрозуміти й підтримати те, під чим підписується.
- Затвердьте, датуйте, версіонуйте. Політика без дати й версії — це чернетка. Поставте номер версії, дату затвердження і хто затвердив.
- Доведіть до персоналу. Розішліть, викладіть у внутрішній системі, додайте в онбординг новачків. Вимога 5.2(f) вважається виконаною тоді, коли люди про політику знають.
- Заплануйте перегляд. Раз на рік або після суттєвих змін, щоб політика не застаріла разом із компанією.
На практиці найбільше часу з'їдають не формулювання, а погодження з керівництвом і чесна оцінка того, що компанія реально робить, а не декларує. Якщо ви робите це вперше, попередня оцінка готовності економить тижні: вона показує, які принципи ви можете чесно закріпити в політиці вже зараз, а які поки що будуть фікцією.
Типові помилки, через які політику завертають
Помилки в політиках повторюються з компанії в компанію, і майже всі вони про формальний підхід. Ось ті, що трапляються найчастіше.
Перша й найгрубіша — скопіювати чужу політику. У відкритому доступі лежать політики банків і великих компаній, тож спокуса взяти готове велика. Але чужий документ описує чужі ризики, чужу структуру й чужі системи, і під час аудиту це випливає з перших питань. Друга — політика, відірвана від реальності: у ній написано «доступ надається за принципом мінімальних привілеїв», а насправді у всіх адмінські права. Аудитор перевіряє не текст, а відповідність тексту життю.
Третя помилка — завелика деталізація, коли у верхньорівневу політику намагаються запхати паролі, налаштування й процедури. Для цього є топікові політики. Четверта — відсутність підпису й дати: документ без затвердження керівництвом формально не виконує вимогу 5.2. І п'ята — «написали й забули»: політику затвердили три роки тому, компанія змінилася до невпізнаваності, а документ той самий.
Скопійована політика — найшвидший шлях до зауваження
Найпоширеніша причина, чому політику завертають на аудиті, — вона очевидно не про цю компанію. Формулювання про «дата-центри» у фірми, що вся в хмарі, згадки про відділи, яких не існує, принципи, які ніхто не виконує. Політику не оцінюють за красою мови — її звіряють з тим, як компанія працює насправді. Тому чесний документ на дві сторінки, що відображає ваші реальні процеси, завжди сильніший за красивий чужий шаблон. Пишіть про себе, а не про абстрактну «організацію».
Як Ekontrol допомагає з політикою і сертифікацією
На практиці політика рідко буває самоціллю — компанія приходить по неї, бо готується до сертифікації або відповідає на запит клієнта. Тому ми не пишемо політику окремо від системи: Ekontrol супроводжує впровадження СУІБ як єдиний напрям, і політика народжується природно з оцінки вашого контексту й ризиків, а не з шаблону.
Починаємо з розбору ситуації: які дані ви обробляєте, чого вимагають контракти, де ваш головний ризик. Далі — попередня діагностика, яка показує розрив між тим, що є, і тим, чого хоче стандарт, а вже потім побудова політики й решти документів під ваші реальні процеси. Наші послуги з підготовки до сертифікації охоплюють увесь шлях — від першої діагностики до сертифікаційного аудиту. Для IT- і SaaS-компаній, що працюють із клієнтами з ЄС і США, ми окремо готуємо тендерну документацію, де політика лише один з елементів.
Якщо не знаєте, з чого почати, є два прості варіанти: прочитати повний посібник з ISO/IEC 27001, щоб побачити всю картину, або одразу зв'язатися з командою Ekontrol й обговорити вашу ситуацію. Ми працюємо як партнер Bureau Veritas в Україні з 2014 року.
Потрібна консультація щодо сертифікації?
Безкоштовна консультаціяЗміст сторінки
- Що таке політика інформаційної безпеки і навіщо вона
- Політика інформаційної безпеки за ISO/IEC 27001: пункт 5.2
- Яка мета політики інформаційної безпеки
- Одна політика чи багато: пункт 5.2 і топікові політики
- Структура політики інформаційної безпеки: скелет по розділах
- Політика й управління ризиками інформаційної безпеки
- Як написати політику інформаційної безпеки крок за кроком
- Типові помилки, через які політику завертають
- Як Ekontrol допомагає з політикою і сертифікацією
- FAQ — питання про політику інформаційної безпеки
Що таке політика інформаційної безпеки і навіщо вона
Коли компанія вперше стикається з ISO/IEC 27001, один із перших документів, який від неї просять, — це політика інформаційної безпеки. І тут багато хто робить однакову помилку: гуглить чужу політику, копіює її PDF, міняє назву фірми у шапці й вважає, що справу зроблено. Аудитор бачить такі документи наскрізь за пару хвилин.
Політика інформаційної безпеки — це короткий документ, у якому керівництво компанії заявляє, що і як воно захищає, і задає правила гри для всіх працівників. Не інструкція з паролів і не технічний регламент, а верхньорівнева заява про наміри: які дані для нас критичні, хто за них відповідає, яких принципів ми дотримуємося. З неї починається вся система управління інформаційною безпекою, тож від того, наскільки чесно й точно вона написана, залежить решта.
У стандарті ISO/IEC 27001 вимоги до цього документа зібрані в пункті 5.2 «Політика». Далі розберемо, що саме він вимагає, яка структура працює на практиці, і покажемо скелет по розділах, який ви зможете адаптувати під свою компанію замість того, щоб копіювати чужий. А якщо потрібен ширший контекст, повний посібник з ISO/IEC 27001 проводить через увесь шлях до сертифікації.
Політика інформаційної безпеки за ISO/IEC 27001: пункт 5.2
Пункт 5.2 стандарту — це не рекомендація, а обов'язкова вимога з основної частини ISO/IEC 27001 (розділи 4–10). Її не можна виключити чи обґрунтовано пропустити, як окремі контролі з Annex A. Причому відповідальність тут персональна: політику встановлює саме вище керівництво, а не айтівідділ і не запрошений консультант. Це принциповий момент. Підпис директора під політикою означає, що безпека має підтримку згори, без якої вона просто не працює.
Стандарт формулює вимоги у двох частинах. Перші чотири пункти (a–d) стосуються змісту документа, останні три (e–g) — того, чи він живий: можна ідеально сформулювати принципи, але якщо політику ніхто не бачив, вимога не виконана. Саме на пунктах e–g найчастіше сиплються компанії, що поставилися до політики формально. Ось повний перелік простими словами.
| Вимога пункту 5.2 | Що це означає на практиці |
|---|---|
| a) відповідає призначенню організації | Політика написана під вашу компанію, а не скопійована: відображає ваш бізнес, ваші дані й ваші ризики |
| b) містить цілі або задає рамку для них | Політика або прямо перелічує цілі безпеки, або встановлює, як їх ставити (зв'язок із пунктом 6.2) |
| c) містить зобов'язання виконувати вимоги | Компанія зобов'язується дотримуватися застосовних вимог — законів, договорів, регуляторних норм |
| d) містить зобов'язання до постійного покращення | Політика декларує, що система не застигає, а вдосконалюється з часом |
| e) доступна як задокументована інформація | Політика існує у вигляді документа — затвердженого, з версією і датою |
| f) доведена до персоналу всередині компанії | Про політику знають і мають до неї доступ працівники, а не лише керівництво |
| g) доступна зацікавленим сторонам, за потреби | Клієнти, партнери чи регулятори можуть отримати політику, коли це доречно |
Яка мета політики інформаційної безпеки
Питання «навіщо взагалі ця політика» виникає майже завжди, і відповідь на нього визначає, вийде документ живим чи мертвим. Метою політики інформаційної безпеки є задати єдиний напрям для всіх рішень щодо захисту інформації в компанії й показати, що керівництво цей напрям підтримує. Простіше кажучи, це компас: коли працівник чи менеджер не знає, як діяти в неоднозначній ситуації, він звіряється з політикою.
Якщо розкласти детальніше, метою політики інформаційної безпеки є:
- задати напрям і принципи — що для компанії означає захист інформації і яких правил вона дотримується;
- закріпити відповідальність керівництва — політику затверджує топменеджмент, тож безпека перестає бути «проблемою айтівідділу»;
- дати рамку для цілей — з політики випливають конкретні, вимірювані цілі інформаційної безпеки;
- пов'язати безпеку із законами й договорами — через зобов'язання виконувати застосовні вимоги;
- запустити механізм покращення — політика фіксує, що система переглядається й розвивається.
Зверніть увагу: жодна з цих цілей не про технології. Політика не каже «встановіть антивірус X». Вона задає рівень, нижче якого компанія не опускається, а конкретні заходи вже підбираються під ризики.
Одна політика чи багато: пункт 5.2 і топікові політики
Тут ховається плутанина, на якій спотикаються майже всі новачки. У стандарті слово «політика» трапляється у двох різних місцях, і це не одне й те саме.
Пункт 5.2 вимагає одну верхньорівневу політику інформаційної безпеки — той самий короткий документ від керівництва, про який ідеться в цій статті. А контроль 5.1 з Annex A («Політики інформаційної безпеки», у множині) — це вже набір топікових, деталізованих політик під конкретні теми: політика контролю доступу, політика використання паролів, політика роботи з постачальниками, політика чистого столу.
Співвідношення просте: верхньорівнева політика (5.2) задає загальний напрям, а топікові політики (Annex A 5.1) розкривають його в деталях під окремі напрями. Одна «парасолька» і багато конкретних документів під нею. Плутати їх не варто: аудитор чекає обидва рівні, але верхньорівнева політика — одна, і вона має лишатися стислою.
Пункт 5.2 і Annex A 5.1: не сплутайте два рівні політик
Найчастіша помилка — намагатися вмістити в один документ і загальні принципи, і всі детальні правила. Верхньорівнева політика за пунктом 5.2 має лишатися короткою: дві-три сторінки, які прочитає й зрозуміє будь-який працівник. Усе технічне й детальне виносять в окремі топікові політики (контроль доступу, криптографія, використання активів), що відповідають контролю 5.1 з Annex A. Терміни цієї галузі, зокрема саме визначення «політики», формалізовано в стандарті-словнику ISO/IEC 27000.
Структура політики інформаційної безпеки: скелет по розділах
Тепер найпрактичніше — з чого фізично складається документ. Стандарт не диктує жорсткого шаблону: він каже, що політика має містити (пункти a–g), але не як її форматувати. За роки практики склалася структура, яка закриває всі вимоги 5.2 і при цьому лишається читабельною.
Вісім розділів політики інформаційної безпеки
Ось скелет, який можна взяти за основу й наповнити своїм змістом. Це не файл для завантаження, а структура: ви просто відтворюєте ці розділи у власному документі й пишете про свою компанію, а не про абстрактну «організацію».
| Розділ політики | Що в ньому написати | Вимога 5.2 |
|---|---|---|
| 1. Призначення й сфера дії | Навіщо документ і на кого поширюється: підрозділи, працівники, підрядники, системи | a |
| 2. Принципи безпеки | Що компанія захищає — конфіденційність, цілісність, доступність — і базові принципи | a |
| 3. Цілі інформаційної безпеки | Самі цілі або рамка для їх постановки; зв'язок із пунктом 6.2 | b |
| 4. Ролі та відповідальність | Хто відповідає: керівництво, власник СУІБ, працівники. Персональна, а не абстрактна | a |
| 5. Зобов'язання щодо вимог | Дотримання законів, договорів, регуляторних норм | c |
| 6. Управління ризиками | Посилання на процес оцінки й обробки ризиків — як компанія вирішує, що захищати | b |
| 7. Зобов'язання до покращення | Заява, що система переглядається й вдосконалюється | d |
| 8. Затвердження й перегляд | Хто затвердив, дата, версія, періодичність перегляду. Підпис керівництва обов'язковий | e |
Чого у верхньорівневій політиці бути не повинно
Вісім розділів — це орієнтир, а не догма. Маленька IT-компанія вмістить усе на двох сторінках, велика фінустанова розгорне до п'яти-шести. Головне правило: кожен розділ має нести сенс. Якщо ви не можете пояснити, навіщо в політиці той чи інший абзац, — його там бути не повинно.
І навпаки, є речі, яким у верхньорівневій політиці не місце. Конкретні налаштування паролів, списки дозволених програм, покрокові процедури реагування — усе це живе в топікових політиках і регламентах. Якщо запхати їх у головний документ, він розбухне до непридатного стану, а міняти його доведеться щоразу, коли зміниться дрібна технічна деталь. Політика має бути стабільною; деталі нехай змінюються нижче.
Коротка політика працює краще за товсту
Спокуса написати політику на двадцять сторінок, щоб «виглядало серйозно», грає проти вас. Що довший документ, то менше шансів, що його хтось прочитає, а вимога 5.2(f) якраз про те, щоб політику знали працівники. Хороша верхньорівнева політика вміщується на двох-трьох сторінках і читається за п'ять хвилин. Деталі — у топікових політиках і процедурах. Аудитор радше похвалить стислий документ, який люди справді розуміють, ніж товстий том, у який ніхто не заглядав після затвердження.
Від політики до сертифіката ISO/IEC 27001
Політика — це перший документ вашої системи управління інформаційною безпекою, але далеко не останній крок. Якщо ви готуєтеся до сертифікації, ми проведемо вас через оцінку ризиків, вибір контролів і аудит — від першої діагностики до сертифіката, який визнають клієнти в ЄС і США.
Підготовка до сертифікації ISO/IEC 27001Політика й управління ризиками інформаційної безпеки
Політика не висить у повітрі — вона спирається на управління ризиками інформаційної безпеки, і це зв'язок, який аудитори перевіряють особливо прискіпливо. Логіка така: спершу ви оцінюєте, що може піти не так із вашими даними, потім вирішуєте, що з цим робити, і лише тоді політика закріплює загальні принципи цих рішень.
Тому в політиці має бути розділ, який посилається на процес управління ризиками: хто його проводить, як часто, за якою методикою. Не сам аналіз ризиків — він живе в окремих документах, — а згадка про те, що компанія системно ним займається. Це і є практичне втілення вимоги 5.2(b): політика задає рамку, а конкретні цілі й заходи випливають з оцінки ризиків.
Зв'язка виглядає так: політика декларує намір керувати ризиками, оцінка ризиків показує, де саме загрози, обробка ризиків обирає контролі з Annex A, а Декларація застосовності фіксує вибір. Якщо в політиці немає й згадки про ризики, вона відірвана від реальної системи, і це видно одразу. Докладніше про те, як влаштована вся ця система, — у посібнику із сертифікації СУІБ.
Як написати політику інформаційної безпеки крок за кроком
Зберемо все в порядок дій. Ось як виглядає написання політики від чистого аркуша до підписаного документа.
- Зберіть контекст. Перш ніж писати, з'ясуйте, які дані компанія обробляє, чого вимагають клієнти й закони, де межі майбутньої системи. Без цього політика вийде абстрактною.
- Проведіть попередню оцінку ризиків. Навіть груба картина загроз підкаже, які принципи варто закріпити в політиці.
- Напишіть чернетку за скелетом вище. Вісім розділів, кожен — кілька абзаців простою мовою. Пишіть так, щоб зрозумів не лише безпечник, а й бухгалтер.
- Погодьте з керівництвом. Це не формальність: топменеджмент має не просто підписати, а зрозуміти й підтримати те, під чим підписується.
- Затвердьте, датуйте, версіонуйте. Політика без дати й версії — це чернетка. Поставте номер версії, дату затвердження і хто затвердив.
- Доведіть до персоналу. Розішліть, викладіть у внутрішній системі, додайте в онбординг новачків. Вимога 5.2(f) вважається виконаною тоді, коли люди про політику знають.
- Заплануйте перегляд. Раз на рік або після суттєвих змін, щоб політика не застаріла разом із компанією.
На практиці найбільше часу з'їдають не формулювання, а погодження з керівництвом і чесна оцінка того, що компанія реально робить, а не декларує. Якщо ви робите це вперше, попередня оцінка готовності економить тижні: вона показує, які принципи ви можете чесно закріпити в політиці вже зараз, а які поки що будуть фікцією.
Типові помилки, через які політику завертають
Помилки в політиках повторюються з компанії в компанію, і майже всі вони про формальний підхід. Ось ті, що трапляються найчастіше.
Перша й найгрубіша — скопіювати чужу політику. У відкритому доступі лежать політики банків і великих компаній, тож спокуса взяти готове велика. Але чужий документ описує чужі ризики, чужу структуру й чужі системи, і під час аудиту це випливає з перших питань. Друга — політика, відірвана від реальності: у ній написано «доступ надається за принципом мінімальних привілеїв», а насправді у всіх адмінські права. Аудитор перевіряє не текст, а відповідність тексту життю.
Третя помилка — завелика деталізація, коли у верхньорівневу політику намагаються запхати паролі, налаштування й процедури. Для цього є топікові політики. Четверта — відсутність підпису й дати: документ без затвердження керівництвом формально не виконує вимогу 5.2. І п'ята — «написали й забули»: політику затвердили три роки тому, компанія змінилася до невпізнаваності, а документ той самий.
Скопійована політика — найшвидший шлях до зауваження
Найпоширеніша причина, чому політику завертають на аудиті, — вона очевидно не про цю компанію. Формулювання про «дата-центри» у фірми, що вся в хмарі, згадки про відділи, яких не існує, принципи, які ніхто не виконує. Політику не оцінюють за красою мови — її звіряють з тим, як компанія працює насправді. Тому чесний документ на дві сторінки, що відображає ваші реальні процеси, завжди сильніший за красивий чужий шаблон. Пишіть про себе, а не про абстрактну «організацію».
Як Ekontrol допомагає з політикою і сертифікацією
На практиці політика рідко буває самоціллю — компанія приходить по неї, бо готується до сертифікації або відповідає на запит клієнта. Тому ми не пишемо політику окремо від системи: Ekontrol супроводжує впровадження СУІБ як єдиний напрям, і політика народжується природно з оцінки вашого контексту й ризиків, а не з шаблону.
Починаємо з розбору ситуації: які дані ви обробляєте, чого вимагають контракти, де ваш головний ризик. Далі — попередня діагностика, яка показує розрив між тим, що є, і тим, чого хоче стандарт, а вже потім побудова політики й решти документів під ваші реальні процеси. Наші послуги з підготовки до сертифікації охоплюють увесь шлях — від першої діагностики до сертифікаційного аудиту. Для IT- і SaaS-компаній, що працюють із клієнтами з ЄС і США, ми окремо готуємо тендерну документацію, де політика лише один з елементів.
Якщо не знаєте, з чого почати, є два прості варіанти: прочитати повний посібник з ISO/IEC 27001, щоб побачити всю картину, або одразу зв'язатися з командою Ekontrol й обговорити вашу ситуацію. Ми працюємо як партнер Bureau Veritas в Україні з 2014 року.
