Evidência DMARC para ISO 27001, NIS2, DORA e RGPD da UE

Tudo começa quando um diretor financeiro reencaminha uma mensagem de correio eletrónico para o CISO às 07:42.

“Fomos nós que enviámos isto?”

A mensagem parece perfeita. O mesmo logótipo, o mesmo rodapé, o mesmo tom da equipa de faturação. Afirma que os dados bancários foram alterados. O nome de apresentação do remetente está correto. O domínio não é uma imitação com erro tipográfico. O atacante está a falsificar o domínio real.

Às 08:15, a equipa de segurança confirma a realidade incómoda: existe SPF, mas é demasiado abrangente; o DKIM está ativado apenas para a plataforma principal de correio eletrónico; várias ferramentas de marketing enviam mensagens sem assinatura; o DMARC ainda está em modo de monitorização; e ninguém consegue encontrar a última revisão da política MTA-STS do domínio. A organização tem “segurança do correio eletrónico” num conjunto de diapositivos, mas a evidência está dispersa por capturas de ecrã de DNS, portais de fornecedores, tickets Jira antigos e uma folha de cálculo pertencente a alguém que saiu no ano passado.

Às 10:30, o departamento jurídico pergunta se podem estar envolvidos dados pessoais de clientes. A função de conformidade pergunta se isto é relevante para reporte ao abrigo da NIS2. Um cliente de serviços financeiros pergunta se a empresa consegue demonstrar controlos de risco das TIC alinhados com o DORA. A auditoria interna pergunta como isto se mapeia para a ISO/IEC 27001:2022. O conselho de administração faz uma pergunta mais simples: “Porque é que alguém conseguiu fazer-se passar por nós?”

Essa pergunta explica porque, em 2026, a autenticação de correio eletrónico deixou de ser um tema técnico restrito a DNS. DMARC, SPF, DKIM, MTA-STS e TLS-RPT são controlos que produzem evidência. Reduzem o risco de phishing e falsificação de domínio, mas também geram os artefactos que os auditores esperam: decisões de política, responsabilidade atribuída, configurações técnicas de referência, responsabilização de fornecedores, logs, registos de monitorização, exceções, aprovações de alterações e acionadores de resposta a incidentes.

O problema de conformidade não é “Temos DMARC?”. É “Conseguimos provar que a autenticação de correio eletrónico é governada, monitorizada, revista e ligada ao risco?”.

A lacuna de evidência que os auditores continuam a encontrar

Um segundo cenário é igualmente comum. Está a decorrer uma auditoria externa numa fintech em rápido crescimento. O auditor passa da continuidade de negócio para a gestão de incidentes e pergunta ao CISO sobre comprometimento de correio eletrónico empresarial.

O CISO explica que a empresa tem filtros anti-phishing e formação trimestral de sensibilização em segurança.

O auditor acena com a cabeça e depois pede algo mais específico: “Mostre-me a governação em torno de DMARC, SPF e DKIM. Preciso de ver propriedade, registos de alterações, avaliação de riscos, evidência de monitorização e como isto se relaciona com a higiene de cibersegurança da NIS2 e o quadro de gestão do risco das TIC do DORA.”

A sala fica em silêncio.

A equipa técnica implementou DMARC há meses, mas o SGSI não tem referência em política, não tem pacote central de evidência, não tem ligação ao registo de riscos e não tem um roteiro aprovado de aplicação efetiva. O controlo pode existir tecnicamente, mas é invisível para a governação.

Essa é a lacuna de evidência.

Um programa maduro de autenticação de correio eletrónico responde a seis perguntas de auditoria:

1. Que domínios e subdomínios estão no âmbito?
2. Quem é responsável por cada domínio, zona DNS, fluxo de correio e serviço de envio?
3. Que sistemas estão autorizados a enviar em nome da organização?
4. Que mecanismos de autenticação são aplicados, monitorizados e revistos?
5. Como são aprovadas as exceções, aceite o risco e retiradas as exceções?
6. Que evidência comprova que o controlo operou ao longo do tempo?

A ISO/IEC 27001:2022 transforma isto numa questão de sistema de gestão. As cláusulas 4.1 a 4.4 exigem que a organização compreenda o contexto, os requisitos das partes interessadas, os limites do âmbito, as interfaces e as dependências. A autenticação de correio eletrónico toca todos estes elementos. O seu registador de domínios pode ser um fornecedor. O DNS pode estar alojado em infraestrutura de nuvem. O CRM, a plataforma de processamento salarial, a ferramenta de faturação, o fornecedor de automatização de marketing e o sistema de suporte ao cliente podem enviar correio eletrónico usando a sua marca.

