Tópico 3.10 — Preparação, resiliência e resposta a emergências

A Preparação, Resiliência e Resposta a Emergências (EPRR) é um dever estatutário, e não um desejável, e num sistema de saúde moderno a dimensão digital e de dados já faz parte da linha de frente — por isso você deve planejar, treinar, exercitar e comandar a sua tecnologia ao lado dos seus clínicos.

Por que isso importa na saúde e nos cuidados#

Quando ocorre um incidente grave — um ataque terrorista, um vazamento químico, uma onda de calor, um surto de gripe ou um ciberataque que tranca todos os clínicos fora do prontuário eletrônico do paciente —, espera-se que o sistema de saúde e cuidados continue funcionando enquanto tudo ao redor está desorganizado. Essa expectativa está escrita em lei. Sob a Civil Contingencies Act 2004, os órgãos do NHS e seus parceiros têm deveres específicos de avaliar riscos, manter planos e ser capazes de responder. A Preparação, Resiliência e Resposta a Emergências é o termo guarda-chuva que o NHS usa para como cumpre esses deveres. Não é o mesmo que a gestão de serviços comum, e é mais ampla do que a recuperação de desastres focada em TI, tratada no Tópico 3.9 — Continuidade de negócios e recuperação de desastres.

A razão pela qual isso importa mais na saúde e nos cuidados do que em quase qualquer outro lugar é que a falha tem custo humano imediato. Se o sistema de caixas de um supermercado falha, as vendas param; se o sistema clínico de um hospital falha durante um evento com muitas vítimas, pessoas podem morrer que de outro modo teriam vivido. Os serviços digitais estão hoje tão entrelaçados ao trabalho clínico — pedir exames, prescrever, verificar alergias, ver imagens, dar alta a pacientes — que uma indisponibilidade tecnológica é um evento de segurança clínica e deve ser tratada com a mesma seriedade de qualquer outra ameaça à vida. É por isso que a tese do "como se trabalha" deste livro é aqui mais aguda: a sua preparação é uma questão de segurança clínica, de equidade e de confiança pública.

As emergências também expõem a desigualdade. As pessoas menos capazes de se virar quando os serviços normais falham — as sem transporte, sem inglês, sem dinheiro, sem cuidadores, com condições crônicas — são exatamente as que os seus planos de emergência precisam proteger primeiro. Uma resposta que as deixa para trás em silêncio não é uma resposta bem-sucedida, por mais impecável que pareça a estrutura de comando. Preparar-se bem e ensaiar com honestidade é como se conquista a confiança pública que uma crise real testará até o limite.

Conceitos centrais#

A gestão de emergências é a disciplina de reduzir a vulnerabilidade de uma comunidade a perigos e coordenar a resposta quando eles ocorrem. É convencionalmente descrita como um ciclo — antecipar, avaliar, prevenir, preparar, responder, recuperar — e os sistemas de saúde percorrem esse ciclo continuamente, e não apenas durante uma crise. A EPRR é a expressão do NHS para isso.

A Civil Contingencies Act 2004 é a espinha dorsal legal. Divide os respondedores em dois grupos. Os respondedores de Categoria 1 são os que estão no centro da resposta — serviços de emergência, hospitais e conselhos do NHS, conselhos de cuidados integrados, a UK Health Security Agency e as autoridades locais — e carregam o conjunto completo de deveres: avaliação de riscos, planejamento de emergência, continuidade de negócios, compartilhamento de informações e alerta ao público. Os respondedores de Categoria 2 — concessionárias de serviços públicos, operadores de transporte, empresas de telecomunicações e outros — são "órgãos cooperantes" com um dever mais leve, principalmente o de compartilhar informações e cooperar com os de Categoria 1. Saber qual você é, e quais deveres se aplicam, é o ponto de partida para todo o resto.

Os respondedores se coordenam por meio de um Local Resilience Forum (LRF), uma parceria multiagência construída em torno de cada área policial. O LRF é onde o NHS, os conselhos, a polícia, os bombeiros, a ambulância e outros planejam juntos, e mantém um registro de riscos da comunidade — uma avaliação compartilhada e publicada dos perigos locais com maior probabilidade de exigir uma resposta coordenada, da gripe pandêmica a inundações e acidentes industriais. O registro é um exemplo prático de avaliação de riscos: identificar perigos, julgar probabilidade e impacto e decidir para o que planejar.

