Управление на жизнения цикъл на политиките за ISO 27001, NIS2 и DORA

Имейлът пристигна във входящата поща на CISO Мария Петрова с тихо тупване, което прозвуча като сирена. Беше от външния одитор — предварителен списък с искания за комбиниран надзорен одит по ISO/IEC 27001:2022 и оценка на готовността по DORA. Първата точка изглеждаше проста:

„Моля, предоставете актуалната Политика за информационна сигурност, пълната ѝ история на версиите, доказателства за одобрение от ръководството за всяка версия и записи за комуникирането ѝ към съответния персонал през последните 24 месеца.“

Компанията на Мария, средна по размер fintech платформа, имаше политики. Десетки. Имаше Политика за информационна сигурност, план за реагиране при инциденти, въпросник за сигурност на доставчиците, регистър на риска, процедура за контрол на достъпа, План за непрекъсваемост на дейността и папка, пълна с доказателства за одит. Но файловете бяха разпръснати в SharePoint сайтове, наследени Confluence пространства, имейл нишки, прикачени файлове към тикети и споделени дискове, притежавани от хора, които вече бяха напуснали компанията.

Истинският проблем стана ясен, когато пристигнаха последващите въпроси на одитора.

Кой е одобрил актуалната процедура за инциденти? Защо политиката за сигурност на доставчиците в SharePoint е версия 2.1, а отделът по снабдяване използва версия 1.8? Коя политика е съпоставена с мерките за управление на риска по NIS2 Article 21? Къде е записът, който показва, че персоналът е бил информиран за последната актуализация на политиката? Защо е предоставено изключение за привилегирован достъп, кой е приел остатъчния риск и кога изтича то? Премахнати ли са остарелите документи от оперативна употреба? Колко дълго се съхраняват одитните доклади? Може ли компанията да докаже, че библиотеката с политики е била прегледана след последната съществена системна промяна?

Мария имаше контроли, но нямаше контрол върху контролите.

Това е проблемът с управлението на жизнения цикъл на политиките през 2026 г. Организациите вече не се провалят на одити само защото правило на защитната стена е грешно или липсва тест на резервно копие. Те се провалят, защото документираната информация е фрагментирана, неподходяща за одит, дублирана, остаряла, неконтролирана или откъсната от правните задължения. Съгласно ISO/IEC 27001:2022 клауза 7.5 документираната информация не е административна поддръжка. Тя е оперативната памет на СУИС. По NIS2 тя подпомага одобрението и надзора от ръководния орган. По DORA тя става част от рамката за управление на ИКТ риска и доказателствената следа за устойчивост. По GDPR тя доказва отчетност.

Позицията на Clarysec е ясна: библиотеката с политики не е склад за документи. Тя е управлявана система за доказателства.

Защо управлението на жизнения цикъл на политиките вече е въпрос на ниво управителен съвет

Управлението на жизнения цикъл на политиките е дисциплината за създаване, одобряване, публикуване, комуникиране, преглед, промяна, извеждане от употреба, съхранение и доказване на политики и свързаните с тях записи. То отговаря на въпросите, които одитори, регулатори, клиенти и управителни съвети вече задават рутинно:

1. Кой е собственик на всяка политика?
2. Кой я одобрява?
3. Кои правни, договорни и рискови изисквания удовлетворява тя?
4. Кои контроли и процедури я прилагат?
5. Коя версия е актуална?
6. Кой е бил информиран, обучен или е трябвало да потвърди запознаване с нея?
7. Кои изключения са свързани с нея?
8. Кои записи доказват, че тя функционира на практика?
9. Какво се случва, когато стане остаряла?

ISO/IEC 27001:2022 поддържа тази дисциплина чрез клауза 7.5 относно документираната информация, клауза 5 относно лидерството, клауза 6 относно планирането и третирането на риска, клауза 8 относно оперативния контрол и контролите от Приложение A, обхващащи политики, записи, правни изисквания, доставчици, инциденти, непрекъсваемост, поверителност, регистриране, мониторинг и управление на промените.