As cláusulas 5.1 a 5.3 tornam isto uma questão de liderança. A gestão de topo deve atribuir responsabilidades e integrar a segurança da informação nos processos de negócio. Uma decisão DMARC de p=none para p=quarantine ou p=reject pode afetar comunicações com clientes, notificações financeiras, integração de recursos humanos, campanhas comerciais e fornecedores externalizados.

As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos, seleção de controlos e uma Declaração de Aplicabilidade. A falsificação de domínio deve ser tratada como um cenário de risco, com SPF, DKIM, DMARC, MTA-STS e TLS-RPT selecionados como parte do tratamento, quando adequado. A cláusula 8.1 exige depois planeamento e controlo operacional, incluindo controlo sobre processos, produtos e serviços fornecidos externamente que sejam relevantes para o SGSI.

O que cada controlo de autenticação de correio eletrónico comprova

SPF, DKIM, DMARC, MTA-STS e TLS-RPT funcionam em conjunto, mas comprovam aspetos diferentes.

SPF e DKIM são sinais de identidade e integridade. DMARC é a camada de política que transforma esses sinais em ação por parte do destinatário. MTA-STS e TLS-RPT apoiam o transporte seguro de correio eletrónico, ajudando a prevenir riscos de downgrade e de configuração incorreta.

Para os auditores, o valor mais profundo está na evidência repetível. Os relatórios agregados DMARC mostram quem envia como se fosse o seu domínio. Os relatórios TLS mostram se a entrega cifrada está a falhar. Os tickets de alteração mostram se existe governação. Os registos de fornecedores mostram se as dependências da cadeia de fornecimento são conhecidas.

Coloque primeiro os domínios no registo de ativos

A autenticação de correio eletrónico não pode ser governada se os domínios não forem tratados como ativos.

A Política de Gestão de Ativos para PME Política de Gestão de Ativos - PME inclui explicitamente os domínios e identidades relacionadas com correio eletrónico no âmbito:

“Credenciais e serviços digitais: nomes de domínio, certificados digitais, chaves de API, contas de correio eletrónico, credenciais de acesso à nuvem”

Da secção “Âmbito”, cláusula 2.2.4 da política.

Para organizações de maior dimensão, a Política de Gestão de Ativos Política de Gestão de Ativos aplica a mesma lógica:

“Ativos lógicos: nomes de domínio, licenças, contas de utilizador, configurações de referência”

Da secção “Âmbito”, cláusula 2.2.5 da política.

Se os domínios forem ativos, podem ter responsáveis, classificações de criticidade, ciclos de revisão, dependências de fornecedores, controlos de alterações e localizações de evidência. Se forem apenas entradas DNS, ficam normalmente por gerir até algo falhar.

Um registo de domínios e de envio de correio eletrónico preparado para auditoria deve incluir:

Este registo apoia o controlo A.5.9 do Anexo A da ISO/IEC 27001:2022, Inventário de informação e outros ativos associados, A.8.9 Gestão da configuração, A.5.19 Segurança da informação nas relações com fornecedores e A.5.23 Segurança da informação na utilização de serviços de nuvem. Também apoia os resultados de inventário do NIST CSF 2.0 para ativos, serviços, fornecedores e criticidade.

Use a gestão de alterações para decisões de DNS e fluxo de correio

A autenticação de correio eletrónico falha quando a gestão de alterações é fraca. Uma equipa comercial adiciona uma plataforma de prospeção. Recursos humanos adota uma ferramenta de acompanhamento de candidatos. A área financeira altera o software de faturação. O marketing migra para um novo fornecedor de serviços de correio eletrónico. Cada decisão de negócio cria um novo remetente.

A Política de Gestão de Alterações empresarial Política de Gestão de Alterações torna explícito o requisito de evidência:

“Todos os pedidos de alteração, revisões, aprovações e evidência de suporte devem ser registados no Sistema de Gestão de Alterações centralizado.”

Da secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.

Um ticket robusto de alteração de autenticação de correio eletrónico deve incluir:

