Автоматизация на доказателствата за съответствие

Съответствието не е папка с документи — то е доказуемо твърдение, че правилата, които сте описали, наистина се спазват всеки ден. Одиторът не иска да прочете хубава политика; иска да види запис кой е получил достъп, кой е одобрил заявката, кога е тествано възстановяването от архив и кой е минал обучението. Автоматизацията на доказателствата означава тези записи да се събират сами, в момента на действието, в обща одитна следа — така че когато одитът пита, системата вече има отговора.

Защо политиката в PDF не е доказателство?

В много фирми „съответствие“ означава папка с политики: политика за пароли, политика за достъп, план за реакция при инциденти. Документите са важни — те описват как трябва да работи организацията. Но описанието не е доказателство. Политиката казва, че достъпите се преразглеждат на всяко тримесечие; одиторът пита кога е било последното преразглеждане, кой го е направил и на кого е бил отнет достъпът в резултат. Ако отговорът е „някъде го имаме“, доказателството липсва.

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

Кое всъщност иска да види одиторът?

Зад всяко изискване стои един и същ въпрос: кой, какво, кога и с какъв резултат. Одиторът търси проследимост — възможност да проследи едно правило от политиката до конкретното му изпълнение. За няколко типа доказателства този въпрос се задава почти винаги:

1. Достъп до системи — кой има достъп до какво, кога е бил даден и кога отнет. Тук журналът (log) на входовете и промените в правата е основната следа. По темата сме писали подробно в статията Одит на киберсигурността.

2. Одобрения и решения — кой е разрешил дадено изключение, инсталация или достъп. Следата от одобрения показва, че решенията минават през правилния човек, а не се вземат тихомълком.

3. Архивиране и възстановяване — не просто че има архиви, а че редовно се тества дали от тях наистина може да се възстанови работеща система.

4. Обучения и осведоменост — кой служител е минал обучение за сигурност и кога, за да е ясно, че екипът е подготвен, а не само записан.

5. Инциденти — регистър на дейностите при всеки сигнал: кога е засечен, как е реагирано, какво е предприето. Именно тази хронология доказва, че организацията умее да реагира.

Ключово

Доказателството не е нещо, което се пише преди одита — то е нещо, което системата вече е записала, докато хората просто са си вършили работата. Автоматизацията не създава доказателства от нищото; тя събира следите, които и без това се оставят, преди да са се загубили.

Как автоматизацията превръща следите в одитна следа?

Всяка система, която използвате, вече оставя следи. Всеки вход, всяка одобрена заявка, всяко завършено обучение, всяко изпълнено архивиране създава запис някъде. Проблемът никога не е липсата на данни — а че данните живеят разпръснато и никой не ги свързва. Автоматизацията прави точно това свързване: в момента, в който събитието се случи, записът се копира в общ регистър на дейностите, обозначен с време, автор и контекст, така че по-късно да може да се намери за секунди.

Резултатът е, че одитната следа расте сама, непрекъснато, вместо да се сглобява на пристъпи. Когато дойде проверка — вътрешна, партньорска или регулаторна — не започва трескаво търсене, а справка. Този подход е част от по-широкото мислене, което описваме в Какво е автоматизация на бизнес процеси: рутинното събиране и подреждане се поема от системата, а хората се занимават с преценката.

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

Какво изискват NIS2 и ISO 27001 в тази посока?

Регулаторната рамка все по-настоятелно измества фокуса от „имате ли политика“ към „можете ли да го докажете“. NIS2 и националният Закон за киберсигурност поставят изисквания за отчетност и отговорност — организацията трябва да може да покаже как управлява риска, как реагира на инциденти и кой носи отговорност. Без конкретни срокове и членове тук: същината е, че доказуемостта престава да е добра практика и става очакване.

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

Отделно стои защитата на личните данни. При заявка или проверка от КЗЛД същият принцип спасява ситуацията: ако системата пази следа кой е достъпвал лични данни и на какво основание, отговорът е въпрос на справка, а не на разследване. Цялата тази основа — журнали, регистри, следа от одобрения, отчети за архивиране — я изграждаме в рамките на услугата Киберсигурност: не за да мине една проверка, а за да е готова организацията за всяка.

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

Достатъчна ли е една добра политика, за да мина одит?

Не. Политиката описва как трябва да е; одиторът иска доказателство, че така и се случва в реалността. Затова освен документа са нужни записи — журнали за достъп, следа от одобрения, отчети за архивиране — които показват, че правилото се спазва всеки ден, а не само на хартия.

Как автоматизацията събира доказателства, без да товари екипа?

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