Регулаторният натиск е също толкова пряк.

NIS2 Article 20 изисква ръководните органи да одобряват мерките за управление на рисковете за киберсигурността, да осъществяват надзор върху внедряването и да получават подходящо обучение. Article 21 изисква технически, оперативни и организационни мерки, основани на риска, включително политики за сигурност, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурна разработка, оценка на ефективността, киберхигиена, криптография, сигурност на човешките ресурси, контрол на достъпа, политика за управление на активите и автентикация. Корпус от политики без собственост, одобрение и доказателства за преглед отслабва доказуемостта на управленската отчетност.

DORA се прилага от 17 януари 2025 г. и установява единна рамка на ЕС за управление на ИКТ риска, докладване на инциденти, тестване на цифровата оперативна устойчивост, риск от трети страни в областта на ИКТ и договорни изисквания. За финансови субекти, които също са съществени или важни субекти по NIS2, DORA се третира като специфичен за сектора правен акт на Съюза за съответните задължения в областта на киберсигурността. Article 5 изисква отговорност на ръководния орган за рамката за управление на ИКТ риска, политиките, отговорностите, плановете за непрекъсваемост, одитите, политиките за трети страни в областта на ИКТ, каналите за докладване и обучението. Article 6 изисква добре документирана рамка за управление на ИКТ риска, която да се преглежда поне веднъж годишно за финансови субекти, които не са микропредприятия, и да се подобрява въз основа на извлечените поуки.

GDPR добавя изискването за отчетност. Article 5 изисква личните данни да се обработват законосъобразно, добросъвестно, прозрачно, за определени цели, при минимизиране, точност, ограничение на съхранението и сигурност. Article 5(2) възлага на администратора отговорността да доказва съответствие. Това доказване зависи от контролирани записи: решения за правно основание, графици за съхранение, DPIA, когато са приложими, надлежна проверка на обработващи лични данни, записи за нарушения, прегледи на правата за достъп, журнали от обучения и одобрения на политики.

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

Гръбнакът на документираната информация по ISO/IEC 27001:2022

Гръбнакът на защитимата документация е ISO/IEC 27001:2022 клауза 7.5, Документирана информация. Тя изисква организациите да създават, актуализират и контролират документираната информация, необходима за СУИС и изисквана от стандарта.

Практичен начин да се разбере това е документираната информация да се раздели на три слоя:

Zenith Blueprint: 30-стъпкова пътна карта за одитори на Clarysec разглежда това изрично във фазата „основи и лидерство на СУИС“, Step 6: документирана информация и изграждане на библиотеката на СУИС. В него се обяснява, че клауза 7.5 обхваща документацията като цяло, създаването и актуализирането, както и контрола на документираната информация.

Zenith Blueprint превръща това в практически насоки за внедряване:

„Документите трябва да имат подходяща идентификация (заглавие, евентуално номер на документа или уникален идентификатор, автор), подходящ формат … и преглед и одобрение за пригодност преди употреба.“

Той също така формулира оперативното правило, което много организации пропускат:

„Гарантирайте, че лесно се намира само актуалната версия (архивирайте остарелите версии или ги маркирайте ясно като заменени).“

Именно там много внедрявания на СУИС тихо се пропукват. Една политика може някога да е била одобрена, но ако старите версии остават налични, персоналът използва остарели процедури или одиторите не могат да проследят промените, документът вече не е контролиран по смислен начин.

Zenith Blueprint препоръчва създаване на „библиотека с документация на СУИС“ с папки за политики и процедури, оценка на риска и SoA, записи за обучение, одит и преглед, записи за инциденти, активи и инвентар, както и библиотека с контроли от Приложение A. Той също така посочва, че хранилището трябва да бъде „достъпно, но защитено“, като политиките са четими за служителите, а поверителни папки като оценки на риска и записи за инциденти са ограничени.

