Закрыть.
Выбор города

Главная  /  База знаний  /  ISO  /  Подготовка к сертификационному аудиту ISO 27001: чек-лист для CISO

Подготовка к сертификационному аудиту ISO 27001: чек-лист для CISO

Подготовка к сертификационному аудиту ISO 27001 — практический чек-лист для руководителя ИБ.

Главная  /  База знаний  /  ISO  /  Подготовка к сертификационному аудиту ISO 27001: чек-лист для CISO

Подготовка к сертификационному аудиту ISO 27001: чек-лист для CISO

Сертификационный аудит ISO 27001 — ответственный этап, от которого зависит получение сертификата. В этой статье — полный чек-лист подготовки для CISO: что проверяет аудитор, какие документы обязательны и какие ошибки стоят сертификата.

Содержание

  1. Зачем CISO нужен чек-лист подготовки к сертификационному аудиту ISO 27001
  2. Stage 1 и Stage 2: что проверяет аудитор на каждом этапе
  3. Обязательная документация СУИБ: полный перечень
  4. Логирование и мониторинг: контроли Annex A, которые проверяют в первую очередь
  5. Управление инцидентами: процедуры, записи, доказательная база
  6. Большой чек-лист CISO: 25 пунктов по категориям
  7. Major и Minor Nonconformities: как избежать критических несоответствий
  8. Надзорные аудиты и ресертификация: что делать после получения сертификата
  9. Итог: пошаговый план действий перед аудитом

Зачем CISO нужен чек-лист подготовки к сертификационному аудиту ISO 27001

Сертификационный аудит ISO 27001 — это не просто формальная проверка документов. Это комплексная оценка того, насколько система управления информационной безопасностью (СУИБ) реально работает в организации. По нашему опыту, даже компании с зрелыми процессами ИБ допускают ошибки при подготовке к сертификации — не потому, что их защита слабая, а потому, что они не понимают логику аудитора. Аудитор проверяет не столько техническую защищённость, сколько управляемость системы: есть ли документированные процедуры, ведутся ли записи, проводится ли анализ со стороны руководства.

Роль CISO (Chief Information Security Officer) в подготовке к аудиту — ключевая. Именно он координирует сбор доказательной базы, проверяет полноту документации и организует внутренний аудит. Однако без структурированного подхода даже опытный руководитель ИБ рискует упустить критически важные пункты. Типичная ошибка — сосредоточиться на технических контролях (файрволы, антивирусы, SIEM), забыв о процессных требованиях: внутреннем аудите по ISO 19011, анализе рисков с актуальным реестром, обучении персонала и управлении изменениями.

Структурированный чек-лист решает эту проблему. Он позволяет системно пройти по каждому разделу стандарта ISO/IEC 27001:2022 (пункты 4–10) и каждому применимому контролю Annex A, убедившись, что для каждого требования есть документ, запись или иное свидетельство выполнения. Именно такой чек-лист мы подготовили для вас в этой статье — с разбивкой по категориям и пояснениями, на что аудитор обращает внимание в первую очередь.


Stage 1 и Stage 2: что проверяет аудитор на каждом этапе

Сертификационный аудит ISO 27001 проводится в два этапа, и понимание различий между ними критически важно для правильной подготовки. Многие организации готовятся «ко всему сразу», тогда как на практике каждый этап имеет свои приоритеты, свой фокус и свои типичные ловушки.

Stage 1 — аудит документации (Document Review). На этом этапе аудитор оценивает готовность организации к основному аудиту. Он запрашивает и анализирует ключевые документы СУИБ: область применения (Scope), политику информационной безопасности, методологию оценки рисков, реестр рисков, план обработки рисков, Заявление о применимости (SoA, Statement of Applicability). Аудитор также проверяет, что проведён как минимум один цикл внутреннего аудита и один анализ со стороны руководства (Management Review). Результат Stage 1 — заключение о готовности к Stage 2, а также перечень замечаний, которые необходимо устранить до основного аудита. Между этапами обычно проходит от 2 до 8 недель — используйте это время для устранения всех найденных пробелов.