Os incidentes são classificados para que todos compartilhem uma linguagem de escala. Um incidente de continuidade de negócios perturba a sua capacidade de prestar serviços, mas é, em princípio, gerenciável com os seus próprios planos. Um incidente crítico é mais sério: o nível de interrupção ameaça a capacidade da organização de prestar cuidados seguros e exige medidas especiais. Um incidente grave é aquele cuja escala ou natureza exige arranjos especiais de um ou mais serviços de emergência e, em geral, de todo o sistema — um evento com muitas vítimas é o arquétipo. Os limiares importam porque declarar um incidente libera recursos, autoridade e ajuda mútua.

O comando segue a estrutura de comando ouro–prata–bronze, também chamada de estratégico–tático–operacional. O ouro (estratégico) define os objetivos e é dono das grandes decisões; a prata (tático) decide como os recursos são empregados para alcançá-los; o bronze (operacional) executa as tarefas práticas. A estrutura é deliberadamente genérica para que agências que nunca trabalharam juntas possam se encaixar num único sistema de comando no dia.

Mais três conceitos completam o quadro. O surto de demanda (surge) é a capacidade de expandir a capacidade — leitos, pessoal, oxigênio, computação — de forma rápida e temporária além dos limites normais. A triagem é o processo de priorizar vítimas quando a necessidade excede a capacidade, e existem sistemas de triagem para muitas vítimas justamente para os piores dias. A ajuda mútua é o acordo de emprestar pessoal, equipamento ou capacidade entre fronteiras organizacionais quando um respondedor está sobrecarregado. E uma pandemia — um surto de doença infecciosa que se espalha por uma grande região — é o pior caso permanente contra o qual a maioria dos sistemas de saúde hoje planeja explicitamente, fortemente informados pela pandemia de COVID-19 no Reino Unido.

