Вопросы на собеседовании: GRC-аналитик

Я сопоставляю каждое требование с той целью и тем действием, которые контроль действительно покрывает, а не просто ищу похожие формулировки.

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

Я строю библиотеку вокруг выполняемых действий и создаю одну стабильную запись для каждого отдельного контроля.

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

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

• Требование PCI или пункт договора вносится в реестр обязательств с указанием источника, применимости, владельца и даты вступления в силу.
• Одно или несколько контрольных действий реализуют обязательство, например отключают учётные записи уволенных сотрудников в течение 24 часов.
• Журнал Okta и согласованная заявка на увольнение подтверждают работу контроля за период, но ни один из этих материалов не является самим контролем и не доказывает выполнение всех связанных обязательств.

Я формулирую опровержимое утверждение, в котором заданы проверяемая совокупность, ожидаемое состояние, период и критерии.

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

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

• Ежемесячная выгрузка из системы управления доступом может подтверждать инвентаризацию и проверку доступа, если она создана системой, полна, датирована и связана с утверждённой проверкой.
• В каталоге доказательств я сохраняю исходную систему, параметры отчёта, время выгрузки, охваченную совокупность, ответственного хранителя и неизменяемое место хранения.
• Вывод оформляю отдельно по каждому контролю, поскольку выгрузка может подтвердить полноту совокупности, но не своевременность согласования или отзыва доступа.

Я фиксирую, какая ответственность наследуется, какая остаётся у использующей сервис команды и чем подтверждается граница между ними.

• В записи указываю поставщика, охват сервиса, формулировку контроля, источник подтверждения, срок его действия и использующие системы.
• В части физической безопасности AWS я могу опираться на подходящий отчёт SOC, но наша команда по-прежнему отвечает за выбор региона, IAM, журналирование и обязанности клиента.
• Изменение сервиса, оговорка в отчёте, непокрытый регион или истечение срока подтверждения запускают переоценку, а не молчаливое продолжение доверия.

Сначала я определяю область по бизнес-сервисам и потокам регулируемых данных, а затем выбираю системы и контроли.

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

Я повторно использую результат, только если контроль, область, период, проверяемая совокупность, атрибуты и стандарт подтверждения подходят для второй цели.

• В обосновании повторного использования указываю исходный рабочий документ, компетентность и независимость проверяющего, выборку, отклонения, дату теста и точные покрытые требования.
• Проверка доступа для SOC 2 может поддержать ISO по тем же системам и за тот же период, но не PCI, если его совокупность включает дополнительные системы CDE.
• Если сроки или критерии различаются, провожу проверку последующего периода либо дополнительный тест и фиксирую оставшийся пробел вместо копирования вывода.

Я отмечаю общий контроль осведомлённости как частично покрывающий требование и оформляю обучение по ролям как дополнительное требование или действие.

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

Я совместно версионирую исходное требование, решение о сопоставлении и контроль, чтобы выводы за прошлые периоды можно было воспроизвести.

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

Я веду его как поэтапный проект подтверждения: определяю область и критерии, устраняю пробелы готовности, обеспечиваю работу контролей в течение периода, поддерживаю тестирование и закрываю отчёт.

• По итогам оценки готовности должны быть определены граница системы, обязательства сервиса, выбранные Trust Services Criteria, матрица контролей, владельцы, план доказательств и реестр пробелов.
• До начала периода ключевые контроли внедряются, а владельцы учатся по графику предоставлять полные совокупности и воспроизводимые доказательства.
• Во время аудиторских процедур я организую сквозные разборы, запросы материалов от клиента, выборки, отклонения, ответы руководства, письменные заявления и итоговую проверку отчёта вместе с аудиторской фирмой CPA.

Я рассматриваю Type II как ограниченное областью и периодом подтверждение, а не как общий знак надёжности поставщика.

• Сначала сопоставляю описание системы, охваченные услуги и площадки, выбранные Trust Services Criteria и период отчёта с нашим способом использования сервиса.
• Затем изучаю процедуры и результаты тестов контролей, отклонения и ответы руководства, оценивая их распространённость и значение для нужных нам контролей.
• Наконец, связываю CUECs с нашими обязанностями и проверяю метод учёта субсервисных организаций, их дополнительные контроли и пробелы в покрытии.

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

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

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

• Я фиксирую владельца, событие запуска, системы, шаги, периодичность, источник совокупности, сохраняемые доказательства, исключения и передачи между командами.
• Владелец показывает один недавний элемент от возникновения до согласования и завершения, а я сверяю его с письменным описанием контроля.
• Рабочий документ содержит участников, дату, ссылки на материалы, недостатки конструкции и последующие действия, но не выдаёт такой разбор за полную проверку эффективности работы за период.

Я проверяю способ формирования совокупности до того, как полагаться на выбранные из неё элементы.

• Пакет материалов по запросу аудитора содержит исходную систему, название отчёта или запрос, параметры, охваченные даты, фильтры, число строк, время выгрузки и составителя.
• Я сверяю количество с независимым источником, проверяю первую и последнюю даты, исследую исключённые статусы и сохраняю созданный файл вместе с параметрами.
• Если выгрузка Jira не включает аварийные изменения или API вернул не все страницы, я формирую совокупность заново до выбора образцов аудитором.

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

• Матрица контролей задаёт периодичность и ожидаемые атрибуты, например инициатора, согласующего, временную отметку, результат теста и подтверждение закрытия для каждого изменения.
• Я передаю полную совокупность в воспроизводимом формате и веду указатель, чтобы любой выбранный элемент можно было получить без изменений.
• Я отслеживаю выбранные элементы, замены, отсутствующие доказательства, отклонения и сроки, но не подставляю удобные образцы без документированной причины аудитора.

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

• Поставщик расчёта заработной платы может требовать от клиента разрешать доступ пользователям, проверять исходные данные расчёта и удалять доступ уволенных сотрудников.
• Клиент связывает каждый применимый CUEC с внутренним владельцем, процедурой, доказательством и тестом либо документирует причину неприменимости.
• Немодифицированное мнение о поставщике не покрывает невыполнение CUEC клиентом, поэтому раздел CUEC должен входить в рабочий документ по проверке отчёта.

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

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

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

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

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

• В записи указываю ожидаемую работу контроля, обнаруженный элемент и даты, причину, размер совокупности, длительность и возможное компенсирующее действие, после чего ищу аналогичные случаи.
• Ответ описывает факты, риск, немедленное исправление, корректирующее действие, владельца, срок и доказательство эффективности, не пытаясь обесценить исключение.
• Аудитор независимо оценивает частоту, распространённость, другие доказательства и влияние на отчёт, а устранение причины не стирает первоначальный результат теста.