Stage 2 — сертификационный аудит (Certification Audit). Основной аудит проводится на площадке организации (или удалённо, если это допускается органом по сертификации). Аудитор проверяет, что задокументированные процедуры реально выполняются: интервьюирует сотрудников, запрашивает записи (логи, протоколы, акты), наблюдает за процессами. На аудите проверяют соответствие всем пунктам стандарта (Clauses 4–10) и применимым контролям Annex A. Типичная ошибка — красивые политики, которые существуют только на бумаге. Аудитор быстро выявит это, задав рядовому сотруднику вопрос: «Расскажите, как вы сообщаете об инциденте ИБ?» Если сотрудник не знает процедуры — это свидетельство несоответствия.

Параметр Stage 1 Stage 2
Цель Оценка готовности документации Проверка реального функционирования СУИБ
Формат Документарная проверка (часто удалённо) На площадке: интервью, наблюдения, выборки
Длительность 1–2 дня 3–5 дней (зависит от масштаба)
Что проверяют Scope, политика ИБ, SoA, реестр рисков, план внутреннего аудита Все контроли Annex A, записи, компетенции персонала, инциденты
Результат Заключение о готовности + замечания Решение о выдаче/отказе в сертификате
Типичная ошибка Неполный SoA, отсутствие внутреннего аудита Политики не внедрены, сотрудники не знают процедур

Практический совет: проведите пробный аудит (mock audit) за 4–6 недель до Stage 1. Это позволит выявить пробелы в документации и устранить их заблаговременно. Подробнее о методологии внутреннего аудита — в нашем материале Внутренний аудит СМК по ISO 19011.


Обязательная документация СУИБ: полный перечень

Стандарт ISO/IEC 27001:2022 чётко определяет перечень обязательной документированной информации. Отсутствие любого из этих документов на Stage 1 практически гарантирует замечание, а на Stage 2 — несоответствие (nonconformity). По нашему опыту, около 40% замечаний на первом этапе аудита связаны именно с неполнотой документации, а не с техническими недостатками.

Стандарт различает два типа документированной информации: документы (политики, процедуры, методологии — определяют «как должно быть») и записи (логи, протоколы, акты — подтверждают «как было сделано»). Аудитор проверяет наличие и того, и другого.

Обязательные документы по пунктам стандарта (Clauses 4–10):

  • Область применения СУИБ (п. 4.3) — границы системы: площадки, подразделения, процессы, ИТ-системы. Должна быть согласована с контекстом организации и требованиями заинтересованных сторон.
  • Политика информационной безопасности (п. 5.2) — утверждена высшим руководством, содержит обязательства по постоянному улучшению и соответствию требованиям.
  • Методология оценки рисков (п. 6.1.2) — критерии принятия рисков, шкалы вероятности и воздействия, подход к идентификации активов и угроз.
  • Реестр рисков и план обработки рисков (п. 6.1.3) — перечень идентифицированных рисков с оценками, выбранные варианты обработки (снижение, принятие, передача, избегание).
  • Заявление о применимости (SoA) (п. 6.1.3 d) — перечень всех 93 контролей Annex A с обоснованием включения или исключения каждого. Подробности составления SoA описаны в статье Внедрение СУИБ по ГОСТ Р ИСО/МЭК 27001.
  • Цели информационной безопасности (п. 6.2) — измеримые, с указанием ответственных, сроков и ресурсов.
  • Записи о компетентности (п. 7.2) — свидетельства образования, обучения, навыков персонала, задействованного в СУИБ.
  • Результаты внутреннего аудита (п. 9.2) — программа аудитов, отчёты, корректирующие действия.
  • Протоколы анализа со стороны руководства (п. 9.3) — входные данные (результаты аудитов, статус инцидентов, метрики), решения и действия.
  • Записи о несоответствиях и корректирующих действиях (п. 10.2) — выявленные проблемы, анализ причин, принятые меры, проверка результативности.

Помимо обязательных документов, стандарт подразумевает наличие дополнительных процедур: управления доступом, управления изменениями, резервного копирования, реагирования на инциденты, управления поставщиками. Формально они не являются «обязательными» в тексте стандарта, но аудитор обязательно спросит, как именно реализованы соответствующие контроли Annex A — и без документированной процедуры доказать выполнение будет крайне сложно.


Логирование и мониторинг: контроли Annex A, которые проверяют в первую очередь

Контроли, связанные с логированием и мониторингом, — одни из самых проверяемых на аудите ISO 27001. Это неудивительно: без качественных логов невозможно ни расследовать инциденты, ни доказать выполнение других контролей. В версии ISO 27001:2022 ключевые требования сосредоточены в контролях A.8.15 (Logging) и A.8.16 (Monitoring Activities).