Boas práticas#

  1. Trate grandes indisponibilidades tecnológicas e ciberataques como incidentes graves por direito próprio. Um ataque de ransomware que desativa os sistemas clínicos não é meramente um "problema de TI" a ser tratado discretamente por uma central de serviços; é uma ameaça à segurança do paciente em toda uma organização. Ligue a sua resposta a incidentes cibernéticos e digitais à mesma estrutura de comando ouro–prata–bronze que a organização usa para um acidente de ônibus, com um gatilho definido para quando um incidente digital é escalado a incidente crítico ou grave formal. O ataque WannaCry de 2017 mostrou como um único malware pôde se propagar por dezenas de hospitais em horas — ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança, para os controles que o previnem, e este tópico, para como comandar a resposta quando eles falham.

  2. Percorra o ciclo planejar–treinar–exercitar sem descanso, e para valer. Um plano que nunca foi testado é uma hipótese. A EPRR do NHS exige um programa contínuo de exercícios — testes de comunicação, exercícios de mesa e exercícios plenos ao vivo — e vocês devem agendá-los, dotá-los de recursos e tratar a ausência de líderes seniores como o sinal de alerta que ela é. De modo crucial, incluam as equipes digitais e de dados: ensaiem perder o prontuário eletrônico, perder a rede e perder o data center principal, e não apenas um incêndio numa enfermaria.

  3. Projete e ensaie deliberadamente o seu recurso de papel e de contingência. Todo sistema clínico crítico precisa de um modo de trabalhar documentado e praticado para quando estiver indisponível — formulários de contingência, fichas de medicação impressas, cópias somente leitura de "continuidade de negócios" dos registros e um processo conhecido para reconciliar os dados quando os sistemas voltarem. Esses recursos decaem em silêncio; os formulários ficam desatualizados, quem conhecia o procedimento sai e a impressora está sem toner no dia em que se precisa dela. Auditem-nos com o mesmo cuidado com que auditam o sistema em produção e liguem esse trabalho explicitamente aos objetivos de tempo de recuperação do Tópico 3.9 — Continuidade de negócios e recuperação de desastres.

  4. Mantenha funcionando as comunicações de comando e controle quando todo o resto falha. Num incidente real, o seu e-mail e a telefonia comuns podem fazer parte do que falhou, especialmente num ciberataque. Mantenham comunicações fora de banda — uma forma de reunir o comando ouro que não dependa da rede sob ataque — junto com listas de acionamento atualizadas e offline e um método resiliente de alcançar a equipe da linha de frente. Testem esses canais nos exercícios; descobrir que a sua ponte de incidente depende do mesmo login único que o ransomware acabou de criptografar é uma descoberta que vocês querem fazer num ensaio, e não às 3 da manhã.

  5. Pré-acorde as regras de governança da informação para uma crise antes da crise. Numa emergência, vocês precisarão compartilhar dados rapidamente — entre hospitais, com a saúde pública, com parceiros de ajuda mútua — e a equipe precisa saber que tem permissão. Trabalhem com o seu Encarregado de Proteção de Dados e o seu Caldicott Guardian para estabelecer, de antemão, as bases legais e os acordos permanentes de compartilhamento de informações que se aplicam numa emergência, para que os clínicos compartilhem o que é necessário para salvar vidas sem congelar na incerteza. Manter um registro das decisões de compartilhamento de dados em emergência protege pacientes e equipe depois (ver Tópico 1.8 — Ética de dados, consentimento e confiança pública).

  6. Incorpore o surto de demanda aos seus serviços digitais, e não apenas às suas enfermarias. Os serviços digitais voltados à população — agendamento, triagem, verificadores de sintomas, sistemas de vacinação — podem ser atingidos por picos de demanda de dez ou cem vezes o normal durante uma emergência, exatamente quando mais importam. Façam testes de carga contra cenários realistas de surto, acordem como escalarão rapidamente a capacidade da nuvem e decidam de antemão o que degradar com elegância para que a função central sobreviva. Uma fila que se sustenta é melhor do que um site que desaba sob o peso de um público assustado.

  7. Leve a expertise digital e de dados à avaliação de riscos e ao registro de riscos da comunidade. A contribuição da sua organização ao Local Resilience Forum deve incluir uma visão lúcida do risco digital e cibernético, dos pontos únicos de falha e das dependências de sistemas nacionais e fornecedores. Com demasiada frequência, o registro de riscos trata a "falha de TI" como uma única linha vaga; detalhem-na, quantifiquem-na e garantam que o LRF entenda que uma indisponibilidade de rede ou de nuvem regional é hoje um evento de interrupção em massa crível. Isso faz parte do ciclo de governança e garantia descrito no Tópico 6.4 — Governança e garantia.

  8. Aprenda abertamente com cada exercício e cada incidente real. O valor de um exercício é a reunião de balanço, e o valor de um incidente real são as lições estruturadas que se seguem. Registrem o que aconteceu sem culpa, acompanhem as ações até a conclusão e — a parte difícil — fechem-nas de fato antes que o próximo incidente encontre a mesma lacuna. Compartilhem o aprendizado pelo sistema por meio do LRF e dos canais nacionais, porque o objetivo de uma rede resiliente é que nenhuma organização precise aprender a mesma lição dolorosa duas vezes.

  9. Cuide das suas pessoas durante e depois da resposta. A resiliência não é só técnica; uma força de trabalho exausta, assustada ou moralmente ferida não consegue sustentar uma longa emergência. Planejem escalas de turnos, descanso, primeiros socorros psicológicos e bem-estar durante incidentes prolongados, como uma pandemia, e tornem legítimo pedir ajuda. As organizações que melhor se recuperaram da COVID-19 foram, com frequência, as que protegeram deliberadamente o bem-estar da equipe, em vez de tratar a resistência como infinita.

