ISO 27001 Annex A: 93-те контроли, обяснени (2022)

Контролите от ISO 27001 Annex A са каталогът от мерки за сигурност на информацията, който стои в сърцето на най-широко признатия в света стандарт за система за управление на сигурността на информацията (ISMS). Ако сте CISO, който планира проект за сертификация, мениджър по съответствието, който се подготвя за одит, или основател, от когото корпоративен купувач иска сертификат по ISO 27001, това ръководство отговаря на практичните въпроси: какво всъщност съдържа Annex A, защо ревизията от 2022 г. свали броя от 114 на 93, кои контроли сте длъжни да прилагате и как Декларацията за приложимост превръща един общ списък в защитима програма за сигурност, съобразена с вашата организация.

Какво представлява ISO 27001 Annex A

ISO/IEC 27001 е международният стандарт, който определя изискванията за създаване, работа, поддържане и непрекъснато подобряване на ISMS. Основната част на стандарта (клаузи от 4 до 10) е мястото, където живеят обвързващите изисквания: контекст, лидерство, планиране, поддръжка, дейности, оценка на резултатността и подобряване. Annex A е нормативно приложение, добавено към тази основна част. То представлява справочен списък с контроли за сигурност на информацията, от който организацията черпи, за да третира рисковете, които е идентифицирала.

Важният нюанс е, че Annex A е меню. Подробните указания за прилагане на всяка контрола живеят извън самия ISO 27001; те са в придружаващия стандарт ISO/IEC 27002:2022, който описва целта на всяка контрола и как да се приложи. Annex A ви дава кратките заглавия и формулировките на контролите; ISO 27002 ви дава дълбочината. Заедно те позволяват на одитора и на организацията да говорят на един и същ език за това как изглежда "доброто" при всяка мярка.

На кого са нужни ISO 27001 и контролите от Annex A

ISO 27001 е доброволен в смисъл, че никой отделен закон не го обявява за задължителен за всяка компания. На практика той е станал почти задължителен за цели категории организации, като движещата сила идва от търговския натиск на пазара. Ако някое от следващите описания се отнася за вас, Annex A ви предстои.

B2B софтуерни и облачни доставчици

SaaS доставчиците, доставчиците на управлявани услуги и обработващите лични данни са най-голямата група, която търси сертификация. Корпоративните отдели по доставки и въпросниците за сигурност все по-често третират сертификата по ISO 27001 като входен билет за сделката. Спечелването на голям клиент често зависи от представянето на сертификата и понякога на Декларацията за приложимост зад него.

Регулирани фирми и фирми, критични за веригата на доставки

• Финансови услуги и финтех, където регулаторите и банковите партньори очакват признат базов стандарт за сигурност.
• Здравеопазване и здравни технологии, които обработват чувствителни лични данни в голям мащаб.
• Доставчици на публичния сектор, където обществените поръчки често правят сертификацията оценявано или допускащо изискване.
• Критични доставчици на по-големи предприятия, които наследяват задължения за сигурност, спуснати надолу по договорите.

Организации, които съгласуват няколко рамки

Тъй като наборът контроли в Annex A се припокрива силно с други режими, много екипи приемат ISO 27001 за свой гръбнак и картират всичко останало върху него. Припокриването със SOC 2 често се посочва като около 80 процента, така че компания, обслужваща едновременно европейски и американски клиенти, може да изгради една контролна среда и да я докаже спрямо двата стандарта. Тази възможност за кръстосано съпоставяне е основна причина ISO 27001 да бъде избиран дори когато нито един клиент не го е поискал изрично.

Какво всъщност изисква ISO 27001

Често срещано погрешно схващане е, че ISO 27001 е "93-те контроли". Това не е така. Сертификацията се присъжда спрямо изискванията към системата за управление в клаузи от 4 до 10, а контролите са един от входовете към тази система. Организация може да внедри всяка контрола от списъка и пак да се провали на одит, ако няма работеща оценка на риска, няма преглед от ръководството и няма доказателства, че ISMS работи във времето. Точно тук повечето проекти за първи път разпределят усилието си погрешно. Екипите прекарват месеци в лъскане на технически контроли, които до голяма степен вече са имали, а после откриват на Етап 1, че протоколите от прегледа на ръководството, програмата за вътрешен одит и записите за коригиращи действия почти не съществуват. Тези артефакти се произвеждат евтино и е невъзможно да бъдат правдоподобно антидатирани, така че започнете да ги генерирате още през първия месец, дори когато половината контроли са още в процес.

