Тема 6.4 — Управление и обеспечение гарантий

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

Почему это важно в здравоохранении и уходе#

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

В то же время у управления в здравоохранении и уходе заслуженная репутация медленного, ритуального и оторванного от поставки. Команды высиживают заседания советов, штампующие уже принятые решения, заполняют шаблоны, которые никто не читает, и смотрят, как янтарные риски зеленеют за неделю до обзора, только чтобы эффектно провалиться после него. Это парадокс, который нужно разрешить. Ответ — не меньше управления и не больше; это соразмерное управление, масштабируемое по риску и ценности, дающее ясным людям ясную подотчётность и производящее честную информацию достаточно быстро, чтобы на неё действовать. Эта тема показывает, как это построить и как наслоить независимые гарантии сверху, чтобы подотчётные люди — и общество — могли быть уверены, что контроли действительно работают. Она тесно связана с темой 1.6 — Клиническая безопасность и управление рисками, темой 1.7 — Управление информацией, защита данных и кибербезопасность, темой 5.3 — EPPM и темой 10.4 — Видимость для CEO и старших руководителей.

Ключевые понятия#

Управление — система прав решений, подотчётности и надзора, посредством которой организация направляет и контролирует то, что делает. В цифровом здравоохранении и уходе вы на самом деле управляете тремя пересекающимися областями управления одновременно. Корпоративное управление охватывает стюардство совета над организацией в целом: финансы, стратегия, риск и юридические обязанности. Клиническое управление — рамка, посредством которой организации здравоохранения подотчётны за непрерывное улучшение качества и безопасности ухода. Управление информацией охватывает то, как организация обращается с данными законно, безопасно и этично. Цифровая услуга затрагивает все три; если вы управляете только одной, остальные застанут вас врасплох.

Подотчётность в одной точке — хребет хорошего управления. Ответственный руководитель (Senior Responsible Owner, SRO) — единственное названное лицо, лично подотчётное за достижение программой или крупным проектом целей и реализацию выгод, — роль, популяризированная британским правительством, но универсально полезная. Права решений ниже SRO делаются явными через матрицу распределения ответственности, обычно в форме RACI (responsible, accountable, consulted, informed), предотвращающую два классических провала: «все думали, что кто-то другой этим владеет» и «все пытались им владеть».

Гарантии (assurance) отличаются от управления. Управление — акт направления и решения; гарантии — независимое, объективное подтверждение, что управление и контроли действительно работают как задумано. Доминирующая ментальная модель — «три линии защиты»: первая линия — операционное управление, владеющее риском и управляющее им изо дня в день; вторая линия — надзорные функции (риск, комплаенс, клиническая безопасность, управление информацией), задающие политику и оспаривающие; а третья линия — внутренний аудит, независимый от обеих и отчитывающийся перед советом. Внешние регуляторы и аудиторы образуют де-факто четвёртую линию.

Два дальнейших понятия скрепляют систему. Аппетит к риску — количество и тип риска, которые организация готова принять в стремлении к своим целям; без него эскалация произвольна. А журнал рисков — часто расширяемый до журнала RAID (риски, допущения, проблемы, зависимости) на той же дисциплине, что и реестр рисков, — рабочая запись, удерживающая поставку честной. Точки обзора обеспечиваются стадийными гарантиями, такими как фазово-шлюзовой процесс и, в британском правительстве, шлюзовые обзоры, проводимые Infrastructure and Projects Authority (IPA). Выше уровня любого отдельного проекта находится управление рисками предприятия — общеорганизационная дисциплина выявления и управления рисками, способными помешать всему предприятию достичь целей, а не отношения к цифровому, клиническому, финансовому, кибер- и операционному риску как к отдельным силосам.

Лучшие практики#

1. Назовите одного подотчётного SRO и имейте это в виду всерьёз. Назначьте одно, достаточно старшее лицо, лично подотчётное за результат, имеющее полномочия принимать решения и остающееся с программой достаточно долго, чтобы с него можно было спросить. Впишите его подотчётность в круг обязанностей и цели. Противьтесь соблазну размазать подотчётность по комитету: комитеты консультируют и решают коллективно, но не могут быть подотчётны, потому что разделённая подотчётность — отсутствующая подотчётность.

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

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

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