Контроль A.8.15 — Логирование (Logging). Стандарт требует, чтобы организация определила, какие события подлежат регистрации, обеспечила защиту логов от несанкционированного изменения и удаления, установила сроки хранения и организовала регулярный анализ. На аудите проверяют наличие политики логирования, фактическое ведение журналов событий и их полноту. Типичная ошибка — логи ведутся, но никто их не анализирует. Аудитор запросит свидетельства регулярного анализа: отчёты SIEM, протоколы разбора аномалий, тикеты по результатам мониторинга. Если таких записей нет — контроль считается неэффективным.

Контроль A.8.16 — Мониторинг (Monitoring Activities). Этот контроль расширяет требования к логированию: организация должна не просто собирать логи, а активно отслеживать аномальное поведение в сетях, системах и приложениях. Аудитор ожидает увидеть настроенные правила корреляции в SIEM, пороговые значения для алертов и процедуру реагирования на срабатывания. По нашему опыту, компании средного размера часто имеют SIEM «для галочки»: система установлена, но правила не настроены, алерты не анализируются, а сотрудники SOC перегружены ложными срабатываниями.

Что ещё проверяют из Annex A по теме логирования:

  • A.8.17 (Clock Synchronization) — синхронизация часов всех систем через NTP. Без этого логи с разных источников невозможно коррелировать.
  • A.5.23 (Information Security for Cloud Services) — логирование и мониторинг облачных сервисов, доступ к логам облачного провайдера.
  • A.8.20 (Network Security) — журналы сетевых устройств, мониторинг трафика.
  • A.5.28 (Collection of Evidence) — процедуры сбора и сохранения цифровых доказательств для расследований.

Практическая рекомендация: составьте матрицу логирования — таблицу, в которой для каждого типа системы (серверы, сетевое оборудование, СУБД, приложения, облака) указаны: какие события логируются, где хранятся логи, срок хранения, кто отвечает за анализ, частота проверки. Эта матрица станет ключевым доказательством для аудитора и одновременно рабочим инструментом для вашей команды.

Для кого эта услуга

Для предприятий всех форм собственности

Для предприятий всех форм собственности

Образовательные центры

Образовательные центры

Медицинские организации

Медицинские организации

Предприятия нефтяной, нефтехимической и газовой промышленности

Предприятия нефтяной, нефтехимической и газовой промышленности

Пищевые предприятия

Пищевые предприятия

Строительные и проектные компании

Строительные и проектные компании

О нашей компании

Постоянно сотрудничаем с крупными государственными и международными корпорациями

Четко выполняем требования контролирующих организаций

Непрерывно работаем над улучшением нашего профессионализма

Послепродажная поддержка в правовых аспектах

Беспроцентная рассрочка (до 4 месяцев)

Бесплатная доставка документации по регионам России лично к заказчику

Клиенты

Фуд-торг
Гринлайт
ЭНТЦ

Благодарственные письма



Управление инцидентами: процедуры, записи, доказательная база

Управление инцидентами информационной безопасности — один из «горячих» разделов сертификационного аудита ISO 27001. Аудиторы уделяют ему особое внимание, поскольку именно способность организации обнаруживать, реагировать и учиться на инцидентах демонстрирует зрелость СУИБ. В версии ISO 27001:2022 управление инцидентами охватывается контролями A.5.24 (Information Security Incident Management Planning and Preparation), A.5.25 (Assessment and Decision on Information Security Events), A.5.26 (Response to Information Security Incidents) и A.5.27 (Learning from Information Security Incidents).

Что должно быть документировано:

  • Процедура управления инцидентами — определение ролей (кто принимает решение о классификации, кто координирует реагирование), классификация по критичности (низкая, средняя, высокая, критическая), временные рамки реагирования для каждого уровня, порядок эскалации.
  • Журнал инцидентов — каждый инцидент (и каждое событие безопасности, которое было оценено) должен быть зарегистрирован с указанием даты, описания, принятых мер, статуса, ответственного. На аудите проверяют, что журнал ведётся регулярно и содержит достаточную детализацию для анализа причин.
  • Отчёты о расследовании — для инцидентов средней и высокой критичности аудитор ожидает видеть результаты анализа коренных причин (root cause analysis), рекомендации по предотвращению повторения и свидетельства их выполнения.
  • Уроки извлечённые (Lessons Learned) — контроль A.5.27 прямо требует, чтобы организация использовала информацию из инцидентов для улучшения контролей. Аудитор проверит, обновлялась ли оценка рисков, менялись ли процедуры, проводилось ли дополнительное обучение персонала после значимых инцидентов.