Perguntas para discutir com a sua equipe#

  1. Quando exatamente um problema digital ou cibernético deixa de ser um "incidente de serviço" e se torna um incidente crítico ou grave declarado — e quem tem autoridade para tomar essa decisão às 2 da manhã de um domingo? Esta pergunta obriga a testar a costura entre a gestão cotidiana de serviços do Tópico 3.8 — Gestão de serviços e operação em produção e a maquinaria estatutária da EPRR. A tensão está entre escalar demais (gritar "lobo", esgotando a estrutura de comando) e escalar de menos (deixar um ataque de ransomware se espalhar por horas enquanto as pessoas debatem se ele conta). Uma boa resposta nomeia gatilhos explícitos e observáveis — por exemplo, a perda do prontuário eletrônico em vários locais ou a confirmação de malware em sistemas clínicos — e nomeia os papéis de plantão com poder para declarar, sem esperar o horário comercial. Discutam quem está nessa escala, se foi treinado e se consegue reunir o comando ouro quando a rede normal está fora do ar. Considerem percorrer um quase-acidente recente e perguntar com honestidade se vocês teriam escalado a tempo. As melhores respostas também cobrem a desescalação: como vocês decidem que a emergência acabou e voltam à rotina.

  2. Se os nossos principais sistemas clínicos ficassem fora do ar por 72 horas, o que de fato faríamos — e já o comprovamos, ou apenas acreditamos? Esta é uma pergunta sobre a distância entre o plano na prateleira e a realidade na enfermaria. A concessão a trazer à tona é o investimento: manter e ensaiar procedimentos de contingência custa dinheiro e tempo clínico que poderiam ir para outro lugar, e é fácil deixá-los apodrecer em silêncio. Uma resposta forte distingue o que é genuinamente ensaiado do que está apenas escrito e é específica sobre a primeira hora, o primeiro turno e o segundo dia, porque os problemas mudam com o tempo — reconciliar três dias de registros em papel de volta ao sistema é, em si, uma grande tarefa. Sondem se a equipe da linha de frente, e não apenas os gestores, conhece o recurso e se os recém-chegados já o viram. Procurem honestidade sobre pontos únicos de falha, incluindo dependências de infraestrutura nacional e de fornecedores que vocês não controlam. As equipes mais maduras conseguem apontar um exercício real ou uma indisponibilidade real em que o recurso se sustentou e as lições que fecharam depois.

  3. Como garantimos que a nossa resposta de emergência proteja as pessoas mais difíceis de alcançar, em vez de deixá-las para trás em silêncio? As emergências amplificam a desigualdade existente, e as respostas digitais podem piorá-la: um sistema de agendamento só on-line, um alerta só em inglês ou um aplicativo que pressupõe um smartphone e dados móveis podem excluir justamente as pessoas mais em risco. A tensão está entre a velocidade e a escala que os canais digitais oferecem e a cobertura que a equidade exige, e não há almoço grátis — será preciso ter vias não digitais rodando em paralelo, o que custa mais. Uma boa resposta se liga ao registro de riscos da comunidade e pergunta que grupos vulneráveis um dado perigo ameaça, verificando depois se a resposta os alcança. Considerem as vias de digital assistido, os materiais traduzidos e como alcançar pessoas acamadas, digitalmente excluídas ou sem apoio (ver Tópico 1.9 — Inclusão digital e acessibilidade). Discutam como saberiam se estavam falhando com elas durante um incidente, e não meses depois, numa revisão. As respostas honestas admitem onde os planos atuais são mais fracos e se comprometem a testá-los com as comunidades envolvidas.

  4. Quais das nossas dependências digitais críticas não controlamos de fato — e qual é o nosso plano quando a falha está a montante de nós? A saúde e os cuidados modernos rodam sobre sistemas nacionais, regiões de nuvem, provedores de conectividade e um punhado de fornecedores dominantes, e grande parte da sua resiliência está, portanto, nas mãos de outros. A tensão incômoda é que vocês carregam o dever estatutário e as consequências para a segurança clínica, mas o ponto único de falha pode ser o data center de um fornecedor ou um serviço nacional compartilhado que vocês não podem inspecionar. Uma resposta forte mapeia essas dependências explicitamente — quais sistemas são hospedados onde, quais fornecedores sustentam quais funções clínicas e onde o risco de concentração faz com que uma indisponibilidade derrube vários serviços de uma vez — em vez de deixar a "falha de TI" como uma única linha vaga no registro de riscos. Faz perguntas duras sobre compromissos contratuais de recuperação, sobre o que acontece quando o próprio fornecedor é a vítima do ataque e sobre se uma indisponibilidade de nuvem regional é tratada como o evento de interrupção em massa crível que hoje é. Sondem se esses riscos a montante são levados ao seu Local Resilience Forum e ao conselho e se vocês têm alguma ajuda mútua ou recurso manual para as dependências sobre as quais não têm influência. A resposta honesta geralmente admite que alguns riscos só podem ser mitigados, e não removidos, e é explícita sobre quais vocês estão conscientemente aceitando.

  5. Os nossos exercícios nos dizem a verdade, e as lições que aprendemos de fato mudam algo antes do próximo incidente? Um programa de exercícios pode virar teatro — uma mesa de cenário roteirizada que todos sabem que terá sucesso, frequentada por juniores enquanto os líderes seniores enviam desculpas, produzindo um relatório arrumado e uma lista de ações que ninguém fecha. A tensão está entre exercícios confortáveis e tranquilizadores e exercícios realistas o bastante para falhar com segurança, que é o único tipo que ensina algo. Uma boa resposta examina se vocês ensaiam cenários genuinamente difíceis — perder o EPR, perder a rede, um ataque de ransomware a um fornecedor — com as pessoas que de fato estariam de plantão e se a presença sênior é tratada como obrigatória, e não opcional. É franca sobre a cultura de balanço: as lições são registradas sem culpa, acompanhadas até a conclusão e verificadas como fechadas, ou as mesmas lacunas reaparecem incidente após incidente? Procurem evidência de que uma lição de um exercício ou evento real demonstravelmente mudou um plano, uma escala ou um controle. As equipes mais maduras conseguem nomear uma falha que trouxeram à tona deliberadamente num ensaio e corrigiram antes que pudesse ferir um paciente.

  6. Como sustentaremos e protegeremos as nossas pessoas numa resposta que dura semanas, e não horas? Muito do planejamento de emergências supõe implicitamente um choque agudo e curto, mas os eventos que mais testam um sistema de saúde — uma pandemia, uma recuperação cibernética prolongada, um longo surto de frio — se arrastam por semanas ou meses, e a resistência humana não é infinita. A concessão é real: rodiziar as pessoas para descanso e bem-estar reduz as horas brutas disponíveis exatamente no momento em que a demanda atinge o pico, e é tentador contar com os dispostos até que quebrem. Uma resposta forte planeja desde o início escalas de turnos, passagens de plantão, descanso, primeiros socorros psicológicos e bem-estar e torna legítimo que a equipe peça ajuda, em vez de tratar a exaustão como compromisso. Considera também as equipes digitais e de dados, que muitas vezes sustentam uma recuperação por dias sem revezamento porque são poucas e especializadas. Discutam como detectariam esgotamento, lesão moral e rotatividade durante um incidente longo e quem é responsável pelo bem-estar da força de trabalho na sua estrutura de comando. As organizações que melhor atravessaram a COVID-19 foram com frequência as que protegeram deliberadamente suas pessoas, e as respostas honestas admitem se os seus planos hoje fazem isso ou apenas esperam por heroísmo.