• Justificação de negócio para o novo remetente.
• Domínio ou subdomínio afetado.
• Impacto de SPF include ou IP de envio.
• Seletor DKIM e propriedade da chave.
• Resultado do teste de alinhamento DMARC.
• Impacto em MTA-STS ou MX, se aplicável.
• Classificação de dados das mensagens enviadas.
• Referência da revisão de segurança do fornecedor.
• Plano de reversão.
• Aprovação pelo responsável pelo domínio e pela segurança.
• Evidência de testes pós-implementação.
• Data de revisão ou de expiração para definições temporárias.

Esta é a diferença entre “um administrador DNS alterou um registo” e “o SGSI controlou uma alteração relevante para o risco”.

Um plano prático de 30 dias para evidência de DMARC, SPF, DKIM e MTA-STS

Um CISO não precisa de um projeto de transformação de seis meses para melhorar a maturidade da evidência. Um sprint focado de 30 dias pode produzir uma base defensável.

Semana 1: Descobrir domínios, remetentes e responsabilidades

Exporte todos os domínios do registador e do fornecedor DNS. Recolha dados de fluxo de correio do gateway de correio eletrónico, CRM, helpdesk, plataforma de marketing, sistema de faturação e serviços de notificação na nuvem. Construa o registo de domínios e envio.

Inclua também domínios estacionados e registos defensivos. Os domínios estacionados são frequentemente ignorados, mas ainda podem ser abusados se o DMARC estiver ausente ou for fraco.

Semana 2: Corrigir o alinhamento SPF e DKIM

Reveja SPF para mecanismos demasiado permissivos, includes obsoletos, fornecedores duplicados e riscos de limite de consultas. Para DKIM, identifique todos os remetentes que não assinam correio ou que assinam com um domínio que não ficará alinhado com DMARC.

Não aprove um remetente SaaS apenas porque o correio está a funcionar. Aprove-o porque:

• O fornecedor está listado no registo de envio.
• A configuração SPF e DKIM está documentada.
• Os seletores DKIM estão inventariados.
• A propriedade das chaves e as expectativas de revisão são claras.
• A documentação de segurança do fornecedor apoia o tratamento seguro de correio eletrónico.
• O responsável de negócio aceita qualquer exceção temporária.

É aqui que a NIS2 e o DORA se tornam práticos. O Article 21 da NIS2 exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e manutenção seguras, avaliação de eficácia, higiene de cibersegurança, criptografia, controlo de acesso e comunicações seguras. O Article 28 do DORA exige que as entidades financeiras giram o risco das TIC de terceiros como parte do quadro de gestão do risco das TIC, incluindo diligência prévia, expectativas contratuais, monitorização e planeamento de saída.

Se um fornecedor de marketing envia correio eletrónico não autenticado usando o seu domínio, isso não é apenas um problema de marketing. É risco de fornecedor, risco de personificação indevida da marca e potencial dano para clientes.

Semana 3: Levar o DMARC para aplicação efetiva

O modo de monitorização é útil, mas p=none permanente sem um roteiro aprovado constitui evidência fraca.

Um plano defensável de aplicação efetiva de DMARC deve incluir:

• Revisão de referência dos relatórios agregados.
• Identificação de fontes legítimas e ilegítimas.
• Remediação de fontes legítimas que falham.
• Validação pelo negócio dos fluxos críticos de correio.
• Aumento gradual da política para pct=25, pct=50, pct=100.
• Transição de p=none para p=quarantine.
• Transição para p=reject quando o risco e a preparação do negócio o permitirem.
• Tratamento separado para subdomínios com sp=.
• Registo de exceções com datas de expiração.
• Aprovação pela gestão para risco residual.

Isto apoia a cláusula 6.1.3 da ISO/IEC 27001:2022 relativa ao tratamento de riscos e a cláusula 8.1 relativa ao planeamento e controlo operacional. Também fornece à auditoria interna um trilho claro: decisão, implementação, monitorização, exceção, aprovação e revisão.

Semana 4: Validar MTA-STS, TLS-RPT e monitorização

O MTA-STS é frequentemente esquecido porque não impede a falsificação de marca no envio da mesma forma que o DMARC. Mas é altamente relevante para comunicações seguras e proteção da informação em trânsito. Indica aos servidores de envio compatíveis que o correio para o seu domínio deve ser entregue por TLS e valida a identidade MX.

A Política de Controlos Criptográficos empresarial Política de Controlos Criptográficos define uma base clara de segurança de transporte:

“Segurança de transporte: TLS 1.2 ou superior (preferencialmente TLS 1.3)”

Da secção “Requisitos de implementação da política”, cláusula 6.1.1.5 da política.

Para PME, a Política de Controlos Criptográficos para PME Política de Controlos Criptográficos - PME inclui explicitamente a transmissão por correio eletrónico:

“Dados transmitidos por correio eletrónico, VPN corporativas e portais web”

Da secção “Requisitos de implementação da política”, cláusula 6.1.1.4 da política.

Os testes devem incluir validação TLS de MX, disponibilidade do ficheiro de política MTA-STS, estado dos certificados HTTPS, revisão de relatórios TLS-RPT e registos de triagem de falhas.

Mapear a autenticação de correio eletrónico para o Anexo A da ISO/IEC 27001:2022

O Zenith Controls: The Cross-Compliance Guide da Clarysec Zenith Controls ajuda a ligar evidência técnica a expectativas de auditoria em vários referenciais. Não é um conjunto de controlos separado. É um guia de mapeamento e auditoria para controlos da ISO/IEC 27001:2022 e normas relacionadas.

Para o controlo A.5.14 do Anexo A da ISO/IEC 27001:2022, Transferência de informação, o Zenith Controls explica a relação com a criptografia:

“A transferência segura de informação assenta em controlos criptográficos, conforme detalhado em 8.24.”

Esta é a relação entre correio eletrónico de negócio, DKIM, MTA-STS e TLS. O correio eletrónico é um canal de transferência de informação. O DKIM apoia a autenticidade e a integridade das mensagens. O MTA-STS e o TLS apoiam a proteção do transporte.

Para o controlo A.8.24 do Anexo A, Utilização de criptografia, o Zenith Controls liga a criptografia à transferência de informação, privacidade, proteção de informações pessoais identificáveis (PII), classificação e gestão de vulnerabilidades. Para os controlos A.8.15 Registo de eventos e A.8.16 Atividades de monitorização do Anexo A, o guia liga registos e monitorização à gestão de eventos, recolha de evidência, revisão, análise e auditabilidade.

A Política de Registo de Eventos e Monitorização para PME Política de Registo de Eventos e Monitorização - PME estabelece:

“O registo deve ser ativado e configurado sempre que disponível”

Da secção “Requisitos de governação”, cláusula 5.5.1.1 da política.

A Política de Registo de Eventos e Monitorização empresarial Política de Registo de Eventos e Monitorização inclui:

“Comunicações externas e acionadores de regras de firewall”

Da secção “Requisitos de implementação da política”, cláusula 6.1.1.6 da política.

Para a autenticação de correio eletrónico, as comunicações externas devem incluir eventos do gateway de correio, processamento de relatórios agregados DMARC, tendências de falha DKIM, infraestrutura de origem suspeita, falhas TLS-RPT e tentativas de falsificação que acionam triagem de incidentes.

O Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint coloca isto na validação prática de controlos. Na fase Controls in Action, Passo 20, instrui as equipas a validar a segurança dos serviços de rede:

“Liste todos os serviços de rede internos e externos (DNS, VPN, SMTP, DHCP, gateways de API, etc.).

✓ Para cada um, confirme que utiliza protocolos seguros (por exemplo, DNSSEC, TLS 1.2+, SSH em vez de Telnet).
✓ Reveja como o acesso a cada serviço é controlado (por exemplo, listas de permissões por IP, autenticação, certificados).
✓ Se forem geridos por terceiros (por exemplo, DNS, SD-WAN, VPN alojada), reveja as cláusulas de segurança no SLA ou no contrato do fornecedor. Atualize o seu registo de serviços e indique onde residem as responsabilidades de segurança, internas ou externas.”

Aplicado ao correio eletrónico, isto torna-se um plano de trabalho para DNS, SMTP, TLS, gateways de correio alojados, remetentes de fornecedores e limites de responsabilidade.

Mapeamento de conformidade cruzada: um pacote de evidência, muitas obrigações

O mesmo pacote de evidência pode apoiar ISO/IEC 27001:2022, NIS2, DORA, RGPD da UE e NIST CSF 2.0 se for estruturado corretamente.