Това не е просто модел за подреждане на файлове. Това е архитектура на управление.

Моделът на Clarysec за жизнения цикъл на политиките

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

Този жизнен цикъл е по-силен от еднократно одобрение, защото свързва документите с контроли, собственици и доказателства. Той също така поддържа съответствие между рамки. Една-единствена политика за реагиране при инциденти може да се съпостави с контролите за инциденти от ISO/IEC 27001:2022 Приложение A, готовността за уведомяване по NIS2 Article 23, процесите за класификация и докладване на инциденти по DORA, обработването на нарушение на сигурността на личните данни по GDPR, резултатите Respond в NIST CSF 2.0 и очакванията за управление по COBIT 2019.

Какво изискват политиките на Clarysec за преглед, версии и доказателства

Библиотеката с политики на Clarysec е проектирана така, че изискванията към жизнения цикъл на политиките да не остават въпрос на тълкуване.

За SME Information Security Policy-sme - SME задава ясен тригер за преглед:

„Тази политика трябва да се преглежда от Управителя (GM) поне веднъж годишно, за да се гарантира продължаващо съответствие с изискванията за сертификация по ISO/IEC 27001, регулаторните промени (като GDPR, NIS2 и DORA) и развиващите се бизнес потребности.“

Тя също така изисква документирани записи за промени:

„Всички прегледи и промени на политиката трябва да бъдат официално документирани, като ясно се посочват датата, естеството на измененията и одобрението на GM.“

И запазва историческата проследимост:

„Исторически запис на версиите на политиката трябва да се поддържа защитено, за да се демонстрират развитието на политиката и съответствието по време на одити.“

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

SME Governance Roles and Responsibilities Policy-sme - SME добавя изискването за проследимост на управленските решения:

„Всички значими решения по сигурността, изключения и ескалации трябва да бъдат записани и проследими.“

Тази клауза е критична за изключенията от политики. Временно отклонение от MFA, забавен преглед на доставчик или аварийна промяна в съхранението на журналите не трябва да съществуват само в имейл нишки. Те трябва да бъдат свързани със съответната политика, контрол, собственик на риска, решение за остатъчния риск и дата на изтичане.

За централизиране на доказателствата SME Audit and Compliance Monitoring Policy-sme - SME посочва:

„Всички доказателства трябва да се съхраняват в централизирана папка за одит.“

В корпоративни среди Information Security Policy на Clarysec изисква политиките да:

„Бъдат под контрол на версиите и документирани“

и:

„Бъдат комуникирани до всички засегнати страни чрез официални канали за комуникация“

Корпоративната Governance Roles and Responsibilities Policy вгражда концепцията за:

„Собственик на политиката и одобряващ“

Корпоративната Audit and Compliance Monitoring Policy добавя очаквания за съхранение:

„Докладите се съхраняват за срок не по-кратък от шест години (или по-дълго, когато се изисква по закон), съхраняват се защитено и подлежат на контрол на версиите съгласно Политиката за управление на документи и записи (P6).“

Накрая, корпоративната Legal and Regulatory Compliance Policy свързва правните задължения със СУИС:

„Всички правни и регулаторни задължения трябва да бъдат съпоставени с конкретни политики, контроли и собственици в рамките на Системата за управление на информационната сигурност (СУИС).“

Това изискване е мостът между управлението на жизнения цикъл на политиките и доказателствата по NIS2, DORA и GDPR. Без съпоставяне на задълженията компанията може да има документи, но не може да покаже, че тези документи удовлетворяват конкретни правни, договорни или рискови изисквания.

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

Zenith Controls: Ръководство за съответствие между рамки на Clarysec предоставя компаса за съответствие между рамки по тази тема. За ISO/IEC 27002:2022 control 5.1, Политики за информационна сигурност, Zenith Controls го определя като превантивен контрол, който поддържа поверителност, цялостност и наличност, съгласуван е с управлението и концепциите за идентифициране в киберсигурността и е свързан с оперативни способности за управление и управление на политики.

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