Compliance is not a folder of documents — it is a provable claim that the rules you have written down are actually followed every day. An auditor does not want to read a nice policy; they want to see a record of who was granted access, who approved a request, when a restore from backup was tested and who completed the training. Automating evidence means these records collect themselves, at the moment of the action, into a single audit trail — so that when the audit asks, the system already has the answer.

Why is a policy in a PDF not evidence?

In many companies, "compliance" means a folder of policies: a password policy, an access policy, an incident response plan. Documents matter — they describe how the organisation is supposed to work. But a description is not evidence. The policy says access rights are reviewed every quarter; the auditor asks when the last review was, who carried it out, and whose access was revoked as a result. If the answer is "we have it somewhere", the evidence is missing.

This is exactly where the pre-audit panic is born. The organisation has policies but no trace that it enforces them. So the week before the inspection turns into a hunt through emails, spreadsheets and personal folders, to assemble by hand what should have been accumulating on its own. The records exist — they are simply scattered across ten systems and nobody has gathered them in one place.

What does the auditor actually want to see?

Behind every requirement sits the same question: who, what, when and with what outcome. The auditor is looking for traceability — the ability to follow a rule from the policy down to its concrete execution. For a few types of evidence, this question is asked almost every time:

1. System access — who has access to what, when it was granted and when revoked. Here the log of sign-ins and changes to permissions is the core trace. We have written about this in detail in the article Cybersecurity audit.

2. Approvals and decisions — who authorised a given exception, installation or access grant. The approval trail shows that decisions pass through the right person rather than being made quietly.

3. Backup and recovery — not merely that backups exist, but that it is regularly tested whether a working system can genuinely be restored from them.

4. Training and awareness — which employee completed security training and when, so it is clear the team is prepared, not just enrolled.

5. Incidents — an activity record for every alert: when it was detected, how it was handled, what was done. It is precisely this timeline that proves the organisation knows how to respond.

Key point

Evidence is not something written before the audit — it is something the system has already recorded while people simply got on with their work. Automation does not create evidence out of nothing; it gathers the traces that are being left anyway, before they are lost.

How does automation turn traces into an audit trail?

Every system you use already leaves traces. Every sign-in, every approved request, every completed training, every executed backup creates a record somewhere. The problem is never a lack of data — it is that the data lives scattered and nobody connects it. Automation does exactly that connecting: the moment an event happens, the record is copied into a shared activity register, stamped with time, author and context, so that later it can be found in seconds.

The result is that the audit trail grows on its own, continuously, instead of being assembled in fits and starts. When an inspection arrives — internal, from a partner or from a regulator — it does not trigger a frantic search but a simple lookup. This approach is part of the wider thinking we describe in What is business process automation: the routine gathering and ordering is taken over by the system, and people are left to the judgement.

The same principle holds for entirely physical processes. In the case study on digitalizing work cards in manufacturing you can see how every step on the shop floor leaves a record — who, when, with what outcome — and how that trail later serves as evidence during an inspection, without anyone filling in anything extra.

What do NIS2 and ISO 27001 require in this direction?

The regulatory landscape is ever more firmly shifting focus from "do you have a policy" to "can you prove it". NIS2 and the national Cybersecurity Act (Закон за киберсигурност) set requirements for accountability and responsibility — the organisation must be able to show how it manages risk, how it responds to incidents and who bears responsibility. No specific deadlines or articles here: the essence is that provability stops being good practice and becomes an expectation.

ISO 27001 follows the same logic. The standard rests on the idea that every control must be not only implemented but also traceable — with records that show it is working. This is why a well-ordered audit trail does not serve one particular standard but works for all of them at once: the same logs, the same activity register, the same training reports satisfy both the regulator and the certification body. For organisations only now approaching NIS2, a useful starting point is the NIS2 checklist.

Personal data protection stands apart. In a request or inspection from the Bulgarian data-protection authority (КЗЛД), the same principle saves the situation: if the system keeps a trace of who accessed personal data and on what grounds, the answer is a matter of a lookup, not an investigation. This entire foundation — logs, registers, approval trails, backup reports — is what we build within our Cybersecurity service: not to pass one inspection, but to keep the organisation ready for any.

Frequently asked questions

Is a good policy enough to pass an audit?

No. A policy describes how things should be; the auditor wants proof that this is how they actually happen in reality. So beyond the document you need records — access logs, an approval trail, backup reports — that show the rule is followed every day, not just on paper.

How does automation collect evidence without burdening the team?

The systems you already use leave traces with every action. Automation gathers those traces into a shared register at the moment of the event — a sign-in, an approved request, a completed training, an executed backup. That way the evidence accumulates on its own, rather than being assembled by hand a week before the audit.

Автоматизация на доказателствата за съответствие: одитът пита, системата отговаря