Типичная ошибка — организация заявляет: «У нас не было инцидентов». Для аудитора это красный флаг. Если за 12 месяцев эксплуатации СУИБ не зарегистрировано ни одного события безопасности, это говорит не о совершенной защите, а о неработающем процессе обнаружения. Должны быть хотя бы события, которые были оценены и классифицированы как «не инцидент». Убедитесь, что ваша служба HelpDesk или SOC фиксирует все подозрительные события — даже те, которые в итоге оказались ложными тревогами.

Для организаций, работающих с персональными данными, управление инцидентами пересекается с требованиями 152-ФЗ — подробнее об интеграции этих требований читайте в статье Интеграция ISO 27001 и 152-ФЗ.


Большой чек-лист CISO: 25 пунктов по категориям

Ниже приведён развёрнутый чек-лист подготовки к сертификационному аудиту ISO 27001:2022, сгруппированный по основным категориям. Для каждого пункта указано, какой раздел стандарта или контроль Annex A он покрывает, и что именно аудитор запросит в качестве свидетельства. Используйте этот чек-лист как рабочий инструмент: пройдите по каждому пункту, отметьте статус («готово», «в работе», «отсутствует») и назначьте ответственного за устранение пробелов.

Категория / Пункт проверки Раздел стандарта Что запросит аудитор
Документация и управление СУИБ
1 Область применения СУИБ определена и документирована п. 4.3 Документ Scope с указанием границ, площадок, процессов
2 Политика ИБ утверждена руководством и доведена до персонала п. 5.2 Подписанная политика, свидетельства ознакомления
3 Цели ИБ измеримы и актуализированы п. 6.2 Документ с целями, метрики, отчёт о достижении
4 Роли и ответственности в СУИБ назначены п. 5.3 Матрица ответственности, приказы о назначении
5 Процедура управления документированной информацией п. 7.5 Процедура, реестр документов, контроль версий
Оценка рисков
6 Методология оценки рисков документирована и воспроизводима п. 6.1.2 Методология, критерии оценки, шкалы
7 Реестр рисков актуален (пересмотрен за последние 12 месяцев) п. 6.1.2, 8.2 Реестр рисков с датой последнего пересмотра
8 План обработки рисков связан с контролями Annex A п. 6.1.3 План с привязкой к контролям, статус выполнения
9 SoA содержит обоснование для каждого контроля п. 6.1.3 d SoA с 93 контролями, обоснования включения/исключения
Логирование и мониторинг
10 Политика логирования определяет типы событий и сроки хранения A.8.15 Политика, матрица логирования, настройки SIEM
11 Логи защищены от модификации и удаления A.8.15 Настройки прав доступа к логам, WORM-хранилище
12 Настроен активный мониторинг аномалий A.8.16 Правила корреляции, алерты, отчёты об аномалиях
13 Часы всех систем синхронизированы (NTP) A.8.17 Конфигурация NTP, скриншоты синхронизации
Управление инцидентами
14 Процедура реагирования на инциденты документирована A.5.24, A.5.26 Процедура с классификацией, ролями, SLA
15 Журнал инцидентов ведётся и содержит записи A.5.25 Журнал с записями, карточки инцидентов
16 Проведён анализ уроков извлечённых (Lessons Learned) A.5.27 Отчёты post-mortem, обновления процедур
Управление доступом и персонал
17 Политика управления доступом и процедура предоставления/отзыва прав A.5.15, A.5.18 Политика, заявки на доступ, акты пересмотра прав
18 Пересмотр прав доступа проводится регулярно A.5.18 Акты пересмотра с датами, отключённые учётные записи уволенных
19 Персонал обучен требованиям ИБ и обучение задокументировано п. 7.2, A.6.3 Программа обучения, журнал обучения, тесты
Поставщики и третьи стороны
20 Реестр поставщиков с оценкой рисков ИБ A.5.19, A.5.21 Реестр, договоры с SLA по ИБ, акты проверок
21 Проводится аудит подрядчиков по информационной безопасности A.5.22 Отчёты аудитов поставщиков, чек-листы проверки
Внутренний аудит и улучшение
22 Проведён внутренний аудит СУИБ (минимум 1 цикл) п. 9.2 Программа аудитов, отчёт, корректирующие действия
23 Проведён анализ со стороны руководства (Management Review) п. 9.3 Протокол совещания, входные данные, решения
24 Несоответствия из внутреннего аудита закрыты корректирующими действиями п. 10.2 Реестр несоответствий, акты корректирующих действий
25 Метрики эффективности СУИБ определены и собираются п. 9.1 Dashboard / отчёт с метриками, тренды