5. Используйте интегрированные гарантии и стадийные точки обзора. Вместо заказа несогласованных обзоров планируйте интегрированный график гарантий и одобрений, согласующий обзоры клинической безопасности, управления информацией, технические и коммерческие с одними и теми же точками решений. Принимайте шлюзовые обзоры на важных переходах — перед выделением денег, перед построением, перед запуском — по образцу шлюзовых обзоров IPA и, для обращённых к публике цифровых услуг, оценок услуг, начатых Government Digital Service (GDS) и адаптированных NHS. Хороший шлюз — поддерживающий вызов, снижающий риски следующей фазы, а не экзамен, который нужно обыграть.

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

7. Ведите живой журнал RAID и Board Assurance Framework. Поддерживайте журнал RAID, пересматриваемый каждый цикл поставки, где каждая запись имеет владельца, дату, оценку и активно прорабатывается, — а не кладбище устаревших янтарных пунктов. На уровне организации ведите Board Assurance Framework (BAF), сопоставляющую ваши главные стратегические риски с действующими контролями и гарантиями, что эти контроли работают, и выставляющую пробелы, где вы полагаетесь на надежду. BAF позволяет совету увидеть на одной странице, действительно ли защищены его важнейшие цели.

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

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

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

Вопросы для обсуждения с командой#

1. Где подотчётность в одной точке подлинно ясна в нашей самой важной цифровой работе и где она — удобная выдумка? Пройдитесь по трём главным инициативам и спросите для каждой, кто лично ответил бы перед советом в случае провала. Если честный ответ «совет», «программа» или имя, которое постоянно меняется, у вас пробел. Проверьте, есть ли у названного SRO полномочия и время, которых требует роль, или он — номинальная фигура, пока реальные решения принимаются в другом месте. Подумайте, не подрывается ли подотчётность матрицей, в которой SRO не может направлять людей, ведущих поставку. Обсудите, как защищается непрерывность, когда SRO уходят, поскольку подотчётность, обнуляющаяся при каждой реорганизации, вообще не подотчётность. Цель — не винить людей, а убедиться, что когда что-то идёт не так, один наделённый полномочиями человек отвечает за то, чтобы исправить.

2. Соразмерно ли наше управление или мы применяем тяжёлый процесс к малорисковой работе и наоборот? Нанесите текущие советы, шлюзы и шаги одобрения на карту относительно реального риска и ценности того, что через них проходит. Ищите малорисковое изменение, ждавшее шесть недель совета, заседающего раз в месяц, и высокорисковое клиническое изменение, проскользнувшее по слову самой команды. Спросите, обходят ли команды управление, потому что оно слишком медленное, — само по себе серьёзный сигнал риска. Подумайте, опубликовали ли вы ясные уровни и пороги или всё по умолчанию получает максимальную церемонию из осторожности. Обсудите, где вы могли бы безопасно делегировать решения, чтобы двигаться быстрее, и где вы были опасно легки. Цель — система, где вес управления видимо следует за весом риска.

3. Как бы мы узнали, что наша отчётность говорит нам правду? Обсудите конкретные недавние примеры, где статус перешёл с зелёного на красный с малым предупреждением, и спросите, каковы были ранние сигналы и почему они не всплыли. Изучите, отчитываются ли руководители поставки и функции гарантий по одним и тем же фактам или по отдельным, удобно расходящимся версиям. Подумайте, что происходит, социально и профессионально, с тем, кто здесь сообщает красный статус: его благодарят или наказывают? Спросите, видит ли ваш совет независимые гарантии наряду с собственным отчётом руководства или только последний. Изучите, измеряют ли ваши дашборды то, что предсказывает проблемы, или только то, что легко сделать зелёным. Цель — построить культуру, где честные плохие новости идут быстро, потому что система управления, не способная слышать плохие новости, не способна управлять.

