Novas regras do FedRAMP para detecção e resposta de vulnerabilidades entram em vigor em dezembro de 2026
A partir de 7 de dezembro de 2026, as regras de Detecção e Resposta de Vulnerabilidades (VDR) e de Verificação e Avaliação (VER) do FedRAMP tornam-se obrigatórias para todas as ofertas de serviços em nuvem que buscam ou mantém a certificação. Um período de carência vai até 7 de março de 2027 para serviços que operam sob um plano de ação corretiva.
O desafio não é apenas a data. A estrutura substituíu o modelo antigo de verificaoção mensal fixa e de Plano de Ação e Checklist (POA&M). A frequência de detecção agora varia conforme a classe de certificação: recursos baseados em máquina são verificados a cada 14 dias na Classe A, a cada 7 dias na Classe B, a cada 3 dias na Classe C e diariamente na Classe D.
As obrigações de verificação e validação de máquina são mais frequentes. Titulares do Rev5 devem realizar verificações de máquina pelo menos mensalmente, enquanto classes superiores 20x podem precisar de verificações a cada três dias. Os prazos para corrigir vulnerabilidades são divididos em camadas, com base na classificaoção de severidade (PAIN) e na facilidade de exploração. As janelas variam de 192 dias no caso de vulnerabilidades menos graves até 12 horas para casos extremos, como uma oferta de Classe D com uma vulnerabilidade PAIN 5 que é facilmente explorada remotamente.
A regra “Assume It’s Automatable” (VER rule EVA AIA) inverte o ônus da prova. Os provedores devem presumir que as explorações podem ser automatizadas, a menos que tenham evidências que demonstrem o contrário. Cada adiamento agora exige um artefato defensável produzido em volume e dentro do mesmo cronograma de outras atividades. Problemas ou falhas nos processos de detecção e resposta são tratados como vulnerabilidades em si (VDR rule CSO FAV). Se o pipeline de detecção parar silenciosamente, isso não é um contratempo operacional que pode ser corrigido discretamente – o sistema que gera as evidências estão dentro do escopo.
Juntos, esses cambios transformam o que é exigido. As organizações não precisam apenas aumentar a frequência de verificação; elas precisam de um sistema que gere respostas defensáveis, atuais e legíveis por máquina sobre sua própria exposição e que as responsabilize quando esse sistema deixa de funcionar. A documentação estrutural também se altera. O Plano de Segurança do Sistema e seus apêndices dão lugar a uma Visão Geral do Pacote de Certificação e a um Registro de Decisão de Segurança. Os Planos de Ação e Marcos foram eliminados completamente e substitúdos por uma lista de Fraquezas Aceitas.
O monitoramento contínuo é renomeado como Certificação Contínua, porque o termo anterior tinha se tornado sinônimo de verificações de vulnerabilidades. A expansão de escopo exige capacidade moderna de GRC, que deve ser populada com automação baseada em dados do mundo real, em vez de documentos artesanais. As exigências não demandam controles de segurança adicionais; elementos como controle de acesso, identidade, criptografia, logs, procedimentos de incidente e treinamento permanecem intactos e reutilizáveis.
O que mudou é que a mera descrição desses controles não é mais aceita como prova. O trabalho ainda é compliance, mas o produto final é agora engenharia: uma série de validações em execução que se conectam diretamente aos sistemas que contém a verdade (configuração em nuvem, provedor de identidades, SIEM, CI/CD, sistema de tickets) e emitem resultados legíveis por máquina segundo uma agenda definida. Os provedores devem validar continuamente os Indicadores-Chave de Segurança, com CR26 listando atualmente 49 indicadores em dez categorias. Esse é um requisito de entrada, por isso cada plano de transição se torna, na verdade, um plano de engenharia de automação.
A responsabilidade pela continuidade é contínua. Monitoramentos mensais tinham datas de vencimento, proprietários e um ritmo natural de catching up. Uma cadência de validação persistente executa sem interrupção ou para silenciosamente, e a diferença só se torna visível quando um avaliador ou cliente a descobre. Antes de construir pipelines, uma organização deve responder a perguntas operacionais: quem é alertado quando uma validação falha, qual o tempo de resposta e quem nota se uma fonte de evidência muda silenciosamente sua API.
Projetar para o ciclo, e não para o envío, é essencial. O FedRAMP define persistente como algo que ocorre de forma firme, constante e repetida ao longo do tempo, independentemente de interrupções. Essa mentalidade está transformar a maneira como os programas planejam o trabalho que vai além de dezembro e se preparam para o novo modelo que entra em vigor em 2027.
Com informações de: BleepingComputer