В нормальных условиях аудит проводится всегда как минимум дважды: в первый заход находят "что не так", во второй заход контролируют, исправлены ли проблемы.
Профессиональные аудиторы подвержены профессиональной деформации и отталкиваются всегда от "
anchor" в своих ожиданиях. Ещё до появления на объекте и сбора эвиденса типовой аудитор имеет представления о типовых проблемах и их типовом объёме основываясь на истории предыдущих аудитов в соотв. отрасли.
Нет смысла слишком отличаться от "типажа" в своей отрасли -- достоинства пропустят, а недостатки увидят обязательно, это ещё одна проблема психологии аудитора -- он настроен на то, чтобы находить недостатки, достоинства получают внимания непропорционально меньше. Поэтому важно быть середнячком и иметь всё "как у всех".
Для того, чтобы обыгрывать анкор, аудиторам нужно "бросить кость". Идеальных объектов нет, более того, нет никакого смысла доводить их до идеала -- любой риск имеет свою цену, которая должна а) качественно меньше цены защищаемого ассета б) как можно дешевле уменьшать риск до приемлемого значения, диктуемого 1) уровнем принятия риска менеджментом 2) регуляциями, т.е. PCI DSS, HITRUST, HIPAA & HITECH, ISO 27000 series and so on.
Для этого ответственный за встречу <s>ревизора</s> должен выявить среди имеющихся недостатков такие, которые а) типовые для индустрии, на них будут смотреть и ожидать их увидеть б) относительно легко устранимые, low hanging fruit. Такие недостатки не нужно исправлять до первого аудита, в разумных пределах. В этом случае их а) найдут и б) их будет просто исправить.
Если "кость" не "бросать", а черезчур идеалить, можно оказаться в ситуации, в которой, не найдя ожидаемого, аудиторы начнут копать глубже среднего. А нам не особо нужно выставлять напоказ своих скелетов в шкафу. Вдобавок, если устранить легкоустранимые недостатки до первого аудита, можно оказаться в ситуации, в которой внедрение рекомендованных контролов, соответствующих обнаруженным недостаткам, будет дорогостоящим, в конечном счёте в деньгах, но в основном во времени и их можно не успеть устранить до второго аудита, а это провал.
Всё это имеет пересечение с реальными проблемами инфобеза процентов на 35. Реальные проблемы это
1) эшелонированная оборона от малспама, включащая в себя сэндбоксинг, все типовые анти-спам техники, анти-фишинговые тренинги персонала, trusted execution решения особенно для executables запускаемых из %userprofile%, обученный персонал security operations для своевременного реагирования если всё это было обойдено.
2) микросегментация
3) проблема доступа к личным имэйлам с работы
4) мимикатз и общий харденинг ADDS
5) DLP хотя бы в небольшом проценте случаев способная предотвратить/детектировать эксфильтрацию
Аудиторов же интересует преимущественно чтобы пароли были комлексные, менялись не реже чем раз в 90 дней, да патчи применялись не позже чем 60 дней и чтобы это было "в основном" а не "тотально".