4. Записали ли мы наш аппетит к риску достаточно конкретно, чтобы команда могла по нему действовать, или это лозунг? Возьмите живой риск одной из ваших программ и спросите, могли бы люди, ближайшие к нему, по заявленному аппетиту сказать, лежит ли он внутри линии или вне её. У большинства организаций есть заявление об аппетите к риску, которое хорошо читается и ничего не решает: «мы придерживаемся сбалансированного подхода к риску» не говорит клиницисту, терпим ли необнаруженный дефект отображения аллергий. Обсудите, выражен ли аппетит по областям — безопасность пациентов, данные, поставка, финансы, репутация, — потому что единый глобальный показатель скрывает, что у вас может быть нулевой аппетит к дефектам клинической безопасности и реальный аппетит к срыву сроков. Изучите, действительно ли эскалация привязана к аппетиту, так что всё вне него поднимается автоматически с названным владельцем и сроком, а не зависит от того, что кто-то решит это поднять. Подумайте, кому принадлежит аппетит и как часто он пересматривается, поскольку установленный раз и никогда не пересматриваемый аппетит расходится с реальным миром. Честный ответ называет недавнее решение, которое заявление об аппетите подлинно сформировало, и признаёт, где оно сейчас слишком расплывчато, чтобы кусаться.

5. Есть ли у наших шлюзов и обзоров гарантий зубы или проваливающиеся программы проплывают через них? Оглянитесь на последние шлюзовые обзоры или оценки услуг и спросите, остановил ли, приостановил или существенно перестроил работу хоть один из них: если каждая программа прошла каждый шлюз, ваши шлюзы почти наверняка театр. Обсудите, воспринимаются ли обзоры как поддерживающий вызов, снижающий риски следующей фазы, или как экзамен, который нужно обыграть, с пакетом доказательств, подобранным для обеспечения прохода. Подумайте, приходят ли гарантии клинической безопасности, управления информацией, технические и коммерческие в одни и те же точки решений или как россыпь несогласованных обзоров, изматывающих команды, не добавляя уверенности. Изучите, какими полномочиями реально обладает рецензент шлюза: может ли он задержать запуск и поддержат ли его, если он это сделает, или коммерческое давление его переборет? Выясните, не являются ли те, кто поставляет, фактически и теми, кто обеспечивает гарантии, — потому что шлюз, управляемый оптимистами, — не гарантии. Цель — обзор, который не смогла бы пережить серьёзная проблема, поскольку шлюз, который ничто никогда не проваливает, — расход без контроля за ним.

6. Какие из рисков, способных реально нас потопить, не принадлежат ни одному проекту и кто ими владеет? Перечислите провалы, наиболее способные остановить ваши цифровые услуги, — стареющее хозяйство унаследованных систем, кибератака, чрезмерная зависимость от одного поставщика, рабочая сила, неспособная управлять новыми инструментами, — и спросите для каждого, в чьём реестре он числится. Эти сквозные риски опасны именно потому, что принадлежат всем и поэтому никому, проваливаясь в щели проектного управления. Обсудите, ведёте ли вы реестр рисков предприятия уровня совета, связывающий цифровой, клинический, финансовый, кибер- и операционный риск, или каждый управляется в своём силосе, слепом к остальным. Подумайте, идёт ли риск, замеченный командой поставки, вверх до совета узнаваемо или смягчается с красного до янтарного до зелёного на каждом уровне, пока совет не видит одни заверения. Изучите, есть ли у каждого сквозного риска названный исполнительный владелец с полномочиями действовать по программам. Честный ответ сталкивается с разрывом между знанием, что каждая программа примерно на курсе, и знанием, находится ли организация в целом внутри своего аппетита.

На практике: пример из здравоохранения и ухода#

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

Вначале подотчётность размыта. Три директора по информации чувствуют себя отчасти ответственными, поставщик ведёт график, а совет программы из восемнадцати человек тратит заседания на получение обновлений, а не на решения. Отчётность зелёная. Затем всплывает «почти-ошибка»: аллергия на лекарство, записанная в одной системе, не отображается в другой, и клиницист едва не назначает препарат, к которому у пациента аллергия.

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

