Как обеспечить соответствие IT требованиям во время аудита

Аудиторы обычно не выявляют проблему, возникшую в день аудита. Он выявляет недостатки, которые существовали в IT-среде месяцами: неконтролируемые административные доступы, неутвержденные изменения, непроверенные резервные копии или документацию, не соответствующую фактической ситуации. Поэтому вопрос как обеспечить соответствие IT требованиям во время аудита — это не о быстро собранных файлах. Это о доказуемом IT-управлении в повседневной работе.

В малом и среднем предприятии эта задача часто ложится на финансового директора, операционного директора или руководителя компании, хотя им не обязательно быть IT-специалистами. Задача руководства — обеспечить четкую ответственность, прозрачность рисков и партнера, способного превратить технические требования в проверяемые процессы.

Аудит проверяет не только документы, но и контроль

IT-аудит может быть связан с требованиями клиента, стандартом ISO, применимостью GDPR, NIS2, условиями страховщика, due diligence сделки или внутренней оценкой рисков. Конкретные требования различаются, однако аудитор почти всегда хочет получить ответ на три вопроса: что собой представляет IT-среда компании, кто ею управляет и как можно доказать, что контроли работают.

Одной политики недостаточно. Если политика управления доступом предусматривает регулярный пересмотр прав пользователей, аудитору понадобится доказательство проведенного пересмотра, принятых решений и исправлений. Если политика резервного копирования устанавливает тесты восстановления, нужно будет показать результаты тестов, ответственное лицо и устранение выявленных проблем.

Именно здесь возникает важное различие между формальным соответствием и управляемой средой. Формальное соответствие хорошо выглядит в папке. Управляемая среда способна выдержать проверку даже тогда, когда аудитор выбирает случайного сотрудника, систему или период времени.

Как обеспечить соответствие IT требованиям во время аудита без поспешных решений

Самый надежный путь — начать с объема аудита. Прежде чем собирать доказательства, нужно понять, какие системы, местоположения, группы пользователей, виды данных и поставщики включены в аудит. Например, финансовая система может находиться в облачном сервисе, данные клиентов — на другой платформе, а файловый обмен — на локальном сервере. Если эти границы не ясны, команда либо готовит слишком мало, либо тратит время на информацию, которая аудиту не нужна.

Назначьте одного ответственного за координацию

Во время аудита нужен один контактный центр, который управляет списком запросов, сроками, ответами и версиями доказательств. Это не значит, что этот человек должен отвечать на все технические вопросы. Он обеспечивает, чтобы аудитору не давались противоречивые ответы и чтобы чувствительная информация не распространялась шире, чем необходимо.

В хорошо организованном процессе IT-партнер подготавливает технические доказательства, владельцы систем подтверждают бизнес-процессы, а руководство принимает решения о принятии рисков, бюджете и приоритетах. Такое разделение особенно важно для компаний без полного внутреннего IT-отдела.

Формируйте комплект доказательств, а не груду документов

Аудитору легче оценить упорядоченный, прослеживаемый материал, чем сотни несвязанных снимков экрана. Каждый контрольный пункт должен быть связан с конкретным доказательством, ответственным лицом и датой. Снимки экрана полезны, но редко достаточны как единственное подтверждение, поскольку показывают лишь один момент.

Обычно полезны следующие категории доказательств:

• актуальный список IT-активов, систем и обработчиков данных;
• отчеты о доступах пользователей, учетных записях администраторов и многофакторной аутентификации;
• журналы выполнения резервного копирования, тестов восстановления и инцидентов;
• запросы на изменения, утверждения и доказательства внедрения;
• политики безопасности, оценки рисков и протоколы регулярных проверок.

Важно учитывать контекст. Статус резервных копий «успешно» еще не доказывает, что компания сможет восстановить критическую систему за приемлемое время. Напротив, регулярный тест восстановления с зафиксированным результатом, выявленными ошибками и планом исправления дает гораздо более убедительное доказательство.

Проверьте доступы и изменения до того, как это выберет аудитор

Управление доступом — один из самых частых аудиторских рисков. Особое внимание следует уделять учетным записям бывших сотрудников, общим административным пользователям, удаленным доступам поставщиков и учетным записям без многофакторной аутентификации. Не всегда экономически оправдано внедрять сложную платформу управления идентификацией, но должен быть процесс, который регулярно проверяет, кому действительно нужен доступ и кто его утвердил.

Аналогичный принцип относится к изменениям в инфраструктуре. Срочное изменение может быть обоснованным, если нужно устранить инцидент безопасности или сбой в работе. Однако даже срочное изменение после этого должно быть задокументировано: что было изменено, почему, каков был риск и кто утвердил дальнейшие действия. Аудит оценивает не только то, была ли ошибка устранена, но и то, может ли компания управлять последствиями.

Преобразуйте IT-среду в проверяемую систему контроля

Соответствие становится значительно проще, если IT-управление основано на регулярном ритме. Ежемесячный обзор резервных копий, патчей, предупреждений безопасности и открытых рисков создает исторический комплект доказательств. Ежеквартальный пересмотр доступов позволяет своевременно заметить избыточные привилегии. Как минимум раз в год следует оценивать планы реагирования на инциденты и восстановления работы, особенно после существенных изменений в системах или структуре компании.

Контроли должны быть соразмерны размеру компании и риску. Для производственного предприятия с непрерывной работой критически важным может быть время восстановления и резервное подключение к интернету. Для компании, оказывающей профессиональные услуги, главным риском может быть конфиденциальность данных клиентов и защита почтовых учетных записей. Одинаковый контроль для всех — не цель; цель — обоснованно снизить наиболее значимый риск.

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

В день аудита сохраняйте контроль над процессом

Интервью аудита следует организовывать с соответствующими специалистами, а не оставлять аудитору самостоятельно искать информацию в организации. Перед ответом стоит уточнить объем вопроса и запрошенный период. Это снижает риск того, что сотрудник добросовестно предоставит неполную или вводящую в заблуждение информацию.

Не нужно скрывать недостатки. Если контроль не работал, профессиональный подход — описать факты, влияние, компенсирующие меры и срок устранения. Аудитора обычно больше беспокоит неустраненный риск без владельца, чем четко идентифицированная проблема с реальным планом действий.

Следует соблюдать информационную безопасность и в самом аудите. Конфигурации систем, отчеты об уязвимостях, данные клиентов и журналы администраторов могут быть чувствительными. Доказательства следует передавать в контролируемой среде, ограничивать доступ и, при необходимости, скрывать данные, несущественные для цели проверки. Полная прозрачность не означает неконтролируемое раскрытие данных.

После аудита внесите исправления, которые снижают бизнес-риск

Отчет аудита — это не только оценка соответствия. Это список приоритетов для руководства. Для каждого замечания следует определить уровень риска, ответственного, бюджет, срок и способ проверки результата исправления. Некоторые вопросы можно решить быстро, например, отключив устаревшие учетные записи. Другие требуют изменения архитектуры, нового решения резервного копирования или внешней экспертизы.

В практике KSK IT готовность к аудиту рассматривается как часть непрерывного управления инфраструктурой: документация, резервные копии, доступы, мониторинг безопасности и способность к восстановлению не могут быть отдельными проектами, которые активируются только перед проверкой.

Самый ценный результат аудита — не отчет без замечаний. Это уверенность руководства в том, что компания знает свои IT-риски, может обосновать принятые решения и продолжать работу даже при инциденте. Если эта уверенность основана на регулярно проверяемых контролях, следующий аудит уже не будет чрезвычайной ситуацией.