Conformidade com a HIPAA para MSPs: o que está mudando e o que você deve fazer agora

A HIPAA (Lei de Portabilidade e Responsabilidade dos Seguros de Saúde) é uma das estruturas de conformidade mais conhecidas nos Estados Unidos e uma das mais importantes para os MSPs que atendem clientes do setor de saúde. Se o seu MSP gerencia a TI de hospitais, clínicas, consultórios odontológicos, prestadores de serviços de saúde mental, seguradoras de saúde ou qualquer outra organização que lide com informações de saúde protegidas (PHI), a conformidade com a HIPAA não é opcional. Trata-se de uma obrigação legal que se aplica diretamente à relação de prestação de serviços.

De acordo com o Relatório Kaseya sobre a Situação dos MSPs de 2026, 71% dos MSPs relataram um crescimento ano a ano na receita de segurança cibernética, e os serviços de conformidade com a HIPAA são um fator significativo para os MSPs que atendem clientes do setor de saúde. Baixe o relatório completo.

Mais importante ainda: a HIPAA está mudando. Em 27 de dezembro de 2024, o Escritório de Direitos Civis do HHS publicou um Aviso de Proposta de Regulamentação que, se aprovado, representará a atualização mais significativa da Regra de Segurança da HIPAA desde 2003. Os MSPs e as equipes de TI da área da saúde que compreenderem o que está por vir poderão se preparar de forma proativa, em vez de terem que agir às pressas quando a regra final for publicada.

O que é a HIPAA

A HIPAA é uma lei federal dos Estados Unidos promulgada em 1996 e administrada pelo Escritório de Direitos Civis (OCR) do Departamento de Saúde e Serviços Humanos (HHS). Ela estabelece normas de privacidade e segurança para as informações de saúde protegidas (PHI), ou seja, informações de saúde individualmente identificáveis relacionadas ao estado de saúde passado, presente ou futuro de uma pessoa, ao tratamento médico ou ao pagamento de serviços de saúde.

A lei se aplica às “entidades abrangidas” (prestadores de serviços de saúde, planos de saúde e centrais de processamento de dados de saúde) e, fundamentalmente, aos seus “parceiros comerciais” — qualquer organização que crie, receba, mantenha ou transmita Informações de Saúde Protegidas (PHI) em nome de uma entidade abrangida.

Para os profissionais de TI, a Regra de Segurança da HIPAA, que abrange as Informações de Saúde Protegidas (ePHI) em formato eletrônico, é o componente de maior relevância operacional. Ela exige que as entidades abrangidas e os parceiros comerciais implementem medidas de segurança administrativas, físicas e técnicas para proteger a confidencialidade, a integridade e a disponibilidade das ePHI.

A quem se aplica a HIPAA, incluindo os MSPs

As entidades abrangidas são prestadores de serviços de saúde que realizam transações eletrônicas padrão (faturamento, encaminhamentos, verificações de elegibilidade), planos de saúde e centrais de processamento de dados de saúde.

Parceiros comerciais são quaisquer pessoas físicas ou jurídicas que desempenham funções envolvendo Informações de Saúde Protegidas (PHI) em nome de uma entidade abrangida. Isso inclui prestadores de serviços de TI, serviços em nuvem que hospedam PHI, empresas de cobrança, escritórios de advocacia que lidam com questões de saúde e prestadores de serviços gerenciados.

Um MSP que presta serviços de TI a uma entidade abrangida, seja gerenciando sistemas que contenham PHI, fornecendo backup que inclua PHI, oferecendo acesso remoto a sistemas clínicos ou gerenciando a segurança da rede, é considerado um parceiro comercial e está diretamente sujeito aos requisitos da Regra de Segurança da HIPAA.

Os subcontratados de parceiros comerciais também são considerados parceiros comerciais. Se um MSP recorrer a um provedor de backup em nuvem para armazenar cópias de segurança de PHI, esse provedor também é um parceiro comercial da entidade abrangida. As obrigações da HIPAA se estendem por toda a cadeia de fornecimento.

As três regras da HIPAA que as equipes de TI devem conhecer

A Norma de Privacidade regula a forma como as Informações de Saúde Protegidas (PHI) podem ser utilizadas e divulgadas. Trata-se, essencialmente, de uma questão de política e administrativa, mas as equipes de TI precisam compreendê-la para configurar corretamente os controles de acesso e o registro de divulgações.

A Norma de Segurança (45 CFR, Partes 160 e 164) é o principal requisito técnico de conformidade. Ela exige que as entidades abrangidas e os parceiros comerciais implementem três categorias de medidas de proteção:

• Medidas de segurança administrativas: análise de riscos, gestão de riscos, treinamento da equipe, procedimentos de gestão de acesso, procedimentos de resposta a incidentes.
• Medidas de segurança física: controles de acesso às instalações, políticas de uso e segurança das estações de trabalho, controles de dispositivos e mídias.
• Medidas de segurança técnicas: controles de acesso (IDs de usuário exclusivos, acesso de emergência, logoff automático, criptografia), controles de auditoria (registros de atividades de hardware e software), controles de integridade (garantindo que as ePHI não tenham sido alteradas indevidamente) e segurança na transmissão (criptografia das ePHI em trânsito).

A Norma de Notificação de Violação exige que as entidades abrangidas notifiquem as pessoas afetadas, o HHS e, em alguns casos, a mídia, no prazo de 60 dias após a constatação de uma violação de PHI não protegida. Os parceiros comerciais devem notificar a entidade abrangida sem demora injustificada e no prazo de 60 dias após a constatação de uma violação que afete as PHI da entidade abrangida.

A atualização proposta da Regra de Segurança: o que os MSPs precisam acompanhar

O Aviso de Proposta de Regulamentação (NPRM) de dezembro de 2024 representa a alteração mais significativa proposta à Regra de Segurança da HIPAA em mais de duas décadas. O Departamento de Saúde e Serviços Humanos (HHS) estabeleceu maio de 2026 como prazo para a regulamentação final, embora o período de comentários tenha gerado quase 5.000 respostas e o cronograma final possa sofrer alterações. O atual governo decidirá se e como finalizá-la.

O rumo a seguir é claro, independentemente do cronograma final, e as ações de fiscalização da OCR tornam essas áreas prioritárias, independentemente de a atualização formal ter sido concluída ou não.

O fim das especificações “sujeitas a exceção”. A maior mudança estrutural na regra proposta é a eliminação da distinção entre especificações de implementação “obrigatórias” e “sujeitas a exceção”. De acordo com as regras atuais, as especificações sujeitas a exceção permitem que as organizações justifiquem por que um controle não é adequado para seu ambiente. A regra proposta elimina essa flexibilidade para quase todas as especificações. Controles como a autenticação multifatorial (MFA) e a criptografia passariam a ser obrigatórios, sem qualquer possibilidade de exceção.

Autenticação multifatorial para todo o acesso a sistemas de ePHI. A proposta exigiria a autenticação multifatorial para todo o acesso a sistemas que criam, recebem, mantêm ou transmitem ePHI, incluindo o acesso remoto e o acesso presencial aos sistemas. Isso eliminaria uma lacuna comum em que entidades abrangidas de menor porte e parceiros comerciais classificavam a autenticação multifatorial como “inadequada” de acordo com a norma aplicável.

Criptografia em repouso e em trânsito. A criptografia de ePHI passaria de uma medida recomendada para uma exigência obrigatória, sem exceções. Os dados ePHI criptografados que forem perdidos ou roubados já se enquadram na exceção de “safe harbor” à notificação de violação, de acordo com as regras atuais. Tornar a criptografia obrigatória codifica o que as práticas defensáveis já exigem.

Segmentação de rede. Requisito proposto para isolar os sistemas que lidam com ePHI do restante da rede, incluindo a separação de dispositivos IoT, sistemas prediais e equipamentos médicos conectados. Isso é relevante para MSPs que gerenciam ambientes de saúde que cresceram organicamente e acumularam uma infraestrutura não segmentada.

Análise de vulnerabilidades e testes de penetração. A proposta prevê a realização de análises automatizadas de vulnerabilidades pelo menos a cada seis meses e de testes de penetração anuais nos sistemas de ePHI, conduzidos por profissionais qualificados em segurança cibernética, com documentação por escrito das conclusões e das medidas corretivas.

Requisitos de backup e recuperação. Requisitos mais explícitos para o backup de ePHI, incluindo cópias de backup offline, objetivos de tempo de recuperação documentados e atenção específica aos sistemas de backup visados por ransomware. Para os MSPs que gerenciam BCDR na área da saúde, isso significa que a arquitetura de backup e os testes de recuperação passam a ser evidências documentadas de conformidade, e não apenas melhores práticas operacionais.

Inventário de ativos e mapeamento de rede. Inventário documentado de todos os ativos de tecnologia que criam, recebem, mantêm ou transmitem ePHI, atualizado anualmente e após mudanças ambientais significativas. As ferramentas de detecção de ativos e os resultados do mapeamento de rede, já padrão na gestão de TI baseada em RMM, tornam-se provas formais de conformidade nos termos da norma proposta.