Гарантии отделяются от поставки. Офицер клинической безопасности и руководитель по управлению информацией отчитываются независимо и могут эскалировать через SRO до руководителей ICS; работа над общей записью добавляется в Board Assurance Framework каждого партнёра. Интегрированный график гарантий задаёт три шлюза — перед дальнейшим построением, перед пилотом, перед полным развёртыванием, — каждый сочетает обзоры клинической безопасности, управления информацией, технические и доступности, в духе шлюзовых обзоров IPA и оценок услуг NHS. Журнал RAID пересматривается раз в две недели, а дефект отображения аллергий записан как красная проблема с владельцем по имени и фиксированной датой устранения.

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

Секторные линзы#

Стартап#

Стартапу в области технологий здравоохранения редко нужны советы и шлюзовые обзоры, но ему нужно самое необходимое рано, потому что регуляторы, покупатели и инвесторы спросят. Назовите одного подотчётного основателя или руководителя за клиническую безопасность и одного — за защиту данных, ведите лёгкий журнал RAID и запишите свой аппетит к риску, хоть на одной странице. Ловушка — считать управление чем-то, что можно приделать позже; дооснащение доказательствами безопасных, законных решений быстро движущегося продукта мучительно и порой невозможно. Стройте минимально жизнеспособное управление, которое узнал бы серьёзный покупатель NHS, и позвольте ему расти вместе с вами, а не прыгать от ничего к бюрократии за ночь.

Малый бизнес#

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода или клиника на одной площадке — несёт те же законные обязанности по клинической безопасности и защите данных, что и крупный траст, но без комитета по аудиту, внутреннего аудита и часто без выделенного ИТ-персонала для их выполнения. Дисциплина управления здесь — радикальная соразмерность: один названный человек, подотчётный за клиническую безопасность, и один — за управление информацией (в очень малой организации это может быть один и тот же старший клиницист или партнёр), одностраничный аппетит к риску и короткий журнал RAID, который действительно пересматривается, а не подшивается. Опирайтесь на рамки, которых уже ожидают ваши регуляторы, — Data Security and Protection Toolkit, требования CQC и любые обязательства клинической безопасности, которым должны отвечать ваши поставщики, — и пусть гарантии ваших поставщиков ПО (их дела безопасности по DCB0129, их сертификаты) делают работу, которую вы сделать не можете. Реалистичная ловушка — не театр управления, а пренебрежение управлением: безопасные, законные решения, принимаемые неформально и никогда не записываемые, так что когда приходит инцидент или инспекция, вы не можете показать, что вы решили и почему. Держите след доказательств лёгким, но реальным, потому что для малого бизнеса цель — защитимые решения с минимальными затратами, а не машина управления, которую нечем укомплектовать.

Предприятие#

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

Правительство#

Национальные и региональные органы — NHS England, ICB, органы на расстоянии вытянутой руки — действуют под законной подотчётностью, контролем государственных расходов и формальными режимами гарантий, такими как шлюзовые обзоры IPA и процессы контроля расходов и оценки услуг правительства. Здесь роль SRO кодифицирована и лично подотчётна парламенту или его эквивалентам, а прозрачность — обязанность, а не выбор. Дисциплина — сделать это вмененное управление соразмерным и согласовать многие внешние требования гарантий, чтобы они информировали поставку, а не просто аудировали её постфактум. При хорошем исполнении управление в государственном секторе — образец подотчётности; при плохом — источник «театра управления», которого боится весь сектор.

Типичные виды отказов#

• Подотчётность комитетом. Нет единого SRO, так что когда что-то идёт не так, все показывают в сторону и ничем не владеют.
• Театр управления. Советы, получающие, а не решающие, шаблоны, которые никто не читает, и шлюзы как экзамены, которые нужно сдать, а не подлинное снижение рисков.
• Арбузная отчётность. Статус остаётся зелёным до момента провала, потому что плохие новости нежелательны, а отчёты поставки не оспариваются гарантиями.
• Один процесс на всех. Тяжёлое управление, применённое к тривиальной работе, толкает команды его обходить, а подлинно рискованная работа проскальзывает налегке.
• Гарантии, захваченные поставкой. Те, кто строит услугу, — единственные, кто подтверждает её безопасность, так что оптимизм остаётся непроверенным.
• Устаревшие журналы RAID. Риски, записанные один раз и никогда не прорабатываемые; янтарные пункты, тихо зеленеющие перед обзором без изменений под ними.
• Слепота к областям. Хорошее управление поставкой, но упущенное измерение клинической безопасности, управления информацией или равенства, пока оно не становится кризисом.
• Театр шлюзов без зубов. Точки обзора, которые никогда не останавливают и не перестраивают работу, так что проваливающиеся программы проплывают через каждый шлюз.