Zenith Controls също така подчертава ISO/IEC 27002:2022 control 5.33, Защита на записите, като превантивен и съгласуван с правното съответствие, политиката за управление на активите и защитата на информацията. Това е централно за доказателствата за одит. Zenith Blueprint разширява същата концепция във фазата Controls in Action, Step 23:

„Записите не са просто останки от минали решения. Те са доказателства — за съответствие, за действие, за отчетност.“

И продължава:

„Записите са надлежно защитени от загуба, неоторизиран достъп, подправяне и преждевременно унищожаване“

ISO/IEC 27002:2022 control 5.37, Документирани оперативни процедури, също е релевантен. Zenith Controls го класифицира като превантивен и коригиращ, поддържащ защита и възстановяване. За DORA и NIS2 документираните оперативни процедури са начинът, по който политиката се превръща в повторяемо действие: триаж на инциденти, възстановяване от резервно копие, въвеждане на доставчици, обработване на уязвимости, сигурна разработка, управление на промените, събиране на доказателства и кризисна комуникация.

Заедно 5.1, 5.33 и 5.37 създават контролния триъгълник на жизнения цикъл на политиките:

Зряла СУИС се нуждае и от трите. Политики без записи са декларации. Записи без процедури са непоследователни. Процедури без насока от политики се превръщат в локални навици, а не в управлявани контроли.

Съпоставяне на съответствието между ISO 27001, NIS2, DORA, GDPR, NIST и COBIT

Управлението на отделни политики за ISO 27001, NIS2, DORA и GDPR създава дублиране, противоречия и умора от доказателства. По-добрият модел е да се поддържа една контролирана библиотека на СУИС с метаданни за съпоставяне. Това позволява един корпус от доказателства да удовлетворява множество аудитории за увереност.

NIST CSF 2.0 е особено полезен като комуникационен слой. Неговата функция GOVERN очаква правните, регулаторните и договорните задължения да бъдат разбрани, целите и отговорностите за управление на риска да бъдат дефинирани, политиките да бъдат установени и актуализирани, а резултатите да бъдат оценявани. Методът Organizational Profile също предоставя практически процес: определяне на обхвата на профила, събиране на входни данни като политики, рискови приоритети и изисквания, създаване на текущи и целеви профили, анализ на пропуски и изпълнение на приоритизиран план за действие.

Това е тясно съгласувано с подхода на Clarysec: изграждане на един оперативен модел, подкрепен с доказателства, и след това съпоставянето му навън към NIS2, DORA, GDPR, NIST и COBIT, вместо поддържане на отделни силози за съответствие.

Едноседмичен спринт за изграждане на контролиран пакет от доказателства за политики

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

Ден 1: Създайте регистър на документите

Започнете с електронна таблица, GRC платформа или структуриран списък в SharePoint. Регистърът на документите е индексът, който позволява на одиторите да навигират в корпуса от доказателства.

Не го усложнявайте излишно. Ако регистърът надеждно показва собственик, одобряващ, версия, дата за преглед, съпоставяне и местоположение на доказателствата, той вече решава много проблеми при извличане за одит.

Ден 2: Създайте хранилището

Следвайте структурата от Zenith Blueprint Step 6: политики и процедури, оценка на риска и SoA, записи за обучение и осведоменост, одит и преглед, записи за инциденти, активи и инвентар и библиотека с контроли.

Приложете правила за достъп. Политиките могат да се четат от всички служители. Записите за оценка на риска трябва да бъдат ограничени до екипа на СУИС и ръководството. Записите за инциденти трябва да бъдат на принципа „необходимост да се знае“. Договорите с доставчици трябва да бъдат ограничени до снабдяване, правен отдел, финанси и сигурност. Остарелите документи трябва да бъдат недостъпни за ежедневна употреба, но съхранени за проследимост при одит.

