CRA para SaaS: escopo, ações próprias e evidências

Não existe uma resposta segura à pergunta «o SaaS está abrangido pelo CRA?» baseada apenas no modelo de subscrição. O CRA regula produtos com elementos digitais, enquanto os serviços de computação em nuvem — incluindo SaaS — também são tratados pelo enquadramento NIS2. A questão essencial é o que é o produto, que software é disponibilizado no mercado e se um serviço remoto é parte integrante de uma função do produto.

Comece pela arquitetura e pelo modelo de disponibilização, e não pela designação comercial.

Duas perguntas que são frequentemente confundidas

O próprio serviço de nuvem é um produto com elementos digitais ao abrigo do CRA?

Não o presuma apenas porque os utilizadores acedem ao software através de um navegador.

O serviço remoto faz parte de outro produto com elementos digitais?

Pode fazer. O CRA define uma «solução de tratamento remoto de dados» como tratamento de dados à distância cujo software é concebido e desenvolvido pelo fabricante ou sob a sua responsabilidade e cuja ausência impediria o produto com elementos digitais de desempenhar uma das suas funções.

Os considerandos do CRA apresentam um exemplo em que uma aplicação móvel precisa de aceder a uma API ou base de dados disponibilizada através de um serviço desenvolvido pelo fabricante. Nessa situação, o serviço pode estar abrangido pelo âmbito do produto como solução de tratamento remoto de dados.

Mapeie a arquitetura antes de decidir o âmbito

Para uma oferta SaaS, descreva separadamente:

software fornecido ao cliente — agente, aplicação de computador/móvel, equipamento dedicado, extensão, biblioteca;
interface Web — aquilo a que o utilizador acede no navegador;
backend/API — funções executadas remotamente;
bases de dados e tratamento — que elementos remotos são necessários às funções do produto;
integrações de terceiros — o que está sob a responsabilidade do fabricante e o que não está;
modelo de mercado — quem disponibiliza a solução e sob que marca;
atualizações — que elementos são alterados pelo fabricante e como afetam a segurança;
apoio — durante quanto tempo é mantido cada componente relevante.

Esse mapa apoia tanto a avaliação do âmbito como a documentação técnica posterior.

Três situações de exemplo

A. Serviço de nuvem acessível apenas pelo navegador

O utilizador inicia sessão num serviço através de um navegador sem receber um produto separado de software/hardware. Não passe diretamente de «SaaS» para «o CRA aplica-se». Verifique as definições CRA e as orientações atuais da Comissão e avalie separadamente as obrigações NIS2 quando forem relevantes para a organização.

B. Produto de software com backend operado pelo fabricante

O cliente recebe uma aplicação ou componente cuja função importante não pode funcionar sem um backend concebido pelo fabricante. O tratamento remoto pode fazer parte do produto para efeitos do CRA.

C. Um produto utiliza um serviço de nuvem independente

Quando o serviço é concebido e desenvolvido fora da responsabilidade do fabricante, a relação pode diferir da de um backend próprio. «Os dados estão na nuvem» não responde, por si só, à questão do CRA.

Estes são exemplos de orientação, e não determinações jurídicas para uma arquitetura concreta.

Por que motivo isso é operacionalmente relevante agora

O artigo 14 aplica-se desde 11 de setembro de 2026 e estende-se aos produtos abrangidos colocados no mercado antes de 11 de dezembro de 2027.

Se uma oferta é composta por uma aplicação, um componente e um backend, a equipa tem de saber, para o produto e a versão pertinentes:

onde são recebidas as comunicações de vulnerabilidades;
quem faz a triagem;
como é avaliado o impacto no produto;
como são disponibilizadas as correções;
como são informados os utilizadores;
quando é desencadeada a avaliação da obrigação de notificação CRA.

Sem limites claros do produto, é difícil definir o T0, a atribuição de responsabilidade ou o âmbito de uma notificação.

O que registar numa decisão de âmbito SaaS

diagrama dos limites do produto;
elementos fornecidos localmente;
elementos executados remotamente;
função assegurada por cada elemento;
se a remoção do elemento remoto impede uma função do produto;
responsabilidade pelo desenvolvimento do elemento remoto;
modelo de distribuição e marca;
papel da organização;
fundamento jurídico/orientações utilizados na avaliação;
pessoa que aprova o resultado;
data da próxima revisão.

Como o Pulsar pode ajudar

O Pulsar pode conservar a decisão sobre o âmbito e os artefactos de apoio, ligando o resultado a riscos, documentos, ações, fornecedores e provas. Quando a arquitetura muda numa versão posterior, a decisão pode regressar à revisão, em vez de permanecer num PDF desatualizado.