Этот чек-лист охватывает ключевые области, которые аудитор проверяет на обоих этапах сертификационного аудита. Рекомендуем распечатать его и пройти совместно с командой ИБ не позднее чем за 8 недель до запланированной даты Stage 1. Каждый пункт со статусом «отсутствует» требует немедленного назначения ответственного и срока устранения. Подробнее об аудите поставщиков и третьих сторон — в материале Аудит подрядчиков: информационная безопасность вендоров.


Major и Minor Nonconformities: как избежать критических несоответствий

Результатом сертификационного аудита ISO 27001 могут быть три типа выводов: наблюдения (observations) — рекомендации по улучшению, не блокирующие сертификацию; незначительные несоответствия (Minor Nonconformities) — отклонения, которые нужно устранить, но сертификат может быть выдан с условием предоставления плана корректирующих действий; значительные несоответствия (Major Nonconformities) — системные нарушения, блокирующие выдачу сертификата до их устранения и повторной проверки.

Понимание разницы между Major и Minor критически важно для CISO, поскольку одно Major-несоответствие может отложить сертификацию на несколько месяцев и потребовать дополнительного визита аудитора (за дополнительную плату). Minor-несоответствия, как правило, можно закрыть в течение 90 дней после аудита, предоставив свидетельства устранения дистанционно.

Тип несоответствия Примеры Последствия Как предотвратить
Major Отсутствует оценка рисков; не проведён внутренний аудит; SoA не содержит обоснований; процесс управления инцидентами полностью отсутствует Сертификат не выдаётся. Требуется устранение и повторная проверка (follow-up audit) Пройти все пункты чек-листа; провести полноценный внутренний аудит за 6–8 недель
Minor Политика ИБ не пересмотрена в указанный срок; один пользователь не прошёл обучение; NTP настроен не на всех системах Сертификат выдаётся с условием: предоставить план корректирующих действий в течение 90 дней Провести mock-аудит; проверить даты пересмотра документов; выверить списки обученных
Observation Метрики СУИБ можно расширить; процедура обработки рисков слишком общая; рекомендуется автоматизировать процесс пересмотра доступа Не блокирует сертификацию. Рекомендация к улучшению, проверяется на надзорном аудите Зафиксировать и включить в план улучшений СУИБ

По нашему опыту, наиболее частые причины Major-несоответствий — это полное отсутствие обязательных процессов (не «плохо задокументированных», а именно отсутствующих) и системная неспособность продемонстрировать работу цикла PDCA (Plan-Do-Check-Act). Например, если организация провела оценку рисков, но не может показать, что риски пересматривались при изменении обстановки, — это может быть квалифицировано как Major. Аудитор должен видеть, что СУИБ — это живая система, а не набор документов, созданных «для аудита».

Ещё одна распространённая проблема — несогласованность документации. Если в политике указано, что пересмотр прав доступа проводится ежеквартально, а по факту последний пересмотр был 8 месяцев назад, аудитор зафиксирует несоответствие. Лучше указать реалистичную периодичность (раз в полгода) и выполнять её, чем написать «ежемесячно» и не выполнять. Аудитор проверяет не амбициозность политик, а их выполнение.


Надзорные аудиты и ресертификация: что делать после получения сертификата

Получение сертификата ISO 27001 — не финальная точка, а начало трёхлетнего цикла. Сертификат выдаётся на 3 года, и в течение этого периода организация проходит ежегодные надзорные аудиты (surveillance audits), а по истечении срока — аудит ресертификации.