A NIS2 é especialmente relevante para entidades essenciais e importantes, bem como para certas categorias de infraestrutura digital e prestadores digitais. O Article 20 torna a governação da cibersegurança uma responsabilidade do órgão de gestão, enquanto o Article 21 estabelece a linha de base de gestão de riscos. A evidência de autenticação de correio eletrónico ajuda a demonstrar que comunicações seguras, relações com fornecedores, tratamento de incidentes, avaliação de eficácia e higiene de cibersegurança são operacionais, não teóricas.

Para entidades financeiras, o DORA aplica-se desde 17 de janeiro de 2025. Os Articles 5 e 6 exigem responsabilização do órgão de gestão e um quadro documentado de gestão do risco das TIC. O Article 17 exige processos para detetar, gerir, registar, classificar, escalar e remediar incidentes relacionados com as TIC. O Article 28 torna a gestão do risco das TIC de terceiros uma responsabilidade formal. Fornecedores de correio eletrónico, plataformas de marketing, sistemas de notificação de pagamentos e ferramentas de comunicação com clientes podem todos integrar essa cadeia de dependência das TIC.

Para o RGPD da UE, a questão-chave é saber se o correio eletrónico é usado para tratar dados pessoais. O Article 5 inclui integridade, confidencialidade e responsabilização. O Article 32 exige medidas técnicas e organizativas adequadas. Se faturas, mensagens de recursos humanos, avisos de conta, tickets de suporte ou mensagens de integração contiverem dados pessoais, a autenticação de correio eletrónico e a segurança de transporte tornam-se parte da evidência de segurança do tratamento.

Resposta a incidentes: quando os relatórios se tornam alerta precoce

Os relatórios agregados DMARC não são apenas evidência de conformidade. São dados de alerta precoce. Um pico de falhas de autenticação a partir de infraestrutura desconhecida pode indicar falsificação ativa, TI sombra, configuração incorreta de fornecedor ou um remetente comprometido.

Nos termos do Article 23 da NIS2, as entidades essenciais e importantes devem notificar incidentes significativos sem demora injustificada, usando reporte faseado que inclui alerta precoce, notificação de incidente e relatório final. Nem todas as tentativas de falsificação são reportáveis, mas a organização deve ser capaz de avaliar severidade, interrupção operacional, perda financeira, impacto transfronteiriço e danos para os destinatários.

Nos termos do Article 17 do DORA, as entidades financeiras devem definir e implementar um processo de gestão de incidentes relacionados com as TIC, registar incidentes e ameaças cibernéticas significativas, identificar causas raiz, utilizar indicadores de alerta precoce, classificar por severidade e criticidade do serviço, atribuir papéis, definir comunicações e escalar incidentes graves. O Article 19 do DORA aborda depois o reporte de incidentes graves relacionados com as TIC.

Para o RGPD da UE, a questão é saber se o evento causou destruição, perda, alteração, divulgação não autorizada ou acesso a dados pessoais, de modo acidental ou ilícito. Uma mensagem falsificada que induz clientes a submeter dados pessoais a um atacante pode desencadear uma avaliação de violação de dados pessoais, mesmo que os sistemas internos não tenham sido comprometidos.

A Política de Auditoria e Monitorização da Conformidade empresarial Política de Auditoria e Monitorização da Conformidade explica porque é que a evidência disciplinada é importante:

“Gerar evidência defensável e um trilho de auditoria em apoio a pedidos de esclarecimento regulamentares, litígios ou pedidos de garantia por parte de clientes.”

Da secção “Objetivos”, cláusula 3.4 da política.

A Política de Auditoria e Monitorização da Conformidade para PME Política de Auditoria e Monitorização da Conformidade - PME acrescenta um requisito de qualidade da evidência:

“Os metadados (por exemplo, quem os recolheu, quando e a partir de que sistema) devem ser documentados.”

Da secção “Requisitos de implementação da política”, cláusula 6.2.3 da política.

Um ficheiro de investigação DMARC deve, por isso, documentar a fonte do relatório, hora de recolha, analista, domínios afetados, IPs de remetentes suspeitos, resultados de autenticação, avaliação de impacto no negócio, decisões tomadas e aprovação de encerramento.

O que os auditores vão pedir

Auditores diferentes usam linguagem diferente, mas a evidência sobrepõe-se.

Espere perguntas práticas:

• Mostre os relatórios DMARC do último trimestre.
• Mostre como foram revistos.
• Mostre a exceção para este remetente em falha.
• Mostre quem aprovou esta alteração SPF.
• Mostre se os seletores DKIM estão inventariados e revistos.
• Mostre como o MTA-STS é testado após alterações ao gateway de correio.
• Mostre como os eventos de falsificação entram na triagem de incidentes.
• Mostre como os remetentes de fornecedores são removidos na cessação do contrato.