O Pulsar não deve apresentar autonomamente uma resposta juridicamente definitiva «o CRA aplica-se / não se aplica» sem fundamento passível de revisão e aprovação humana.

Veja o Pulsar GRC num fluxo de avaliação

Orientações relacionadas

Método proposto: uma ficha de arquitetura por oferta

Imagine uma empresa que vende uma consola web, uma aplicação móvel e um agente instalado nos equipamentos do cliente na mesma subscrição. Perguntar se «a subscrição» está abrangida esconde diferenças. A avaliação identifica componentes fornecidos, funções e tratamento remoto que possa integrar o produto conforme definições legais. O exemplo é hipotético e não determina a conclusão de uma arquitetura concreta.

Prepare uma vista simples: o agente recolhe informação local, a aplicação apresenta avisos e o backend processa dados. Indique quem desenvolve cada componente, sob que responsabilidade e como chega ao mercado. Não é necessário expor segredos para explicar limites. É necessário precisão suficiente para que outra pessoa compreenda dependências relevantes.

Utilize uma pergunta conceptual: que função deixa de funcionar se retirar o componente remoto? Descreva a função concretamente. «Melhora a experiência» é demasiado vago. «O agente não recebe a política necessária para cumprir a função prevista» permite analisar a relação. A interpretação jurídica ainda precisa de rever factos, regulamento e orientações, não apenas essa frase.

Separe oferta, produto e entidade

Uma oferta pode incluir elementos com avaliações diferentes. A empresa pode assumir papéis distintos em cada um. Registe a unidade analisada e a relação com o contrato. Assim evita estender uma conclusão sobre uma função web a um agente descarregável que não foi revisto.

A avaliação NIS2 segue um percurso organizacional próprio, com serviços, dimensão, exceções e lei nacional. Um resultado CRA não determina automaticamente que NIS2 se aplica ou deixa de se aplicar. Os dossiers podem partilhar arquitetura ou continuidade, mas conservam fundamentos e aprovações separados. Uma regra polaca traduzida não passa a ser uma obrigação portuguesa.

Quando o papel da empresa é incerto, consulte contratos, marca e modelo de desenvolvimento. Alojar um componente não determina, por si só, responsabilidade de o desenvolver. Chamar «serviço» à oferta também não resolve a interpretação. Identifique dúvidas e quem as deve esclarecer antes de aprovar uma conclusão.

Alterações que podem reabrir a avaliação

Acrescentar software que o cliente instala pode mudar o objeto analisado. Uma função antes acessível por navegador pode passar a incluir agente, extensão ou aplicação. Antes de publicar, reveja se a decisão anterior ainda cobre a nova oferta. Conserve o diagrama e os factos utilizados na avaliação.

Transferir uma função essencial para backend próprio pode alterar a relação com tratamento remoto. Engenharia explica o que se executava localmente e o que passa a executar-se no serviço. Reveja atualizações, vulnerabilidades e informação ao utilizador. Uma alteração curta no código pode ser material para a documentação.

Comercializar um componente sob outra marca ou modificá-lo pode mudar o papel de operador económico. Não copie a avaliação do fornecedor sem confirmar a responsabilidade agora assumida. A informação recebida é uma fonte útil, mas não substitui a avaliação da oferta efetivamente fornecida pela empresa.

Factos e conclusões em registos distinguíveis

Os factos incluem componentes, funções, versões e responsáveis de desenvolvimento. As conclusões interpretam esses factos face ao direito e orientações. Separá-los permite rever interpretação sem perder o inventário técnico. Também revela que pressuposto continua por confirmar.

Associe cada facto material a uma fonte: arquitetura, contrato, descrição ou revisão de engenharia. Cada conclusão identifica fundamento, aprovador e data. Se a IA propõe classificação, conserve-a como rascunho até uma pessoa verificar factos e inferência. Um erro sobre quem desenvolve o serviço remoto pode levar a analisar outro produto.

Um dossier pode terminar com dúvida delimitada e uma ação para a resolver. Não ganha qualidade por declarar mais certeza. «Fora do âmbito» sem arquitetura suficiente é uma afirmação frágil. A incerteza deve permanecer visível e limitar declarações comerciais definitivas que ainda não podem defender-se.

Ligação à gestão de vulnerabilidades

No cenário proposto, um aviso afeta o agente, mas a correção altera também backend. Identifique versões locais, serviço relacionado e responsável de publicação. Se registar apenas a mudança remota, pode perder relação com produto que continua nos equipamentos dos utilizadores.