Надзорные аудиты проводятся обычно через 12 и 24 месяца после первоначальной сертификации. Их цель — убедиться, что СУИБ продолжает функционировать, развивается и соответствует стандарту. Надзорный аудит короче сертификационного (1–3 дня), но аудитор проверяет полноценно: внутренние аудиты проведены, Management Review состоялся, инциденты обработаны, корректирующие действия закрыты, метрики собираются. Типичная ошибка — «расслабиться» после получения сертификата. Мы видели случаи, когда компании не проводили внутренний аудит между сертификацией и первым надзорным аудитом — это прямой путь к Major-несоответствию и возможному приостановлению сертификата.

Аудит ресертификации проводится на третий год и по объёму близок к первоначальному сертификационному аудиту. Аудитор оценивает, как СУИБ развивалась за три года: обновлялась ли оценка рисков при изменениях в ИТ-инфраструктуре, актуализировался ли SoA, внедрялись ли новые контроли, учитывались ли уроки из инцидентов.

Что важно помнить CISO для поддержания сертификата:

  • Внутренний аудит СУИБ должен проводиться не реже одного раза в год (а лучше — по графику, охватывающему все контроли за 3 года).
  • Management Review — не реже одного раза в год с фиксированной повесткой и протоколом.
  • Реестр рисков пересматривается при значимых изменениях (новые системы, организационные изменения, инциденты) и не реже одного раза в год.
  • Все несоответствия из предыдущих аудитов должны быть закрыты корректирующими действиями с проверкой результативности.
  • Метрики СУИБ (количество инцидентов, время реагирования, процент обученных сотрудников, результаты тестов на фишинг) собираются и анализируются регулярно.

Если вы планируете расширять область сертификации (например, добавить новые площадки или ИТ-системы), это лучше делать в рамках надзорного аудита. Согласуйте изменения с органом по сертификации заранее — как минимум за 3 месяца. Для IT-компаний, которые задумываются о необходимости сертификата, рекомендуем изучить наш материал Зачем ИТ-компании сертификат ISO 27001.


Итог: пошаговый план действий перед аудитом

Подготовка к сертификационному аудиту ISO 27001 — это проект, который требует минимум 3–6 месяцев систематической работы. Ниже — пошаговый план для CISO, основанный на нашем опыте сопровождения десятков сертификаций:

За 6 месяцев до аудита: проведите GAP-анализ текущего состояния СУИБ относительно требований ISO 27001:2022. Определите пробелы в документации и процессах. Составьте план устранения с назначением ответственных и сроков.

За 4 месяца: завершите актуализацию оценки рисков и SoA. Убедитесь, что все применимые контроли Annex A реализованы и для каждого есть документальное подтверждение. Разработайте недостающие процедуры (управление инцидентами, логирование, управление доступом, управление изменениями).

За 2 месяца: проведите полноценный внутренний аудит СУИБ по стандарту ISO 19011. Зафиксируйте все несоответствия и разработайте корректирующие действия. Проведите Management Review с участием высшего руководства.

За 1 месяц: проведите mock-аудит (пробный аудит) силами внешнего консультанта или опытного внутреннего аудитора. Устраните оставшиеся замечания. Подготовьте пакет документов для Stage 1. Проведите awareness-сессию для сотрудников — напомните, что такое СУИБ, как сообщать об инцидентах, какие политики действуют.

За 1 неделю: пройдите по чек-листу из раздела 6 этой статьи. Убедитесь, что для каждого пункта есть актуальное свидетельство. Подготовьте комнату для аудитора, доступ к системам для демонстрации, контактных лиц для интервью.

Подготовка к аудиту ISO 27001 — непростой, но структурированный процесс. При правильном планировании и системном подходе сертификация проходит без Major-несоответствий с первой попытки. Если вам нужна помощь в подготовке к сертификации — специалисты «Астелс» проведут предварительный аудит, помогут разработать недостающую документацию и сопроводят вас на всех этапах — от GAP-анализа до получения сертификата. Свяжитесь с нами для бесплатной консультации.

Была ли полезна вам данная статья?

Да Нет

Отправить запрос

Нажимая кнопку «Отправить», я подтверждаю согласие на обработку персональных данных в соответствии с Политикой конфиденциальности

Ваш менеджер
Кирилл Соколов

Кирилл Соколов

8(800) 70-70-144

info@sertifikat.bz


Услуги