ISO 27001 за българска софтуерна компания: 6-месечна пътна карта седмица по седмица, без излишни инструменти и без забавяне на продукта
Alexander Sverdlov
Анализатор по сигурността

Какво ще научите
- 24 седмици е реалистичният минимум за сертификация на софтуерна компания с 30-80 души, която вече работи с Google Workspace или Microsoft 365, GitHub и AWS/Azure. Под 24 седмици бързате; над 36 седмици губите импулс.
- Реалното вътрешно време е 340-520 часа, разпределени между технически директор (40%), отговорник по сигурността или vCISO (35%), разработчици (15%), HR и юрист (10%). Не е цяла длъжност, а съсредоточени усилия в седмични блокове.
- Първите 4 седмици (обхват + gap анализ) определят 70% от крайната цена и срок. Грешка тук добавя 8-12 седмици към проекта по-късно, без значение колко добре върви всичко друго.
- Седмиците 13-16 (вътрешен одит и преглед на ръководството) са най-подценявани. Тук падат проекти, които изглеждат готови. Резервирайте 80 часа и не правете компромис.
- Седмицата на сертификационния одит е психологически тежка, но технически проста, ако подготовката е свършена. От 11 проекта 10 минаха на първа сертификация с под 5 несъответствия, при това все категория "малки".
- Не купувайте Vanta, Drata или Secureframe в първите 8 седмици. Те имат смисъл от седмица 9, когато вече знаете кое искате да автоматизирате. Преждевременна автоматизация оскъпява проекта с 8 000 - 14 000 лв. и не спестява нито една седмица.
Изпълнителен директор на 42-човешка софтуерна компания в София ми се обади през март. Преди седмица беше получил оферта от германски корпоративен клиент - 6 940 000 евро договор за 3 години, със стартова дата 1 септември 2026 г. и условие за валиден ISO/IEC 27001:2022 сертификат до 1 октомври 2026 г. Без сертификат до тази дата, договорът се разваля автоматично.
Той имаше три оферти от консултантски фирми. Едната обещаваше "сертификат за 12 седмици" - очевидно нереалистично за компания без съществуваща ИСМС. Втората искаше 187 000 лв. за "пълен проект" с неясен обхват и без фиксирани мили. Третата обещаваше "помощ от 10 часа седмично" срещу 4 800 лв./месец до сертификация - на практика 16-18 месеца, прекалено дълго.
Нашият съвет беше различен. ISO 27001 за софтуерна компания с тяхния профил (Google Workspace, GitHub, AWS, 4 продукта в продакшън, без външна процесинг инфраструктура) се изпълнява за 24 седмици, ако работата е разпределена правилно. Не за 12. Не за 18. За 24. И не изисква специален отдел или софтуерна платформа, която струва колкото втори член на екипа.
Този материал е дългата версия на тази пътна карта. От 11 успешни проекта (всичките сертифицирани) за български софтуерни компании от 18 до 240 души през последните 18 месеца: задачи седмица по седмица, кой ги прави, колко часа отнемат, кога и защо проектът се забавя, и какво да правите всеки понеделник, докато не държите сертификата в ръка.
Защо 24
Защо точно 24 седмици и какво ограничава графика
ISO 27001 има две твърди времеви ограничения, които никой консултант не може да съкрати: задължителен 2-3 месечен оперативен период, през който ИСМС работи в обичаен режим, преди сертификационният одитор да я приеме като "ефективно действаща" (изисквания на ИСО/МЕК 17021), и фаза 1 + фаза 2 одит, който отнема 2-4 седмици между двете посещения. Всичко останало е работа, която може да бъде ускорена, но тези 14-18 седмици са физическа граница.
Под 24 седмици проектът е възможен само за компания, която вече има голяма част от 93-те контрола в Анекс А действащи преди да започне. Над 36 седмици проектът губи фокус: смяна на ръководители, преоритизация на бизнес цели, текучество на персонал, обновяване на технологичния стек. Всеки наш проект, който е минал над 36 седмици, се е удължил поне до 50 седмици.
Кога 24 седмици са нереалистични: дайте си 36
Ако компанията няма SSO (Google Workspace или Microsoft 365 като единствен централен идентификатор), няма MDM на ноутбуците, няма централизиран мениджър на пароли, или работи без писмени договори с подизпълнители - 24 седмици не са реалистични. Дайте си 36 седмици и направете проекта с уважение към собствения си капацитет. Сертификат от 24-седмичен проект под напрежение струва същото, колкото сертификат от 36-седмичен проект с дишане - и двата минават първата ресертификация без проблем.
Седмици 1-4
Седмици 1-4: Обхват, gap анализ и решения, които определят 70% от проекта
Това са четирите най-важни седмици на целия проект. Решенията тук определят кое влиза в обхвата, кое остава вън, колко струва финално и кога приключва. Грешки в седмици 1-4 не се поправят късно без отлагане на сертификата.
| Седмица | Основна задача | Кой | Часове |
|---|---|---|---|
| 1 | Дефиниране на обхвата: продукти, локации, дейности, изключения. Решение за обхват по облак, по продуктова линия или по юридическо лице. | CEO + CTO + vCISO | 14-22 |
| 2 | Gap анализ на 93-те контрола в Анекс А, маркиране на "действащо", "частично", "липсва". Карта на активите и оценка на риска - първи проект. | vCISO + CTO | 24-36 |
| 3 | Избор и запитване до 3 акредитирани сертификационни органа (Bureau Veritas, TUV Rheinland, SGS, DEKRA, BSI, LL-C). Сравнение на оферти и резервация на одитор за седмица 22-24. | CEO + vCISO | 10-14 |
| 4 | Структура на ИСМС: контекст на организацията (4.1, 4.2, 4.3), политика по сигурност, ангажираност на ръководството (клауза 5), декларация на приложимост (SoA) - първа версия. | vCISO + CEO | 22-32 |
Най-частата грешка в първите 4 седмици е разширяване на обхвата без причина. Компания, която предлага 4 продукта и от тях 2 имат корпоративни клиенти, не трябва да включва другите 2 в обхвата. SaaS, който работи в AWS Frankfurt с DR в AWS Dublin, не трябва да включва несвързана локална CRM. Всеки излишен елемент в обхвата добавя 6-12 часа документация плюс 2-3 въпроса от одитора.
Изключенията в SoA не са срамни
Декларацията на приложимост (Statement of Applicability) изисква от вас да обясните защо някои от 93-те контрола в Анекс А не се прилагат. Това е НОРМАЛНО. Софтуерна компания без производствена линия с право изключва A.7.10 (контрол на физическия достъп до зони за товарене). Без държавни договори с гриф - изключва A.5.27 (поверителна информация). Целта на SoA не е "100% контроли да са вкл."; целта е "честен запис кои се прилагат и кои не, с обяснение защо". Одиторът цени честното изключение по-високо от формално приложен, но реално несъществуващ контрол.
Седмици 5-12
Седмици 5-12: Внедряване на политики, контроли и доказателствена база
Това е най-дългата фаза - 8 седмици. Тук се пише голямата част от документацията, конфигурират се техническите контроли в продукционната среда и започва системно събиране на доказателства. Голяма част от тази работа може да върви паралелно: технически контроли от инженер, политики от vCISO, обучение от HR.
Конкретно за софтуерна компания: контролите А.8.25 - А.8.34 (сигурно разработване) са най-чести причина за допълнително време в тази фаза. Ако нямате документиран SDLC с code review задължителен, секрет сканиране в CI/CD и автоматично сканиране на зависимости, отделете 25-40 часа допълнително. Това не е допълнителен инструмент - GitHub Advanced Security, Snyk Free Tier или Trivy в pipeline покриват изискването безплатно.
Седмици 13-20
Седмици 13-20: Оперативен период, вътрешен одит и преглед от ръководството
Седмици 13-16: ИСМС работи "в обичаен режим". Доказателства се събират автоматично или ръчно с честота, която отговаря на политиките (логове седмично, прегледи на достъп месечно, тестове на резервно копие месечно). Седмица 17-18: вътрешен одит - независим преглед на всичките 93 контрола от поне един човек, който не ги е писал. Седмици 19-20: преглед от ръководството, корективни действия, документиране на резултатите.
Това е фазата, която най-често се подценява. Вътрешен одит "от половин час" не съществува. От 11 проекта, средното време за компетентен вътрешен одит на софтуерна компания с 40-60 души е 28 часа на одитор плюс 14-22 часа от страна на одитираните екипи. Спестяване на този етап означава да дадете на сертификатора 12-18 несъответствия за намиране вместо да ги намерите сами.
| Седмица | Основна задача | Кой | Часове |
|---|---|---|---|
| 13-16 | ИСМС в оперативен режим. Седмично събиране на доказателства. Месечни прегледи на достъп. Първи реален инцидент в журнала (планиран или истински). | Всички екипи | 38-58 |
| 17 | Вътрешен одит на първите 50 контрола. Записване на находки. Срещи с собствениците на процеси. | Вътрешен одитор | 28-36 |
| 18 | Вътрешен одит на следващите 43 контрола. Доклад с находки и препоръки. Среща с ръководството. | Вътрешен одитор | 26-32 |
| 19 | Преглед от ръководството (клауза 9.3). Корективни действия за всяко несъответствие. Актуализация на риска и SoA. | CEO + CTO + vCISO | 16-22 |
| 20 | Финализиране на доказателствената база. Подреждане на 93-те контрола в споделена директория. Подготовка за фаза 1 на сертификатора. | vCISO + CTO | 18-26 |
Вътрешният одитор не може да е същият човек, който е писал политиките. ISO/IEC 17021 изисква независимост. Възможните решения: vCISO от друга компания за две седмици (типична цена 4 800-7 200 лв.), вътрешен мениджър от друг отдел с базово обучение (по-бавно, но безплатно), или сертифициран ISO 27001 Lead Auditor на хонорар (8 000-12 000 лв.).
Седмици 21-24
Седмици 21-24: Фаза 1, фаза 2 и сертификатът
Тук всичко е дошло до сертификационния орган. Фаза 1 е документен преглед - одиторът идва (обикновено за 1 ден на място плюс 2-3 дни дистанционна работа) и оценява дали ИСМС е готова за фаза 2. Резултатът е доклад с препоръки и евентуални "малки несъответствия" които трябва да са поправени до фаза 2.
Фаза 2 е оперативен одит - проверка на действителната работа на контролите. За софтуерна компания от 40-60 души това отнема 2-3 дни на място плюс 1-2 дни обработка на доказателствата. Одиторът разговаря с разработчици, прави извадка от тикети, проверява логове за инциденти, тества backup, преглежда регистър на доставчици. След фаза 2: доклад, корективни действия (ако има), решение от сертификационния комитет и - сертификат.
Между фаза 1 и фаза 2 не трябва да правите значителни промени в ИСМС. Ако одиторът намери, че сте променили политика или контрол между двата одита, фаза 2 спира и започва отначало. Това е една от трите най-чести причини за забавяне на ISO 27001 проект.
Грешки
Петте грешки, които превръщат 6-месечен проект в 14-месечен
Грешка 1. Купуване на Vanta/Drata преди седмица 9
Тези платформи са брилянтни за автоматизация на доказателства, но в първите 8 седмици нямате на какво да ги "закачите". Конфигурация без ясни политики и без yet-to-be-defined контроли се повтаря по-късно. Изчакайте до седмица 9, когато техническите контроли са на място, и автоматизирайте оттам нататък. Спестявате 8 000-14 000 лв. и три седмици разкарване на платформа, която още не сте сигурни дали ще използвате.
Грешка 2. Прекалено широк обхват
"Да включим всичко за всеки случай" е изречение, което струва скъпо. Всеки излишен продукт, локация или дейност в обхвата добавя 12-30 часа документация плюс още толкова време на одитора. Започнете тясно (един основен продукт + основната инфраструктура) и разширявайте при надзорни одити. Намалявате риска от провал и можете да сертифицирате допълнителен обхват без пълна ресертификация.
Грешка 3. Резервация на сертификатор от седмица 18 вместо седмица 4
Акредитираните органи са натоварени. Bureau Veritas, TUV Rheinland и SGS често нямат свободен слот на 8-10 седмици напред. Ако не сте резервирали, чакате. От нашите 11 проекта, 3 загубиха по 4-6 седмици защото началната резервация е била късна. Резервацията е безплатна и може да се отмени до 30 дни предварително без неустойка - правете я в седмица 3-4 на проекта.
Грешка 4. Игнориране на 2-3 месечния оперативен период
Не можете да преминете фаза 2 без 60-90 дни доказателства, че ИСМС е работила в нормален режим. Това означава, че от 24-та седмица, ИСМС трябва да е била "жива" вече от поне 12-та седмица. Тийми, които започват ИСМС в седмица 18, не приключват в седмица 24 - приключват в седмица 34. Изградете календар, в който ИСМС "започва да работи" в седмица 12 и работи без съществени промени до фаза 2.
Грешка 5. Подценен вътрешен одит
"Ще го направим за един следобед" е изречение, което завършва с 10-15 несъответствия в фаза 2. Качествен вътрешен одит за софтуерна компания с 40-60 души изисква 50-70 часа на одитора плюс 30-40 часа от страна на одитираните. Ако нямате независим вътрешен одитор, наемете - 4 800-12 000 лв. за две седмици са инвестиция, която плаща за себе си многократно.
Често задавани въпроси
Често задавани въпроси
Може ли проектът да приключи за 16 седмици вместо за 24?
Само ако ИСМС вече е била частично имплементирана преди старта на проекта. Конкретно: ако имате документирани политики (поне 8-10 от 25 типични), SSO с условен достъп, MDM на >90% от устройствата, секрет мениджмънт, и са изтекли поне 60-90 дни от последната съществена промяна на тези контроли - тогава 16 седмици са възможни. От 11-те проекта, 1 е минал за 18 седмици, защото компанията вече беше преминала SOC 2 Type 2. Останалите 10 - между 24 и 32 седмици.
Какво се случва, ако не минем фаза 2 от първи опит?
Зависи от типа несъответствия. Малки несъответствия (commonly "minor non-conformities") - сертификатът се издава след представяне на план за корекция в 30 дни. Големи несъответствия ("major non-conformities") - сертификатът не се издава, прави се повторен фокусиран одит след 60-90 дни (по-евтин от пълен фаза 2 - типично 30-50% от цената). От 11 проекта, 1 имаше едно голямо несъответствие (липсваща писмена процедура за реакция на инциденти, която беше изпратена устно като "ще го документираме" в седмица 19) - сертификатът беше издаден 2 месеца по-късно.
Трябва ли да имам отделен човек по сигурност на пълно работно време?
Не. За софтуерна компания с под 100 души vCISO на 8-12 часа седмично през проекта е достатъчно (типична цена 3 600-6 400 лв./месец). След сертификацията поддръжката изисква 4-8 часа седмично, което може да се поеме от вътрешен инженер с допълнително 10-15% натоварване. Цялостен CISO на пълно работно време има смисъл при 150+ души или при значителни регулаторни задължения (NIS2 за съществен субект, DORA, GDPR с висок риск, ISO 27001 + SOC 2 паралелно).
Кой пише политиките - vCISO, юрист или мениджърите?
vCISO ги пише или адаптира от шаблон, мениджърите ги одобряват, юристът ги преглежда за съответствие с българското законодателство (ЗЗЛД, ЗКС, GDPR транспозиция). Първата версия на 25-те типични политики се пише за 60-90 часа от vCISO, прави се преглед от собствениците на процеси (30-45 часа), и финално одобрение от ръководството (10-15 часа). Не започвайте от празен лист - 80% от текста може да дойде от стандартен шаблон, който се адаптира към реалните ви процеси.
Има ли разлика между ISO/IEC 27001:2013 и 27001:2022?
Да, и тя е значителна. ISO 27001:2022 е новата версия (издадена октомври 2022 г.), Анекс А вече има 93 контрола в 4 групи (вместо 114 в 14 групи в 2013-та). Преходът беше задължителен до 31 октомври 2025 г.; всички сертификати по 2013-та вече са невалидни. Ако някой консултант ви предлага "ISO 27001:2013" - бягайте. Ако имате стар сертификат по 2013-та, той трябваше да бъде преиздаден през 2025 г.; ако не - вашата компания няма валиден ISO 27001.
Какво да правя през 36-те месеца между две ресертификации?
12 и 24 месеца след сертификацията: надзорни одити, които покриват 1/3 от контролите всеки път (така че за 36 месеца са покрити всички 93). Между одитите: тримесечни прегледи от ръководството, продължаващо събиране на доказателства, актуализация на регистъра на риска при значителни промени (нов продукт, нова локация, нова значима интеграция), две тренировки по реакция на инциденти годишно. Надзорните одити струват около 40% от цената на сертификацията; ресертификацията на 36-ия месец струва около 70%.
Поговорете с човек
Готови сте да започнете ISO 27001 проекта за вашата софтуерна компания?
Помогнали сме на 11 български софтуерни компании от 18 до 240 души да получат ISO/IEC 27001:2022 сертификат за 24-32 седмици. Безплатна 30-минутна първоначална консултация: преглед на текущото състояние, реалистичен график, ориентировъчна цена.
Резервирайте 30-минутна консултация
Александър Свердлов
Основател на Atlant Security. Автор на 2 книги за информационна сигурност, лектор по киберсигурност на най-големите конференции по киберсигурност в Азия и панелист на конференция на ООН. Бивш член на екипа за консултации по сигурността на Microsoft, външен консултант по киберсигурност в Емиратската корпорация за ядрена енергия.