Uma lista de verificação concisa de auditoria interna para 2026

Use esta lista de verificação como ponto de partida para auditoria interna, testes de controlo ou uma revisão de evidência de autenticação de correio eletrónico.

• Todos os domínios e subdomínios estão listados no registo de ativos.
• Domínios estacionados e defensivos têm cobertura DMARC.
• Cada remetente autorizado tem um responsável de negócio e um responsável técnico.
• Os registos SPF são revistos quanto a includes obsoletos e âmbito excessivo.
• O DKIM está ativado para remetentes legítimos quando suportado.
• Os seletores DKIM estão inventariados e revistos.
• O DMARC está implementado para domínios raiz e subdomínios relevantes.
• O DMARC tem um roteiro de aplicação efetiva, não monitorização indefinida.
• Os relatórios agregados DMARC são revistos segundo uma cadência definida.
• O MTA-STS está configurado para domínios de correio de entrada quando aplicável.
• Os relatórios TLS-RPT são recolhidos e triados.
• As alterações de autenticação de correio eletrónico seguem a gestão de alterações.
• A integração de fornecedores inclui requisitos de envio de correio eletrónico.
• A desvinculação de fornecedores remove SPF includes, seletores DKIM e permissões de envio.
• As exceções têm proprietários do risco, datas de expiração e controlos compensatórios.
• Picos de falsificação e falhas de autenticação alimentam a resposta a incidentes.
• A evidência inclui metadados, fonte, data, responsável pela recolha e sistema.
• A gestão recebe métricas periódicas e atualizações de risco.

O Zenith Blueprint, fase de gestão de riscos, Passo 14, recomenda criar tabelas de mapeamento regulamentar para obrigações aplicáveis:

“Para cada regulamento, se aplicável, pode criar uma tabela simples de mapeamento (que pode ser um anexo num relatório) que enumere os requisitos-chave de segurança do regulamento e os controlos/políticas correspondentes no seu SGSI. Isto não é obrigatório na ISO 27001, mas é um exercício interno útil para assegurar que nada fica por tratar. Também demonstra aos auditores/avaliadores que não está a gerir a segurança no vazio, mas com consciência do contexto legal.”

Para a autenticação de correio eletrónico, essa tabela torna-se a ponte entre a realidade técnica de DNS e a garantia ao nível do conselho de administração.

Transforme a autenticação de correio eletrónico em evidência preparada para auditoria

Os seus clientes podem nunca perguntar se o seu registo SPF tem sintaxe perfeita. Vão perguntar se consegue proteger a sua marca, reduzir o risco de phishing, assegurar comunicações seguras, gerir fornecedores e provar que os seus controlos funcionam.

A Clarysec ajuda as organizações a transformar a autenticação de correio eletrónico de definições técnicas frágeis num sistema de controlo preparado para auditoria. O próximo passo prático é uma revisão focada de evidência de autenticação de correio eletrónico:

1. Construir o registo de domínios e envio.
2. Mapear o estado de SPF, DKIM, DMARC, MTA-STS e TLS-RPT.
3. Identificar fornecedores, remetentes de TI sombra e exceções.
4. Criar um roteiro de aplicação efetiva de DMARC.
5. Validar evidência de gestão de alterações, registo de eventos e resposta a incidentes.
6. Ligar a evidência a ISO/IEC 27001:2022, NIS2, DORA, RGPD da UE e NIST CSF 2.0.
7. Preparar um pacote de evidência pronto para auditoria usando Zenith Blueprint, Zenith Controls e as políticas Clarysec relevantes.

Se a sua organização está a preparar-se para certificação ISO/IEC 27001:2022, preparação para NIS2, garantia DORA, revisões de responsabilização RGPD da UE ou questionários de segurança solicitados por clientes, comece pelos controlos que os atacantes exploram de forma mais visível: os seus domínios, os seus remetentes e a sua cadeia de confiança de correio eletrónico.

Descarregue o Zenith Blueprint, use Zenith Controls para mapeamento de conformidade cruzada e execute uma revisão de evidência de autenticação de correio eletrónico de 30 dias antes que o próximo incidente de falsificação ou pedido de auditoria force a conversa.