Ден 3: Стандартизирайте заглавните блокове и журналите на промените

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

Това поддържа контрола на документираната информация по ISO/IEC 27001:2022, управленския надзор по NIS2, очакванията за преглед по DORA и отчетността по GDPR.

Ден 4: Свържете изключенията с политиките

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

Например наследена система не може да поддържа MFA за 60 дни. Изключението се свързва с Политика за контрол на достъпа, Регистър на активите, регистър на риска и план за отстраняване. Собственикът на риска одобрява остатъчния риск, а изключението изтича автоматично, освен ако не бъде подновено. Това прилага изискването на Clarysec за управление при SME значимите решения, изключения и ескалации да бъдат записани и проследими.

Ден 5: Изградете пакета от доказателства за одит

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

За реагиране при инциденти включете записи от настолни упражнения, критерии за класификация на инцидентите, списъци с контакти, шаблони за преглед след инцидент и записи на решенията за уведомяване. Това поддържа готовност за поетапно докладване по NIS2 Article 23, класификация на инцидентите по DORA и отчетност при нарушения по GDPR.

Ден 6: Тествайте извличането

Възложете на вътрешен одитор или мениджър по съответствието да извлече доказателства за три въпроса:

1. Докажете, че Политиката за информационна сигурност е била одобрена, комуникирана и прегледана.
2. Докажете, че задълженията за сигурност на доставчиците са съпоставени с изискванията на DORA и NIS2.
3. Докажете, че доказателствата за отчетност по GDPR се съхраняват и защитават.

Ако извличането отнема повече от 30 минути на въпрос, хранилището се нуждае от подобрение.

Ден 7: Представете пред ръководството

Обобщете статуса на жизнения цикъл на политиките в преглед от ръководството:

• Политики, които са актуални, просрочени или с падеж в рамките на 90 дни
• Отворени и изтекли изключения
• Пропуски в доказателствата
• Актуализации на регулаторното съпоставяне
• Одитни констатации
• Коригиращи действия
• Нужди от ресурси

Това затваря цикъла с очакванията за лидерство по ISO/IEC 27001:2022, отчетността на съвета по NIS2 и надзора от ръководния орган по DORA.

Как одиторите ще проверят жизнения цикъл на вашите политики

Различните одитори разглеждат едни и същи доказателства през различни призми.

Одитор по ISO/IEC 27001:2022 започва с контрола на документираната информация. Той ще провери дали изискваните документи съществуват, дали са одобрени преди употреба, дали версиите се контролират, дали документите са налични там, където са необходими, дали поверителните записи са защитени и дали остарелите документи са защитени от непреднамерена употреба. Той ще свърже жизнения цикъл на политиките с лидерството, третирането на риска, оперативния контрол, вътрешния одит и прегледа от ръководството.

Проверяващ, фокусиран върху DORA, ще бъде ориентиран към устойчивостта. Той ще разгледа дали рамката за управление на ИКТ риска е добре документирана, одобрена от ръководството, преглеждана поне веднъж годишно, когато е приложимо, одитирана редовно, подобрявана въз основа на извлечени поуки и свързана с докладване на инциденти, тестване, риск от трети страни, непрекъсваемост и възстановяване.

Регулатор по NIS2 ще иска да види непрекъсната верига от доказателства — от идентифицирането на риска, през мерките за управление на рисковете за киберсигурността, до одобрението от ръководния орган, внедряването и мониторинга. Всяко прекъсване в тази верига може да изглежда като липса на дължима грижа.

Одитор по GDPR или проверяващ по защита на личните данни ще попита дали управленските записи за лични данни демонстрират отчетност: цели на обработване, правно основание, срок за съхранение, технически и организационни мерки, контроли върху обработващите лични данни, записи за нарушения и доказателства за прилагане на политиката.