Na prática: um exemplo de saúde e cuidados#

Meadowford é um sistema de cuidados integrados fictício que abrange uma cidade de porte médio e o seu interior rural. Numa chuvosa manhã de fevereiro, o prontuário eletrônico do paciente do seu hospital de agudos — hospedado por um fornecedor nacional e compartilhado com dois hospitais vizinhos — começa a emitir erros e depois falha por completo. Em vinte minutos, o fornecedor confirma um ataque de ransomware. Os clínicos não conseguem mais ver medicamentos, alergias, resultados nem planos de cuidados em três hospitais e seus serviços comunitários associados.

O diretor de plantão do hospital declara um incidente crítico usando um gatilho pré-acordado — "perda do EPR em vários locais" — e, à medida que a escala fica clara, escala a incidente grave. O comando ouro se reúne não pela habitual chamada no Teams, que passa pelo login único afetado, mas por uma ponte fora de banda ensaiada, em outra plataforma, usando uma lista de acionamento impressa. O comando prata ativa os procedimentos de contingência: fichas de medicação em papel, formulários de pedido de contingência e cópias "quebra-vidro" somente leitura dos registros, replicadas para um ambiente segregado justamente para esse cenário, conforme projetado sob os objetivos de recuperação do Tópico 3.9.

Os responsáveis por cibersegurança e segurança clínica trabalham em paralelo. O diretor clínico de informação abre um caso de segurança clínica, tratando a indisponibilidade como um perigo e acompanhando os riscos específicos — alergias perdidas, doses duplicadas, resultados perdidos — com mitigações para cada um (ver Tópico 1.6 — Segurança clínica e gestão de riscos). O Caldicott Guardian e o Encarregado de Proteção de Dados confirmam a posição pré-acordada de compartilhamento de informações em emergência, para que os clínicos possam telefonar para locais vizinhos pedindo dados críticos de pacientes sem hesitar quanto à licitude, e toda decisão desse tipo é registrada.