Requisitos mais rigorosos para os BAAs. A norma proposta exigiria que os BAAs especificassem as medidas de segurança técnicas implementadas pelo parceiro comercial e exigiria uma verificação anual de que essas medidas estão efetivamente em vigor. Um BAA assinado, por si só, não seria mais suficiente — as entidades abrangidas precisariam de provas documentadas de que seus parceiros comerciais estão cumprindo suas obrigações.

Notificação de violação por parceiros comerciais: notificação em 24 horas. A norma proposta exigiria que os parceiros comerciais notificassem as entidades abrangidas no prazo de 24 horas após a ativação de um plano de resposta a incidentes ou de contingência, tornando significativamente mais rigorosa a norma atual de “sem demora injustificada, no prazo de 60 dias”. Um MSP que detectasse um incidente de segurança afetando um cliente do setor de saúde às 23h de uma sexta-feira teria de notificar a entidade abrangida antes da meia-noite de sábado.

Para os MSPs que atendem clientes do setor de saúde, mesmo as mudanças propostas já indicam onde deve ser direcionado o investimento. Independentemente de a regulamentação final corresponder exatamente à proposta, a tendência em termos de fiscalização já está se movendo nessa direção.

Acordos de Parceria Comercial: a base para a conformidade do MSP

Um Acordo de Parceria Comercial (BAA) é um contrato exigido pela HIPAA entre uma entidade abrangida e seus parceiros comerciais. Sem um BAA, a entidade abrangida não pode compartilhar legalmente Informações de Saúde Protegidas (PHI) com o MSP. Atuar como parceiro comercial sem um BAA em vigor constitui uma violação da HIPAA para ambas as partes.

Um BAA em conformidade deve especificar:

• Quais dados de saúde protegidos (PHI) o parceiro comercial trata em nome da entidade abrangida
• Usos e divulgações permitidos de Informações de Saúde Protegidas (PHI)
• Medidas de segurança exigidas, com referência à Norma de Segurança da HIPAA
• Obrigações e prazos para notificação de violações
• Obrigações para com os subcontratados a jusante, incluindo os requisitos do sub-BAA
• Obrigações na rescisão do contrato: devolução ou destruição das informações de saúde protegidas (PHI)

Os MSPs que não tenham assinado um Acordo de Parceria Comercial (BAA) com todos os clientes do setor de saúde que lidam com Informações de Saúde Protegidas (PHI) estão em situação de violação. Essa é uma das deficiências mais frequentemente citadas na fiscalização da HIPAA e uma das mais facilmente evitáveis. As ações de fiscalização da OCR em 2025 incluíram explicitamente falhas na análise de risco e no BAA como principais constatações em diversos acordos com parceiros comerciais.

De acordo com a regra proposta, os BAAs precisariam ser significativamente mais específicos. Em vez de utilizar uma redação genérica sobre obrigações de segurança, os BAAs precisariam identificar as medidas de segurança técnicas específicas em vigor e incluir uma verificação anual de conformidade. Os MSPs devem revisar agora seus modelos de BAA existentes à luz dos requisitos propostos.

Compliance Manager GRC Kaseya oferece suporte à documentação de BAAs e à avaliação de lacunas na Regra de Segurança da HIPAA, proporcionando aos MSPs uma maneira estruturada de acompanhar quais clientes exigem BAAs, quais compromissos estão em vigor e quais evidências técnicas são necessárias para comprová-los. Conheça Compliance Manager GRC.

Aplicação da HIPAA: quais são as penalidades

As penalidades civis previstas na HIPAA são classificadas por grau de culpabilidade e ajustadas anualmente de acordo com a inflação:

– Nível 1, Desconhecido: de US$ 100 a US$ 50.000 por infração, com limite anual de US$ 25.000

– Nível 2, Motivo justificado: de US$ 1.000 a US$ 50.000 por infração, com limite anual de US$ 100.000

– Nível 3, negligência deliberada, corrigido: de US$ 10.000 a US$ 50.000 por infração, com limite anual de US$ 250.000

– Nível 4, negligência deliberada não corrigida: US$ 50.000 por infração, com limite anual de US$ 1,5 milhão

As sanções penais previstas na HIPAA podem chegar a US$ 250.000 e 10 anos de prisão em caso de violações cometidas de forma deliberada. Os procuradores-gerais estaduais também podem instaurar ações de fiscalização paralelas com base na legislação estadual, o que pode acarretar sanções adicionais e exigências de reparação.

