Финтех компаниите имат нужда от ISO 27001 по различни причини от SaaS компаниите
ISO 27001 за финтех не е просто enterprise sales инструмент. Тук натискът идва едновременно от три страни: регулаторите (БНБ, КФН), инвеститорите при due diligence и партньорите (банки, платежни оператори). Платежните данни и лицензионните задължения правят сигурността екзистенциален въпрос, не конкурентно предимство.
Помагаме на финтех компании да внедрят ISO 27001 с обхват и контроли, съобразени с регулаторната реалност в България - не с generic шаблони.
Защо финтехът се нуждае от ISO 27001
БНБ и КФН очакват зрялост по сигурността
БНБ следва насоките на Европейския банков орган (ЕБО) за управление на ИКТ риска. Тези насоки очакват от лицензираните институции - включително платежните оператори и финтех дружествата с PSD2 лиценз - да демонстрират формална система за управление на информационната сигурност. ISO 27001 сертификатът е най-разпознаваемото доказателство за тази зрялост.
При регулаторни прегледи на БНБ, компании с валиден ISO 27001 сертификат прекарват значително по-малко време в обяснение на baseline контролите. Одиторите имат структурирана рамка за справка и питат за конкретни отклонения, а не за основи.
Инвеститорски due diligence при финтех е по-интензивен
При Series A и нагоре, техническият due diligence при финтех компании включва по-задълбочен преглед на security posture от типичен SaaS. Причината е проста: регулаторният риск при финтех е по-висок и инвеститорите го знаят. Липса на формална система за управление на сигурността може да блокира сделка или да намали оценката.
ISO 27001 дава структурирани доказателства - одитирана система, не само твърдения. Много от нашите клиенти са използвали сертификата директно в dataroom-а при fundraising.
PSD2 и DORA създават регулаторни слоеве, не ги елиминират
Ако имате PSD2 лиценз или работите с лицензиран платежен оператор, имате DORA задължения. Ако оперирате критична инфраструктура или сте с 50+ служители, имате NIS2 задължения. ISO 27001 покрива значителна основа - около 60-70% от ИКТ изискванията в DORA и около 50-60% от мерките по NIS2 - но не е заместител. Нужна е координация между режимите.
Платежните данни имат специфично тегло
Инциденти с платежни данни носят директна финансова вреда за клиентите - не само репутационна. Регулаторите, партньорите и банките третират тези данни с по-висок приоритет от общи лични данни. ISO 27001 контролите по криптография, достъп и управление на инциденти са директно приложими тук.
Кои контроли имат най-голямо значение за финтех
Криптография и управление на ключове (A.8.24)
За финтех компания, контрол A.8.24 не е теоретичен. Управлявате криптографски ключове за API интеграции с banking системи, токенизация на платежни данни, подписване на транзакции. Одиторите проверяват не само дали имате политика, а дали имате реален key management процес - кой има достъп, как се ротират ключовете, какво се случва при компрометиране.
Работим с технически екипи директно, за да документираме реалния процес, а не да пишем политика, която не отразява действителността.
Управление на инциденти с регулаторно измерение
При финтех инцидентът не е само технически проблем - той може да изисква докладване в реални срокове към БНБ, СЕРИКС (при NIS2 задължения) и потенциално клиентите. ISO 27001 изисква формален incident management процес (A.5.24-5.26), но за финтех компаниите трябва да добавим паралелните регулаторни пътеки.
Изграждаме процедури, в които ескалацията и докладването към регулаторите са вградени от самото начало - не прибавени после.
Управление на достъпа до финансови системи
Принципът на минималните привилегии (A.8.2) при финтех означава много повече от “правилните хора имат достъп до правилните системи”. Трябва да управлявате достъпа до banking API ключове, до production бази данни с транзакции, до admin панели на payment processor-и. Одиторите търсят конкретни доказателства - access logs, периодични access reviews, offboarding процедури.
Business continuity за регулирана среда
RPO и RTO при финтех не са просто технически параметри - те могат да бъдат регулаторни изисквания. Прекъсването на платежни услуги носи директна вреда за клиентите и привлича регулаторно внимание. ISO 27001 контролите A.5.29-5.30 трябва да са проектирани с конкретни цели за непрекъснатост, а не само на хартия.
Third-party risk от payment processors и banking партньори
Вашата сигурност е толкова добра, колкото е веригата ви на доставки. Контрол A.5.19-5.22 изисква формален supplier assessment process. При финтех типичната екосистема включва payment gateway, banking API, KYC/AML доставчик, fraud detection платформа, cloud инфраструктура. Всеки е потенциална точка на компрометиране и всеки изисква оценка.
Типичен обхват и времева рамка за финтех компания
Обхват за финтех от 20-80 служители
Типичен СУИС обхват за финтех компания включва:
- Payment processing инфраструктура и API интеграции
- Управление на клиентски данни (финансови, лични)
- Операции по сигурността и мониторинг
- Incident response с регулаторни компоненти
- Third-party management (payment processors, banking партньори)
Функции като HR, счетоводство и офис операции обикновено не включваме, освен ако не обработват чувствителни финансови данни.
Реалистична времева рамка
За финтех компания с 20-80 служители, без предишна ISO 27001 работа, но с някаква PSD2 или GDPR документация:
- Месеци 1-2: GAP анализ, картографиране на регулаторните изисквания (DORA, NIS2 застъпване), определяне на обхвата, оценка на риска
- Месеци 2-4: Разработване на политики и процедури, внедряване на приоритетни контроли - особено incident management с регулаторни пътеки и access controls за финансови системи
- Месец 4-5: Вътрешен одит, отстраняване на несъответствия, обучение на екипа
- Месец 5-7: Сертификационен одит (Stage 1 и Stage 2)
Ако вече имате DORA програма или добра GDPR документация, реалистично е 5 месеца вместо 7. Ако започвате от нулата и имате сложна платежна архитектура, 7 месеца е реалистичното очакване - не 3.
Типични пропуски при финтех ISO 27001
Объркване между DORA и ISO 27001 изискванията. “Покрити сме от DORA” е аналогът на “покрити сме от GDPR” при SaaS. DORA е по-детайлна за ИКТ устойчивост, но ISO 27001 добавя цялостна система за управление - политики, цели, вътрешни одити, прегледи от ръководството. Едното не замества другото.
Подценяване на обхвата на платежни системи. Финтех компаниите с outsourced payment processing понякога смятат, че scope-ът им е малък. Реалността: API интеграциите, достъпът до merchant portals, управлението на API ключовете, логовете от транзакции - всичко това е в обхвата. Обхватът рядко е по-малък, отколкото изглежда отначало.
Третиране на payment processors като trusted. Stripe, Adyen, Checkout.com имат добра документация по сигурността. Но ISO 27001 изисква вашият собствен vendor assessment процес - не само да разполагате с техните SOC 2 доклади. Периодичен преглед, договорни клаузи и процес при промяна на доставчика са задължителни.
Неинтегриран incident response. Финтех компании имат добри технически мониторинг инструменти, но нямат процедура, която свързва техническото засичане с регулаторното докладване. При реален инцидент - платежни данни компрометирани, fraud засечен - кой взима решението, кой се обажда на БНБ, в какъв срок? Тези въпроси трябва да са решени предварително.
Липса на доказателства за криптографски практики. Политиката за криптография съществува, но нямат документирани key rotation записи, нямат процедура за управление при компрометиран ключ, нямат inventory на криптографските материали. Одиторите искат evidence, не само документи.
ISO 27001 и SOC 2 при финтех с US амбиции
Ако целевият пазар включва US финтех партньори или инвеститори, вероятно ще имате нужда и от SOC 2. Припокриването с ISO 27001 е около 70-80% - ако ISO 27001 е направен добре, SOC 2 не е двойна работа. Препоръчваме да планирате SOC 2 от самото начало на ISO 27001 проекта, дори да не го правите веднага.
Как работим с финтех компании
Финтех не е просто SaaS с плащания. Разбираме разликата между PSD2 лицензирани дружества и необхванати от PSD2 финтех платформи, между DORA задълженията на различните типове субекти и между регулаторния контекст на БНБ и общите изисквания.
Работим дистанционно по подразбиране с финтех компании от цяла България - с възможност за присъствени сесии в Sofia Tech Park, когато ситуацията го налага. Повечето от работата - workshops, policy reviews, audit preparation - се случва онлайн, без да спираме вашите операции.
Не идваме с Generic ISO 27001 шаблони. Четем вашата архитектура, вашите интеграции и вашите лицензионни задължения, преди да проектираме каквото и да е.
Ако имате нужда от текущо управление на съответствието след сертификацията - вкл. координация с регулаторни прегледи и поддръжка на СУИС - нашата vCISO услуга е естественото продължение.
Следваща стъпка
Ако ISO 27001 е на радара ви - заради инвеститор, заради БНБ преглед или защото знаете, че трябва - нека поговорим. Ще разберем заедно дали моментът е сега и какво реално означава за вашата компания, вашия лиценз и вашата архитектура.
Без презентации. Честен разговор за вашата ситуация.
Разгледайте пълната ISO 27001 услуга - процес, цени и как работим. За финтех компании с NIS2 задължения вижте и NIS2 услугата.