Enquanto isso, o Local Resilience Forum é informado e a ajuda mútua flui: um ICS vizinho empresta pessoal de farmácia para ajudar a gerir a prescrição em papel, e a equipe regional de EPRR do NHS England se coordena com o National Cyber Security Centre. A atividade eletiva é suspensa para criar capacidade de surto; o registro de riscos da comunidade já havia sinalizado uma indisponibilidade regional de sistemas clínicos como cenário crível, de modo que o roteiro existia. Os sistemas são restaurados a partir de backups limpos ao longo de quatro dias. O trabalho mais difícil vem depois: reconciliar quatro dias de papel de volta ao prontuário e um balanço estruturado, sem culpa, cujas ações — uma fronteira de segmentação fraca, uma lista de acionamento desatualizada e equipe que nunca tinha visto os formulários de contingência — são acompanhadas até o fechamento antes do próximo exercício.

Perspectivas setoriais#

Startup#

Uma pequena empresa de saúde digital não conduzirá comando ouro–prata–bronze, mas é uma dependência crítica para os clientes que o fazem. Sua história de resiliência — onde os dados são hospedados, com que rapidez você se recupera, qual é o seu processo de incidentes, como se comunicaria durante uma indisponibilidade — é algo que os compradores corporativos interrogarão, e devem interrogar. Seja honesto sobre os pontos únicos de falha, incluindo a dependência de uma região de nuvem ou de um engenheiro-chave. A atitude disciplinada é escrever cedo um plano leve de resposta a incidentes, ensaiá-lo uma vez e poder mostrar aos clientes que você leva a continuidade deles a sério; é, ao mesmo tempo, boa prática e vantagem de vendas.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou um serviço de cuidados domiciliares — carrega o mesmo dever de manter as pessoas seguras quando os sistemas falham, mas sem nenhuma das maquinarias dedicadas de EPRR de um hospital do NHS. Você não terá um responsável de emergência designado nem uma escala de comando 24/7; a resiliência precisa estar embutida na forma como um punhado de pessoas já trabalha. O foco pragmático é um plano curto e genuinamente ensaiado de contingência para os sistemas de que você depende — o sistema clínico, os telefones, o enlace de internet —, com recursos em papel que a sua equipe real tenha usado ao menos uma vez, e uma lista offline de a quem ligar, incluindo seu fornecedor e seu comissionador. Como você depende quase inteiramente de fornecedores e de serviços nacionais que não pode controlar, conheça os compromissos de recuperação deles e as suas próprias gambiarras manuais para as primeiras horas. Engaje-se com o sistema mais amplo em vez de enfrentar uma emergência sozinho: o seu conselho de cuidados integrados e o Local Resilience Forum existem em parte para ajudar organizações do seu porte, e a ajuda mútua com prestadores vizinhos pode ser a diferença entre aguentar e fechar.

Grande organização#

Um grande hospital do NHS ou um ICS carrega todo o peso dos deveres de respondedor de Categoria 1: um responsável de emergência designado, um programa contínuo de exercícios, um comando de plantão 24/7 e um assento no Local Resilience Forum. O desafio é a integração — garantir que as respostas cibernética, clínica, operacional e de comunicações convirjam numa única estrutura de comando, e não em três paralelas, e que as equipes digitais sejam genuinamente parte da EPRR, e não uma reflexão tardia chamada quando tudo já está em chamas. A escala também traz complexidade: muitos sistemas, muitos fornecedores e dependências de infraestrutura nacional que vocês não controlam. A maturidade se parece com uma contingência ensaiada funcionando em todos os serviços críticos e com uma cultura de balanço que de fato fecha suas ações.

Governo#