A fiscalização da OCR atingiu um marco significativo em 2024, com 22 investigações que resultaram em multas civis ou acordos — um dos anos mais intensos em termos de fiscalização já registrados. Somente nos primeiros cinco meses de 2025, a OCR anunciou 10 acordos de resolução envolvendo entidades abrangidas e parceiros comerciais.

A constatação recorrente nas recentes ações de fiscalização: a falta de realização de uma análise de riscos completa e documentada. As ações de fiscalização da OCR em 2025 incluíram um acordo de US$ 3 milhões com uma empresa de faturamento médico que não havia realizado uma análise de riscos antes de um ataque de ransomware comprometer os dados de 585.000 pessoas. A empresa era uma parceira comercial, e não uma entidade abrangida pela lei. A responsabilidade direta das parceiras comerciais é uma realidade consolidada na prática da fiscalização, e não um risco teórico.

Criação de uma prática de MSP em conformidade com a HIPAA

As etapas a seguir se aplicam tanto às obrigações de um MSP como parceiro de negócios quanto aos programas de conformidade que ele implementa em nome de clientes do setor de saúde.

Passo 1: Identifique todos os clientes do setor de saúde que lidam com Informações de Saúde Protegidas (PHI). Saiba quem são seus clientes e quais dados circulam em seus ambientes. Isso determina o escopo de suas obrigações no âmbito do Acordo de Confidencialidade e de Serviços (BAA) e de seu próprio programa de conformidade.

Etapa 2: Assinar acordos de divulgação de informações (BAAs) com todos os clientes que sejam entidades abrangidas. Caso ainda não existam BAAs assinados com todos os clientes do setor de saúde que lidam com informações de saúde protegidas (PHI), essa é a prioridade imediata.

Etapa 3: Realizar uma análise de riscos documentada. A HIPAA exige uma análise de riscos de segurança precisa e minuciosa, que identifique os riscos aos ePHI nos sistemas que você gerencia, avalie a probabilidade e o impacto e documente as decisões de gestão de riscos. Essa é a base administrativa da conformidade. Sem uma análise de riscos documentada, nenhum outro controle técnico pode ser considerado em conformidade de forma defensável. O histórico de fiscalização da OCR em 2024 e 2025 mostra que a falha na análise de riscos é o caminho mais direto para um acordo judicial.

Etapa 4: Exigir a autenticação multifatorial (MFA) em todos os acessos a sistemas com ePHI. Considerando tanto as orientações atuais aplicáveis quanto a norma obrigatória proposta, a autenticação multifatorial (MFA) em todos os acessos a sistemas que contenham PHI é necessária para garantir uma conformidade justificável. Isso inclui o acesso remoto, contas de administrador e qualquer portal com acesso a sistemas clínicos.

Etapa 5: Implementar a criptografia. Criptografe as ePHI em repouso em todos os dispositivos gerenciados e em trânsito em todas as redes. As ePHI criptografadas que forem perdidas ou roubadas se enquadram na exceção de “safe harbor” à notificação de violação prevista na Regra de Notificação de Violação — a criptografia é tanto um controle de conformidade quanto uma ferramenta de redução de riscos na resposta a incidentes.

Etapa 6: Garantir um backup em conformidade com a HIPAA. O backup de ePHI deve incluir procedimentos de recuperação documentados, capacidade de restauração testada e cópias offline ou imutáveis que resistam a ataques de ransomware. O Datto BCDR oferece a capacidade técnica para MSPs que gerenciam ambientes de saúde; os procedimentos operacionais devem ser documentados e testados de acordo com objetivos de tempo de recuperação definidos.

Passo 7: Implemente o registro de auditoria. Registre todos os acessos aos sistemas que contenham ePHI. Analise os registros regularmente. Mantenha os registros por pelo menos seis anos, de acordo com a norma de retenção de registros da HIPAA.

Etapa 8: Documentar e testar a resposta a incidentes. A norma proposta exigiria a realização de testes anuais dos planos formais de resposta a incidentes. Documentar e testar os procedimentos de resposta a incidentes agora permite que você se antecipe à exigência e preencha uma lacuna que a OCR tem citado repetidamente em suas ações de fiscalização.

OCompliance Manager GRC um módulo de avaliação da Regra de Segurança da HIPAA que permite aos MSPs acompanhar o status de conformidade em relação aos requisitos atuais, realizar e documentar análises de risco, mapear controles para a Regra de Segurança e gerar evidências para auditorias da OCR ou análises de segurança dos clientes. Conheça aqui.