Модель зрелости#

Контрольный список#

• У каждой крупной инициативы есть один названный, достаточно старший, наделённый полномочиями SRO.
• У каждого совета есть актуальный круг обязанностей, называющий его права решений, кворум и эскалацию.
• RACI закрепляет названного подотчётного владельца за каждым повторяющимся типом решений.
• Уровни управления масштабируются по риску и ценности, а пороги опубликованы.
• Три линии защиты действуют, с независимым голосом второй линии, который может эскалировать.
• Интегрированный график гарантий согласует клинические, информационные, технические и коммерческие обзоры со стадийными шлюзами.
• Аппетит к риску записан по областям, а эскалация привязана к нему.
• Живой журнал RAID пересматривается каждый цикл поставки, каждая запись имеет владельца и дату.
• Board Assurance Framework сопоставляет главные риски с контролями и гарантиями, что эти контроли работают.
• Поставка и гарантии отчитываются по общим фактам, а сообщать плохие новости безопасно.
• Каждое заседание, шаблон и отчёт, которые вы сохраняете, меняют реальное решение.

Ключевые источники#

• Infrastructure and Projects Authority (IPA), Principles for Project Success и руководство по шлюзовым/гарантийным обзорам — UK Cabinet Office / HM Treasury.
• NHS England, Clinical Risk Management Standards (DCB0129 и DCB0160) — для клинического управления ИТ здравоохранения (см. также тему 1.6).
• Institute of Internal Auditors (IIA), The IIA's Three Lines Model (обновление 2020 года) — авторитетное изложение подхода трёх линий.
• HM Treasury, The Orange Book: Management of Risk — Principles and Concepts — аппетит к риску, контроли и гарантии в британских государственных органах.
• NHS England / бывший Government Digital Service, Service Standard и руководство по оценке услуг — гарантии для обращённых к публике цифровых услуг.
• UK Corporate Governance Code — Financial Reporting Council — подотчётность совета и внутренний контроль.

Литература#

1. Governance — Wikipedia — https://en.wikipedia.org/wiki/Governance
2. Corporate governance — Wikipedia — https://en.wikipedia.org/wiki/Corporate_governance
3. Clinical governance — Wikipedia — https://en.wikipedia.org/wiki/Clinical_governance
4. Information governance — Wikipedia — https://en.wikipedia.org/wiki/Information_governance
5. Senior responsible owner (Executive sponsor) — Wikipedia — https://en.wikipedia.org/wiki/Senior_responsible_owner
6. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
7. Assurance services — Wikipedia — https://en.wikipedia.org/wiki/Assurance_services
8. Internal audit (Three Lines model) — Wikipedia — https://en.wikipedia.org/wiki/Internal_audit
9. Risk appetite — Wikipedia — https://en.wikipedia.org/wiki/Risk_appetite
10. Risk register — Wikipedia — https://en.wikipedia.org/wiki/Risk_register
11. Phase-gate process — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
12. Infrastructure and Projects Authority — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_and_Projects_Authority
13. The IIA's Three Lines Model — Institute of Internal Auditors — https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/
14. The Orange Book: Management of Risk — Principles and Concepts — HM Treasury — https://www.gov.uk/government/publications/orange-book
15. Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems (DCB0160) — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Service Standard — Government Digital Service / GOV.UK — https://www.gov.uk/service-manual/service-standard
17. The UK Corporate Governance Code — Financial Reporting Council — https://www.frc.org.uk/library/standards-codes-policy/corporate-governance/uk-corporate-governance-code/
18. Enterprise risk management — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_risk_management