Основните задължения вървят приблизително така. Определяте обхвата на своя ISMS и контекста, в който той работи. Ръководството поема ангажимент към политика за сигурност на информацията и възлага отговорности. Извършвате оценка на риска, за да установите какво може да се обърка за поверителността, целостта и наличността на вашата информация, а след това процес по третиране на риска, за да решите как да адресирате всеки риск. Именно при третирането на риска посягате към Annex A: за всеки риск, който решите да намалите с контрола, избирате съответната контрола от Annex A (или собствена контрола) и записвате защо. След това привеждате тези контроли в действие, наблюдавате и измервате тяхната резултатност, провеждате вътрешни одити, правите прегледи от ръководството и действате по несъответствията. Целият цикъл е замислен като непрекъснат.

Съществено е, че не всички контроли от Annex A са задължителни. От вас се изисква да разгледате всяка контрола и да решите дали е приложима към вашите рискове. Контрола може да бъде изключена, но само с документирана обосновка. Точно това прави ISO 27001 използваем както за стартъп от десет души, така и за мултинационална компания: един и същ каталог мащабира, защото всяка организация прилага само това, което нейната собствена рискова картина оправдава. Това е и частта от стандарта, която е наистина добре написана. Предписателен списък с контроли щеше да остарее зле и да смачка малките организации, а превръщането на приложимостта в документирано решение поставя преценката там, където ѝ е мястото. Уловката е, че не можете да се скриете зад каталога. Изключенията, които се четат като удобство вместо като разсъждение, са най-лесното несъответствие, което одиторът някога ще напише.

Четирите теми на Annex A и Декларацията за приложимост

Ревизията от 2022 г. беше значително преструктуриране. Предишното издание от 2013 г. организираше 114 контроли в 14 области. Изданието от 2022 г. консолидира и модернизира набора до 93 контроли, групирани в четири теми:

• Организационни контроли (37): политики, роли и отговорности, отношения с доставчици и облачни услуги, разузнаване на заплахи, управление на инциденти и управление на непрекъснатостта на дейността.
• Контроли за хората (8): проверка на кандидати, условия на трудовите правоотношения, осведоменост и обучение, дисциплинарен процес и отговорности след напускане.
• Физически контроли (14): защитени зони, защита на оборудването, чисто бюро и чист екран и сигурно унищожаване.
• Технологични контроли (34): контрол на достъпа, криптография, логване и наблюдение, сигурна разработка, мрежова сигурност и предотвратяване на изтичане на данни.

Преномерирането беше повече от козметично. Ревизията сля припокриващи се контроли и въведе 11 нови контроли, които отразяват промените в технологиите, включително разузнаване на заплахи, сигурност на информацията при използване на облачни услуги, ИКТ готовност за непрекъснатост на дейността, наблюдение на физическата сигурност, управление на конфигурациите, изтриване на информация, маскиране на данни, предотвратяване на изтичане на данни, дейности по наблюдение, уеб филтриране и сигурно програмиране. ISO 27002:2022 добави и пет "атрибута" към всяка контрола (например тип контрола, свойства на сигурността и концепции за киберсигурност), за да помогне на организациите да филтрират и препращат в набора. Третирайте тези нови контроли като неравностойни, защото такива са. Разузнаването на заплахи и предотвратяването на изтичане на данни струват реални пари и реално внимание. Сигурното програмиране е онова, което най-вероятно ще разкрие разликата между това, което политиката ви твърди, и това, което разработчиците ви правят при преглед на кода. Изтриването на информация и маскирането на данни обикновено са документация, наслоена върху неща, които вече правите. Подреждането им по този начин, преди да планирате проекта, е разликата между оценка, която издържа, и такава, която се срива през втория месец.

Документът, който свързва всичко това, е Декларацията за приложимост (Statement of Applicability, SoA). SoA е задължителен резултат от ISMS. Тя изброява всяка контрола от Annex A, посочва дали сте я приложили, описва как (или препраща къде е внедрена) и обосновава всяко изключване. Одиторите третират SoA като картата на вашата контролна среда; тя често е първият артефакт, който сертифициращият орган иска да види. Добре поддържаната SoA е разликата между одит, който тече гладко, и одит, който засича. Изготвянето на първата версия е черна работа, приблизително две седмици, ако вече познавате контролния си пейзаж, и е черна работа, която си струва да свършите сами, вместо да я оставите на шаблон. Истинският капан е втората година: система се променя, никой не преразглежда обосновката и една остаряла SoA се чете от одитора като ISMS, която никой всъщност не поддържа.

Как всъщност да постигнете съответствие: практическа програма