Одитор по COBIT 2019 или в стил ISACA ще се фокусира върху компонентите на системата за управление: процеси, организационни структури, информационни потоци, политики, роли, култура, умения и услуги. Той ще попита дали собствеността е дефинирана, дали ръководството наблюдава резултатността, дали изключенията се ескалират и дали доказателствата подкрепят функционирането на контролите и управленския надзор.

Едно и също контролирано хранилище за доказателства може да удовлетвори всички тях, но само ако документите са съпоставени, актуални, защитени и проследими.

Чести слабости в жизнения цикъл на политиките, които да отстраните преди пристигането на одитора

Повечето слабости в жизнения цикъл на политиките са базови управленски слабости, повтарящи се в различни среди:

• Политиките съществуват, но нямат определен собственик.
• Одобряващите са неясни, неактуални или твърде ниско в йерархията спрямо риска.
• Политиките са одобрени, но не са комуникирани.
• Датите за преглед се пропускат без ескалация.
• Остарели версии остават налични в споделени папки.
• Процедурите противоречат на политиките.
• Изключенията се одобряват неформално по имейл.
• Правните задължения са съпоставени с рамки, но не и с реални контроли или собственици.
• Доказателствата за одит са разпръснати в лични дискове, тикетинг инструменти и чат съобщения.
• Сроковете за съхранение не са дефинирани или се прилагат непоследователно.
• Записите се съхраняват, но не са защитени от неоторизирано изменение.
• Политиките за доставчици не са свързани с регистри на договорите, надлежна проверка или планове за изход.
• Процедурите за инциденти не са съгласувани с точките за решение относно уведомяване по NIS2, DORA или GDPR.

Тези проблеми създават затруднения при одит, защото подкопават доверието. Ако одиторът не може да се довери на корпуса от политики, той ще навлезе по-дълбоко във функционирането на контролите.

Планът на Мария за отстраняване не беше да напише още една политика. Той беше да създаде единен достоверен източник. Тя определи една официална библиотека с документация на СУИС, мигрира актуалните политики в нея, архивира неконтролираните местоположения, стандартизира полетата за собственик и одобряващ, изгради работни потоци за одобрение, съпостави политиките със задълженията по NIS2 и DORA и предостави на одиторите достъп само за четене до структурирани доказателства. Това, което беше източник на тревога, се превърна в демонстрация на контрол.

Пътят напред с Clarysec

Управлението на жизнения цикъл на политиките не е бюрократична тежест. То е оперативната дисциплина, която прави документираната информация по ISO 27001, управленската отчетност по NIS2, управлението на ИКТ риска по DORA и отчетността по GDPR защитими.

Използвайте Zenith Blueprint: 30-стъпкова пътна карта за одитори, за да изградите библиотеката на СУИС в правилната фаза и последователност, особено Step 6 за документирана информация и Step 22 за управление на политики. Използвайте политиките на Clarysec за SME и корпоративни среди, за да дефинирате изисквания за преглед, одобрение, контрол на версиите, комуникация, проследимост, централизиране на доказателствата и съхранение. Използвайте Zenith Controls: Ръководство за съответствие между рамки, за да съпоставите контролите от ISO/IEC 27002:2022, като 5.1, 5.33 и 5.37, с очакванията за съответствие между рамки, атрибутите на контролите и одитните перспективи.

Преди да купите още един инструмент или да напишете още една политика, отговорете на един въпрос:

Можете ли да докажете, че всяка важна политика има собственик, одобрена е, актуална е, комуникирана е, съпоставена е, подкрепена е с доказателства, прегледана е, защитена е и е изведена от употреба правилно?

Ако отговорът все още е „не“, Clarysec може да ви помогне да изградите готова за доказване библиотека на СУИС, работен поток за жизнения цикъл на политиките и съпоставяне на съответствието между рамки, каквито одиторите, управителните съвети и клиентите очакват през 2026 г. Изтеглете Zenith Blueprint, разгледайте пакетите политики на Clarysec за SME и корпоративни среди или резервирайте оценка на готовността, за да превърнете библиотеката си с политики в защитим актив за съответствие.