Исо27тыщ как защита от дурака

очень недурен.

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

Так вот, одним из плюсов стандарта, с написанием номера которого я наконец определился, является то, что при его внедрении созидается пусть и не идеальная, но система управления ИБ, а первейшее преимущество системной ИБ перед островной заключено в ее (кто бы мог подумать) системности.

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

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

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