Os órgãos nacionais e regionais — NHS England, UK Health Security Agency, Department of Health and Social Care, governos descentralizados — definem o arcabouço, detêm os padrões e coordenam a resposta acima do nível que qualquer organização isolada consegue gerir. Seu trabalho de EPRR é escrever e assegurar os padrões centrais, conduzir exercícios nacionais, manter reservas e arranjos de ajuda mútua e prover coordenação de comando durante eventos de todo o sistema, como uma pandemia. Também são donos da infraestrutura digital nacional cuja falha seria, em si, um evento de interrupção em massa; sua própria resiliência é, portanto, um dever público. Trabalhar bem com eles e entender a cadeia estratégico–tático–operacional até o nível nacional é o tema do Tópico 9.1 — Trabalho com governos locais e nacionais.

Modos de falha comuns#

  • Planos na prateleira. Um fichário grosso escrito para passar numa verificação de garantia, nunca exercitado e desconhecido da equipe que teria de usá-lo. O ensaio, e não a documentação, é o teste da prontidão.
  • Tratar o cyber como problema de TI. Deixar um ataque de ransomware com a central de serviços enquanto ele se espalha, em vez de escalá-lo ao comando de incidente grave com liderança de segurança clínica. A velocidade da escalação é tudo.
  • Procedimentos de contingência não testados. Formulários de recurso desatualizados, equipe que nunca os viu e nenhum plano ensaiado de reconciliação dos dados depois. O recurso decai em silêncio, a menos que vocês o auditem.
  • Canais de comando que compartilham a falha. Reunir o comando ouro na mesma plataforma que o ataque criptografou. As comunicações fora de banda precisam ser genuinamente independentes.
  • Aprendizado que nunca pousa. Balanços que produzem um relatório e uma lista de ações que ninguém fecha, de modo que o próximo incidente encontra a mesma lacuna. Acompanhem as lições até a conclusão.
  • Equidade como reflexão tardia. Respostas só digitais que excluem os vulneráveis, descobertas apenas numa revisão pós-incidente. Projetem desde o início as vias não digitais.
  • Heroísmo como estratégia. Supor que a resistência da equipe é infinita e negligenciar o bem-estar, o descanso e o apoio psicológico durante um incidente longo. O esgotamento é uma falha de resiliência.

Modelo de maturidade#

Dimensão Iniciar Desenvolver Padronizar Gerir Orquestrar
Classificação de incidentes e comando Ad hoc; sem gatilhos nem papéis claros Estrutura de comando existe no papel; digital não integrado Gatilhos claros; cyber/digital ligados ao ouro–prata–bronze; plantão treinado Tempos de declaração e escalação medidos; desempenho do comando revisto e assegurado frente a metas Gatilhos ensaiados e refinados a partir de eventos reais; comando clínico-cibernético-operacional fluido
Planejar–treinar–exercitar Sem exercícios; planos não lidos Exercícios de mesa ocasionais; TI raramente envolvida Programa contínuo incluindo cenários digitais/de dados Cobertura dos exercícios e taxas de fechamento de ações acompanhadas; presença sênior assegurada; programa gerido por um plano baseado em risco Exercícios frequentes e realistas, com aprendizado em ciclo fechado por todo o sistema
Resiliência digital à indisponibilidade Sem recurso documentado Formulários de contingência existem, mas não testados Recursos ensaiados, registros quebra-vidro, planos de reconciliação Prontidão do recurso e tempos de recuperação medidos frente aos RTOs; auditados em cronograma; lacunas geridas até o fechamento Trabalho em contingência comprovado em incidentes reais; tempos de recuperação medidos e em melhoria
Governança da informação em emergência A equipe não sabe o que pode compartilhar Alguns acordos, acionados de forma reativa Bases legais e acordos de compartilhamento em emergência pré-acordados Decisões de compartilhamento em emergência registradas e auditadas; acordos revistos em ciclo; conformidade gerida frente a padrões Governança da informação em crise é segunda natureza; decisões registradas e revistas
Aprendizado e melhoria Sem balanços Balanços realizados, ações raramente fechadas Balanços estruturados e sem culpa, com ações acompanhadas Fechamento de ações e recorrência acompanhados como KPIs; lições vencidas escaladas e geridas até a meta Lições compartilhadas por todo o sistema; a recorrência de falhas conhecidas tende a zero