Teste quem conhece utilizadores afetados, como se verifica a correção e quem decide comunicação. Não assuma atualização imediata de todas as instalações. Registe ramos e configurações que exigem seguimento. A avaliação de notificação quando aplicável utiliza esse contexto, juntamente com o fundamento jurídico pertinente.

Critérios de aceitação da avaliação

Outra pessoa deve distinguir elementos locais, remotos e externos, explicar papel da empresa e localizar fontes. Deve saber que alteração reabre a decisão. Se a conclusão depende só da etiqueta «SaaS», o trabalho não terminou. Se o diagrama contradiz contrato ou documentação de engenharia, preserve e resolva a diferença.

O Pulsar pode conservar dossier, riscos e ações. A organização mantém revisão técnica e jurídica e utiliza canais próprios para comunicações exigidas. O resultado útil é um limite de produto explicado e revisável. Isso permite organizar trabalho sem transformar um modelo de subscrição numa isenção nem numa inclusão automática.

Considere também funções ativadas por configuração. Uma oferta pode parecer igual no contrato e ter uma dependência remota diferente quando um cliente ativa determinada opção. Engenharia deve explicar se essa opção modifica a função prevista, os componentes fornecidos ou a responsabilidade pelo tratamento. A ficha identifica quais configurações foram avaliadas e quais exigem revisão. Não estenda automaticamente uma conclusão da configuração básica a todas as combinações disponíveis.

Como exercício, selecione uma opção que foi acrescentada recentemente e compare arquitetura anterior e atual. Produto confirma como se apresenta ao utilizador; engenharia identifica o que mudou; a função competente revê o efeito no fundamento de âmbito. Conserve a decisão e os limites. Se a documentação comercial ainda não reflete a alteração, atribua ação específica em vez de assumir que o contrato resolveu a questão. Um registo de configuração ajuda a relacionar vulnerabilidades e comunicações posteriores com a oferta efetivamente utilizada. O objetivo é identificar diferenças materiais antes da publicação, sem transformar cada opção numa conclusão jurídica automática.

Ensaie um requisito e um resultado revisado

Use um produto fictício que consiste em um cliente de desktop e um back-end operado pelo fabricante. Este é um exemplo de arquitetura sintética, não uma declaração de que todo serviço SaaS se enquadra no CRA. Primeiro registre a função do produto, a função do backend e a questão que precisa de revisão qualificada do escopo. Mantenha a fonte legal e a decisão de revisão em ficheiro.

Uma vez explícitas as suposições de aplicabilidade do exemplo, escolha um requisito relevante e uma ação. Atribua um proprietário e uma data e defina quais evidências demonstrariam o resultado da ação. Por exemplo, a ação pode revisar uma regra de acesso ao produto e anexar a descrição e o resultado fictícios do teste. Uma pessoa autorizada analisa as evidências de acordo com o critério declarado. Um ficheiro anexado à ação não completa essa revisão por si só.

No Pulsar, leia o requisito, a ação vinculada, a versão de origem e a evidência após salvar. Peça a um colega para identificar a próxima responsabilidade sem explicação do autor. O resultado concreto do teste é um fragmento inspecionável do trabalho do produto. Não se trata de uma classificação CRA automática, avaliação de conformidade, declaração CE ou apresentação a uma autoridade.

Pulsar oferece um teste de 14 dias que requer uma forma de pagamento. Revise o plano selecionado, o preço pós-teste e os termos de cancelamento antes de confirmar. Use registos sintéticos para este exercício; uma decisão real sobre um produto requer sua própria arquitetura e revisão qualificada.

Fontes

Fontes verificadas: 12 de setembro de 2026.

Pulsar GRC — acesso, isolamento de dados e exportação (polaco) Fontes verificadas: 2026-10-10.
CRA — Regulation (EU) 2024/2847 — Escopo do produto e obrigações aplicáveis.
European Commission — CRA guidance, 27 July 2026 — Orientação oficial sobre escopo e implementação.
European Commission — CRA legislative summary — Escopo, tratamento de vulnerabilidades e datas de aplicação.
Pulsar GRC — features — Requisitos, ações e evidências registradas.
Pulsar GRC — pricing — Termos de teste.
Escopo do produto e termos de avaliação publicados — Escopo do produto e termos de avaliação publicados. Revise os termos e inicie o teste de 14 dias

Vulnerabilidades de componentes IoT: fornecedores, decisões e correções

KSC/NIS2 polaco para fornecedores de TI: avaliação e registo de ações

API e MCP no GRC: defina o acesso antes de conectar sistemas