1. Определете обхвата. Решете кои части от бизнеса, системите и локациите покрива ISMS. Стегнатият и честен обхват е по-лесен за сертифициране и поддържане от прекалено амбициозния. Имайте предвид, че купувачите четат декларациите за обхват. Сертификат, покриващ една продуктова линия и един офис, ще бъде оспорен от всеки внимателен екип по доставки, така че спокойно определете тесен обхват за първия цикъл, но решете предварително какво ще отговорите, когато клиент попита защо услугата, която купува, стои извън него.
2. Осигурете ангажимент на ръководството и политика. Осигурете документиран ангажимент на ръководството, политика за сигурност на информацията и ясна собственост. Това е изискване по клауза 5 и е задължително.
3. Проведете оценка на риска. Идентифицирайте информационните активи и рисковете за тях, след което оценете тези рискове с последователна методология, която можете да повторите и защитите.
4. Изгответе плана за третиране на риска. За всеки риск, който решите да намалите, изберете съответните контроли от Annex A и запишете решението.
5. Напишете Декларацията за приложимост. Преминете през всичките 93 контроли, отбележете всяка като приложима или изключена и обосновете всяко изключване. Този документ се развива заедно с ISMS.
6. Внедрете избраните контроли. Въведете политиките, техническите мерки и процесите и започнете да генерирате доказателствата, които показват, че те работят.
7. Работете, наблюдавайте и одитирайте вътрешно. Събирайте показатели, провеждайте вътрешни одити и правете прегледи от ръководството, за да изплуват несъответствията, преди външен одитор да ги открие.
8. Ангажирайте акредитиран сертифициращ орган. Одитът на Етап 1 преглежда вашата документация и готовност; одитът на Етап 2 проверява дали ISMS работи на практика. Сертификатът обикновено е валиден три години, с ежегодни надзорни одити и ресертификация в края на цикъла.

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

За преглед контрола по контрола на това как една платформа картира доказателства към всяка контрола от Annex A и поддържа Декларацията за приложимост, вижте как Venvera работи с ISO 27001. Ако още избирате инструменти, нашият преглед на софтуера за съответствие с ISO 27001 в сравнение показва на какво да обърнете внимание.

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

Колко контроли има в ISO 27001 Annex A?

Ревизията на ISO 27001 от 2022 г. съдържа 93 контроли в Annex A, спрямо 114 във версията от 2013 г. Те са групирани в четири теми: 37 организационни, 8 за хората, 14 физически и 34 технологични контроли. Намалението дойде от сливането на припокриващи се контроли, а ревизията въведе и 11 наистина нови контроли.

Задължителни ли са всичките 93 контроли от Annex A?

Не. От вас се изисква да разгледате всяка контрола, но прилагате само тези, които вашата оценка на риска показва като относими. Контрола може да бъде изключена, при условие че документирате обосновка. Тези решения за приложимост се записват в Декларацията за приложимост, която сама по себе си е задължителна част от ISMS.

Каква е разликата между ISO 27001 и ISO 27002?

ISO 27001 е сертифицируемият стандарт: той определя изискванията към системата за управление и изброява контролите от Annex A като кратки формулировки. ISO 27002 е придружаващото ръководство, което обяснява целта на всяка контрола и как да се внедри. Сертифицирате се спрямо ISO 27001; използвате ISO 27002, за да разберете и приложите контролите в дълбочина.

Какво представлява Декларацията за приложимост?

Декларацията за приложимост (Statement of Applicability, SoA) е задължителен документ, който изброява всички контроли от Annex A, посочва дали всяка от тях се прилага за вашата организация, описва как са внедрени приложимите контроли и обосновава всички изключвания. Сертификационните одитори разчитат на нея като на карта на вашата контролна среда, затова тя често е първият документ, който искат.

Как ISO 27001 се свързва със SOC 2?

Двете рамки адресират едни и същи основни грижи за сигурността и наборите им от контроли се припокриват съществено, като припокриването често се оценява на около 80 процента. Много организации, обслужващи едновременно европейски и американски клиенти, изграждат една контролна среда и я доказват както спрямо ISO 27001, така и спрямо SOC 2, което значително намалява дублираното усилие.

Колко време е валиден сертификатът по ISO 27001?

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

Първични източници

• ISO/IEC 27001:2022 - стандартът, определящ изискванията към ISMS, включително Annex A. ISO 27001 в iso.org.
• ISO/IEC 27002:2022 - указанията за контролите, описващи целта и внедряването на всяка контрола от Annex A. ISO 27002 в iso.org.

Бележка за обхвата. Тази статия обобщава структурата на ISO 27001 и неговия Annex A с ориентировъчна цел. Броят на контролите и изискванията следва да се потвърдят спрямо официалните стандарти на ISO, а вашите решения за приложимост следва да отразяват собствената ви оценка на риска и указанията на вашия сертифициращ орган.

От Александър Свердлов, главен изпълнителен директор и основател на Venvera. Публикувано на 20 юли 2026 г. - последен преглед на 20 юли 2026 г.