Lista de verificação#

  • Confirme o status da sua organização (respondedor de Categoria 1 ou 2) e os deveres estatutários que se aplicam.
  • Defina gatilhos explícitos e observáveis para escalar um problema digital ou cibernético a incidente crítico ou grave e nomeie quem pode declarar, 24/7.
  • Garanta que a resposta a incidentes cibernéticos e digitais esteja ligada à sua estrutura de comando ouro–prata–bronze.
  • Mantenha comunicações de comando fora de banda e listas de acionamento offline e teste-as nos exercícios.
  • Documente, audite e ensaie procedimentos de contingência/recurso para todo sistema clínico crítico, incluindo a reconciliação de dados.
  • Pré-acorde com o seu Caldicott Guardian e o Encarregado de Proteção de Dados as bases legais e os acordos de compartilhamento de informações em emergência.
  • Faça teste de carga dos serviços digitais voltados à população contra cenários realistas de surto e acorde o que degrada com elegância.
  • Contribua com uma visão clara do risco digital e cibernético ao seu Local Resilience Forum e ao registro de riscos da comunidade.
  • Conduza um programa contínuo de planejar–treinar–exercitar que inclua perder o EPR, a rede e o data center principal.
  • Realize balanços sem culpa após exercícios e incidentes reais e acompanhe toda ação até o fechamento.
  • Planeje o bem-estar, o descanso e o apoio psicológico da equipe durante incidentes prolongados.
  • Verifique se a sua resposta de emergência alcança grupos digitalmente excluídos e vulneráveis por vias não digitais.

Fontes-chave#

  • NHS England — NHS Emergency Preparedness, Resilience and Response (EPRR) Framework e os EPRR Core Standards.
  • Cabinet Office — Civil Contingencies Act 2004 e orientações estatutárias Emergency Preparedness / Emergency Response and Recovery.
  • Cabinet Office / GOV.UK — National Risk Register e orientações sobre Local Resilience Forums e registros de riscos da comunidade.
  • National Cyber Security Centre (NCSC) — orientações sobre ransomware, gestão de incidentes e tratamento de incidentes cibernéticos como incidentes graves.
  • UK Health Security Agency (UKHSA) — orientações de preparação para pandemias e doenças infecciosas.
  • UK Covid-19 Inquiry — módulos e relatórios publicados sobre preparação e resposta à pandemia.
  • Joint Emergency Services Interoperability Principles (JESIP) — comando, coordenação e o modelo estratégico–tático–operacional.
  • National Audit Office — Investigation: WannaCry cyber attack and the NHS (2018).

Referências#

  1. Civil Contingencies Act 2004 — Wikipedia — https://en.wikipedia.org/wiki/Civil_Contingencies_Act_2004
  2. Emergency management — Wikipedia — https://en.wikipedia.org/wiki/Emergency_management
  3. Local resilience forum — Wikipedia — https://en.wikipedia.org/wiki/Local_resilience_forum
  4. Gold–silver–bronze command structure — Wikipedia — https://en.wikipedia.org/wiki/Gold%E2%80%93silver%E2%80%93bronze_command_structure
  5. Risk assessment — Wikipedia — https://en.wikipedia.org/wiki/Risk_assessment
  6. Triage — Wikipedia — https://en.wikipedia.org/wiki/Triage
  7. Mutual aid (emergency services) — Wikipedia — https://en.wikipedia.org/wiki/Mutual_aid_(emergency_services)
  8. Pandemic — Wikipedia — https://en.wikipedia.org/wiki/Pandemic
  9. COVID-19 pandemic in the United Kingdom — Wikipedia — https://en.wikipedia.org/wiki/COVID-19_pandemic_in_the_United_Kingdom
  10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
  11. NHS Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
  12. Civil Contingencies Act 2004 (legislation) — UK Government / The National Archives — https://www.legislation.gov.uk/ukpga/2004/36/contents
  13. Preparation and planning for emergencies: responsibilities of responder agencies and others — Cabinet Office, GOV.UK — https://www.gov.uk/guidance/preparation-and-planning-for-emergencies-responsibilities-of-responder-agencies-and-others
  14. Mitigating malware and ransomware attacks — National Cyber Security Centre — https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks
  15. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
  16. UK Covid-19 Inquiry — https://covid19.public-inquiry.uk/

Editar esta página no GitHub — o livro é a fonte da verdade; este site apenas o exibe.