Evidencias de DMARC para ISO 27001, NIS2, DORA y GDPR
Todo empieza cuando un director financiero reenvía un correo electrónico al CISO a las 07:42.
«¿Hemos enviado esto?»
El mensaje parece perfecto. El mismo logotipo, el mismo pie, el mismo tono que el equipo de facturación. Afirma que los datos bancarios han cambiado. El nombre visible del remitente es correcto. El dominio no es un error tipográfico ni una imitación. El atacante está suplantando el dominio real.
A las 08:15, el equipo de seguridad confirma una realidad incómoda: SPF existe, pero es demasiado amplio; DKIM solo está habilitado para la plataforma principal de correo electrónico; varias herramientas de marketing envían correo sin firmar; DMARC sigue en modo de supervisión; y nadie encuentra la última revisión de la política MTA-STS del dominio. La organización tiene «seguridad del correo electrónico» en una presentación, pero las evidencias están dispersas entre capturas de pantalla de DNS, portales de proveedores, tickets antiguos de Jira y una hoja de cálculo propiedad de alguien que dejó la empresa el año pasado.
A las 10:30, el área jurídica pregunta si pueden estar implicados datos personales de clientes. Cumplimiento pregunta si esto es relevante para la notificación conforme a NIS2. Un cliente del sector financiero pregunta si la empresa puede demostrar controles de riesgo relacionado con las TIC alineados con DORA. Auditoría interna pregunta cómo se mapea esto con ISO/IEC 27001:2022. El consejo de administración formula una pregunta más sencilla: «¿Por qué alguien ha podido hacerse pasar por nosotros?»
Esa pregunta explica por qué la autenticación del correo electrónico en 2026 ya no es un asunto técnico especializado de DNS. DMARC, SPF, DKIM, MTA-STS y TLS-RPT son controles que generan evidencias. Reducen el riesgo de phishing y suplantación de dominios, pero también crean los artefactos que esperan los auditores: decisiones de política, propiedad, configuraciones técnicas de referencia, gobernanza de proveedores, registros de eventos, registros de supervisión, excepciones, aprobaciones de cambios y desencadenantes de respuesta a incidentes.
La cuestión de cumplimiento no es: «¿Tenemos DMARC?». Es: «¿Podemos demostrar que la autenticación del correo electrónico está gobernada, supervisada, revisada y vinculada al riesgo?»
La brecha de evidencias que los auditores siguen encontrando
Un segundo escenario es igual de habitual. La auditoría externa está en curso en una fintech de rápido crecimiento. El auditor pasa de continuidad del negocio a gestión de incidentes y pregunta al CISO por el compromiso del correo electrónico empresarial.
El CISO explica que la empresa dispone de filtros antiphishing y formación trimestral de concienciación en seguridad.
El auditor asiente y pide algo más específico: «Muéstrame la gobernanza de DMARC, SPF y DKIM. Necesito ver la propiedad, los registros de cambios, la evaluación de riesgos, las evidencias de supervisión y cómo se relaciona esto con la higiene cibernética de NIS2 y el marco de riesgo relacionado con las TIC de DORA».
La sala queda en silencio.
El equipo técnico implantó DMARC hace meses, pero el SGSI no contiene ninguna referencia de política, ningún paquete centralizado de evidencias, ningún vínculo con el registro de riesgos y ninguna hoja de ruta de aplicación aprobada. El control puede existir técnicamente, pero es invisible para la gobernanza.
Esa es la brecha de evidencias.
Un programa maduro de autenticación del correo electrónico responde a seis preguntas de auditoría:
- ¿Qué dominios y subdominios están dentro del alcance?
- ¿Quién es propietario de cada dominio, zona DNS, flujo de correo y servicio de envío?
- ¿Qué sistemas están autorizados a enviar en nombre de la organización?
- ¿Qué mecanismos de autenticación se aplican, supervisan y revisan?
- ¿Cómo se aprueban, aceptan y retiran las excepciones?
- ¿Qué evidencias demuestran que el control ha funcionado a lo largo del tiempo?
ISO/IEC 27001:2022 convierte esto en una cuestión del sistema de gestión. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda el contexto, los requisitos de las partes interesadas, los límites del alcance, las interfaces y las dependencias. La autenticación del correo electrónico afecta a todos ellos. Tu registrador de dominios puede ser un proveedor. DNS puede estar alojado en infraestructura en la nube. Tu CRM, plataforma de nóminas, herramienta de facturación, proveedor de automatización de marketing y sistema de atención al cliente pueden enviar correos electrónicos usando tu marca.
Las cláusulas 5.1 a 5.3 convierten esto en una cuestión de liderazgo. La alta dirección debe asignar responsabilidades e integrar la seguridad de la información en los procesos de la organización. Una decisión DMARC de p=none a p=quarantine o p=reject puede afectar a comunicaciones con clientes, notificaciones financieras, incorporación de empleados de Recursos Humanos, campañas comerciales y proveedores externalizados.
Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, selección de controles y una Declaración de Aplicabilidad. La suplantación de dominios debe tratarse como un escenario de riesgo, con SPF, DKIM, DMARC, MTA-STS y TLS-RPT seleccionados como parte del tratamiento cuando proceda. La cláusula 8.1 exige después planificación y control operacional, incluido el control de procesos, productos y servicios proporcionados externamente que sean relevantes para el SGSI.
Qué demuestra cada control de autenticación del correo electrónico
SPF, DKIM, DMARC, MTA-STS y TLS-RPT funcionan conjuntamente, pero demuestran cosas distintas.
| Control | Qué hace | Evidencias de cumplimiento que genera | Debilidad habitual en auditoría |
|---|---|---|---|
| SPF | Autoriza qué servidores de correo pueden enviar para un dominio | Registro DNS, inventario de remitentes aprobados, lista de envíos de proveedores, historial de cambios | El registro es demasiado amplio, supera los límites de consultas o incluye proveedores abandonados |
| DKIM | Firma criptográficamente el correo electrónico para que los receptores puedan verificar la integridad y la asociación con el dominio | Inventario de selectores, registros de rotación de claves, configuración DKIM de proveedores, resultados de pruebas | Solo firma la plataforma principal de correo, mientras que las herramientas SaaS envían correo sin firmar |
| DMARC | Indica a los receptores qué hacer cuando SPF o DKIM fallan la alineación y envía informes | Registro de política, informes agregados, hoja de ruta de aplicación, registro de excepciones, paneles de supervisión | Permanece en p=none indefinidamente sin aceptación del riesgo ni fecha objetivo |
| MTA-STS | Indica a los servidores de correo remitentes que usen TLS al entregar correo a tu dominio | Archivo de política, registro TXT de DNS, evidencias de alojamiento HTTPS, validación TLS, registros de revisión | Se crea una vez, pero no se vuelve a probar tras cambios en la pasarela de correo o en certificados |
| TLS-RPT | Recibe informes sobre problemas de entrega TLS | Registro DNS, buzón o punto de recepción de informes, registros de triaje, tickets de incidentes | Los informes se recopilan, pero no se revisan ni se vinculan a incidentes |
SPF y DKIM son señales de identidad e integridad. DMARC es la capa de política que convierte esas señales en una acción por parte del receptor. MTA-STS y TLS-RPT respaldan el transporte seguro del correo electrónico al ayudar a prevenir riesgos de degradación y configuración incorrecta.
Para los auditores, el valor más profundo es la evidencia repetible. Los informes agregados DMARC muestran quién está enviando como tu dominio. Los informes TLS muestran si está fallando la entrega cifrada. Los tickets de cambio muestran si existe gobernanza. Los registros de proveedores muestran si se conocen las dependencias de la cadena de suministro.
Incluye primero los dominios en el registro de activos
La autenticación del correo electrónico no puede gobernarse si los dominios no se tratan como activos.
La Política de Gestión de Activos para pymes Política de Gestión de Activos - pyme incluye expresamente los dominios y las identidades relacionadas con el correo electrónico en su alcance:
«Credenciales y servicios digitales: nombres de dominio, certificados digitales, claves de API, cuentas de correo electrónico, accesos a servicios en la nube»
De la sección «Alcance», cláusula 2.2.4 de la política.
Para organizaciones de mayor tamaño, la Política de Gestión de Activos Política de Gestión de Activos aplica la misma lógica:
«Activos lógicos: nombres de dominio, licencias, cuentas de usuario, configuraciones de referencia»
De la sección «Alcance», cláusula 2.2.5 de la política.
Si los dominios son activos, pueden tener propietarios, clasificaciones de criticidad, ciclos de revisión, dependencias de proveedores, controles de cambios y ubicaciones de evidencias. Si son solo entradas DNS, normalmente permanecen sin gestionar hasta que algo falla.
Un registro de dominios y envíos de correo preparado para auditoría debe incluir:
| Campo | Ejemplo |
|---|---|
| Dominio o subdominio | example.com, billing.example.com |
| Proveedor DNS y registrador | Proveedor DNS en la nube, registrador corporativo |
| Proveedor MX | Microsoft 365, Google Workspace, pasarela segura de correo electrónico |
| Servicio de envío | SendGrid, Salesforce, Zendesk, proveedor de nóminas |
| Propietario de negocio | Operaciones financieras |
| Propietario técnico | Ingeniería de mensajería |
| Método de autenticación | SPF y DKIM alineados |
| Selector DKIM | selector1, vendor2026 |
| Resultado DMARC | Correcto, parcial, fallido |
| Estado MTA-STS | Aplicado, en pruebas, no aplicable |
| Destino TLS-RPT | tls-rpt@example.com |
| Estado del riesgo | Aprobado, excepción, remediación |
| Ubicación de evidencias | Ticket de cambio, exportación DNS, captura de proveedor |
| Fecha de revisión | Trimestral |
Este registro respalda el control A.5.9 Inventario de información y otros activos asociados del Anexo A de ISO/IEC 27001:2022, A.8.9 gestión de configuraciones, A.5.19 seguridad de la información en las relaciones con proveedores y A.5.23 seguridad de la información para el uso de servicios en la nube. También respalda los resultados de inventario de NIST CSF 2.0 para activos, servicios, proveedores y criticidad.
Usa la gestión de cambios para decisiones de DNS y flujo de correo
La autenticación del correo electrónico falla cuando la gestión de cambios es débil. Un equipo comercial añade una plataforma de prospección. Recursos Humanos adopta una herramienta de seguimiento de candidatos. Finanzas cambia el software de facturación. Marketing migra a un nuevo proveedor de servicios de correo electrónico. Cada decisión de negocio crea un nuevo remitente.
La Política de gestión de cambios empresarial Política de gestión de cambios establece de forma explícita el requisito de evidencias:
«Todas las solicitudes de cambio, revisiones, aprobaciones y evidencias de soporte deben registrarse en el Sistema de Gestión de Cambios centralizado.»
De la sección «Requisitos de implementación de la política», cláusula 6.1.1 de la política.
Un ticket sólido de cambio de autenticación del correo electrónico debe incluir:
- Justificación de negocio para el nuevo remitente.
- Dominio o subdominio afectado.
- Impacto del mecanismo
includede SPF o de la IP de envío. - Selector DKIM y propiedad de la clave.
- Resultado de la prueba de alineación DMARC.
- Impacto en MTA-STS o MX, si existe.
- Clasificación de datos de los mensajes enviados.
- Referencia de revisión de seguridad del proveedor.
- Plan de reversión.
- Aprobación por el propietario del dominio y seguridad.
- Evidencias de pruebas posteriores a la implementación.
- Fecha de revisión o caducidad para configuraciones temporales.
Esta es la diferencia entre «un administrador de DNS cambió un registro» y «el SGSI controló un cambio relevante para el riesgo».
Plan práctico de 30 días para evidencias de DMARC, SPF, DKIM y MTA-STS
Un CISO no necesita un proyecto de transformación de seis meses para mejorar la madurez de las evidencias. Un sprint focalizado de 30 días puede producir una configuración de referencia defendible.
Semana 1: descubrir dominios, remitentes y propiedad
Exporta todos los dominios del registrador y del proveedor DNS. Extrae datos de flujo de correo de la pasarela de correo electrónico, CRM, mesa de servicio, plataforma de marketing, sistema de facturación y servicios de notificación en la nube. Construye el registro de dominios y envíos.
Incluye también dominios aparcados y registros defensivos. Los dominios aparcados suelen ignorarse, pero pueden ser abusados si DMARC está ausente o es débil.
Semana 2: corregir la alineación de SPF y DKIM
Revisa SPF para detectar mecanismos excesivamente permisivos, mecanismos include obsoletos, proveedores duplicados y riesgos por límite de consultas. Para DKIM, identifica todos los remitentes que no firman el correo o que firman con un dominio que no se alineará con DMARC.
No apruebes un remitente SaaS solo porque el correo funcione. Apruébalo porque:
- El proveedor figura en el registro de envíos.
- La configuración de SPF y DKIM está documentada.
- Los selectores DKIM están inventariados.
- La propiedad de las claves y las expectativas de revisión están claras.
- La documentación de seguridad del proveedor respalda un manejo seguro del correo.
- El propietario de negocio acepta cualquier excepción temporal.
Aquí es donde NIS2 y DORA se vuelven prácticos. El Article 21 de NIS2 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidas análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y mantenimiento seguros, evaluación de la eficacia, higiene cibernética, criptografía, control de acceso y comunicaciones seguras. El Article 28 de DORA exige a las entidades financieras gestionar el riesgo de terceros de TIC como parte del marco de gestión del riesgo relacionado con las TIC, incluida la diligencia debida, expectativas contractuales, supervisión y planificación de salida.
Si un proveedor de marketing envía correo no autenticado usando tu dominio, no es solo un problema de marketing. Es riesgo de proveedor, riesgo de suplantación de marca y, potencialmente, daño para clientes.
Semana 3: avanzar DMARC hacia la aplicación
El modo de supervisión es útil, pero un p=none permanente sin una hoja de ruta aprobada constituye una evidencia débil.
Un plan defendible de aplicación de DMARC debe incluir:
- Revisión de referencia de informes agregados.
- Identificación de fuentes legítimas e ilegítimas.
- Remediación de fuentes legítimas que fallan.
- Validación de negocio de flujos de correo críticos.
- Incremento gradual de la política a
pct=25,pct=50,pct=100. - Transición de
p=noneap=quarantine. - Transición a
p=rejectcuando el riesgo y la preparación del negocio lo permitan. - Tratamiento separado de subdominios con
sp=. - Registro de excepciones con fechas de caducidad.
- Aprobación de la dirección para el riesgo residual.
Esto respalda la cláusula 6.1.3 de ISO/IEC 27001:2022 sobre tratamiento de riesgos y la cláusula 8.1 sobre planificación y control operacional. También ofrece a auditoría interna una trazabilidad clara: decisión, implementación, supervisión, excepción, aprobación y revisión.
Semana 4: validar MTA-STS, TLS-RPT y la supervisión
MTA-STS suele pasarse por alto porque no detiene la suplantación saliente de marca del mismo modo que DMARC. Pero es muy relevante para las comunicaciones seguras y la protección de la información en tránsito. Indica a los servidores de envío compatibles que el correo hacia tu dominio debe entregarse mediante TLS y valida la identidad MX.
La Política de Controles Criptográficos empresarial Política de Controles Criptográficos establece una configuración de referencia clara para la seguridad del transporte:
«Seguridad del transporte: TLS 1.2 o superior (preferiblemente TLS 1.3)»
De la sección «Requisitos de implementación de la política», cláusula 6.1.1.5 de la política.
Para pymes, la Política de Controles Criptográficos para pymes Política de Controles Criptográficos - pyme incluye expresamente la transmisión por correo electrónico:
«Datos transmitidos por correo electrónico, VPN corporativas y portales web»
De la sección «Requisitos de implementación de la política», cláusula 6.1.1.4 de la política.
Las pruebas deben incluir validación TLS de MX, disponibilidad del archivo de política MTA-STS, estado de salud del certificado HTTPS, revisión de informes TLS-RPT y registros de triaje de fallos.
Mapear la autenticación del correo electrónico con el Anexo A de ISO/IEC 27001:2022
Zenith Controls: la guía de cumplimiento cruzado de Clarysec Zenith Controls ayuda a conectar evidencias técnicas con expectativas de auditoría entre distintos marcos. No es un conjunto de controles independiente. Es una guía de mapeo y auditoría para controles de ISO/IEC 27001:2022 y normas relacionadas.
Para el control A.5.14 Transferencia de información del Anexo A de ISO/IEC 27001:2022, Zenith Controls explica la relación con la criptografía:
«La transferencia segura de información se basa en controles criptográficos, según se detalla en 8.24.»
Esa es la relación entre el correo electrónico de la organización, DKIM, MTA-STS y TLS. El correo electrónico es un canal de transferencia de información. DKIM respalda la autenticidad e integridad de los mensajes. MTA-STS y TLS respaldan la protección del transporte.
Para el control A.8.24 Uso de criptografía del Anexo A, Zenith Controls vincula la criptografía con la transferencia de información, la privacidad, la protección de información de identificación personal (PII), la clasificación y la gestión de vulnerabilidades. Para los controles A.8.15 Registro de eventos y A.8.16 Actividades de supervisión del Anexo A, la guía conecta los registros y la supervisión con la gestión de eventos, la recopilación de evidencias, la revisión, el análisis y la auditabilidad.
La Política de registro y supervisión para pymes Política de registro y supervisión - pyme establece:
«El registro de eventos debe habilitarse y configurarse cuando esté disponible»
De la sección «Requisitos de gobernanza», cláusula 5.5.1.1 de la política.
La Política de registro y supervisión empresarial Política de registro y supervisión incluye:
«Comunicaciones externas y desencadenantes de reglas de cortafuegos»
De la sección «Requisitos de implementación de la política», cláusula 6.1.1.6 de la política.
Para la autenticación del correo electrónico, las comunicaciones externas deben incluir eventos de la pasarela de correo, procesamiento de informes agregados DMARC, tendencias de fallos DKIM, infraestructura de origen sospechosa, fallos TLS-RPT e intentos de suplantación que activen el triaje de incidentes.
El Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint lleva esto a la validación práctica de controles. En la fase Controles en acción, paso 20, indica a los equipos que validen la seguridad de los servicios de red:
«Enumera todos los servicios de red internos y externos (DNS, VPN, SMTP, DHCP, pasarelas de API, etc.).
✓ Para cada uno, confirma que usan protocolos seguros (p. ej., DNSSEC, TLS 1.2+, SSH en lugar de Telnet).
✓ Revisa cómo se controla el acceso a cada servicio (p. ej., listas de permitidos de IP, autenticación, certificados).
✓ Si los gestionan terceros (p. ej., DNS, SD-WAN, VPN alojada), revisa las cláusulas de seguridad del SLA o del contrato con el proveedor. Actualiza tu Registro de Servicios e indica dónde recaen las responsabilidades de seguridad, internas o externas.»
Aplicado al correo electrónico, esto se convierte en un plan de trabajo para DNS, SMTP, TLS, pasarelas de correo alojadas, remitentes de proveedores y límites de responsabilidad.
Mapeo de cumplimiento cruzado: un paquete de evidencias, muchas obligaciones
El mismo paquete de evidencias puede respaldar ISO/IEC 27001:2022, NIS2, DORA, GDPR y NIST CSF 2.0 si está estructurado correctamente.
| Artefacto de evidencia | Relevancia para ISO/IEC 27001:2022 | Relevancia para NIS2 | Relevancia para DORA | Relevancia para GDPR | Relevancia para NIST CSF 2.0 |
|---|---|---|---|---|---|
| Registro de dominios y envíos de correo | Cláusulas 4.3 y 8.1, A.5.9, A.5.19, A.5.23 | Article 21 gestión de riesgos y seguridad de la cadena de suministro | Articles 6 y 28 riesgo relacionado con las TIC y gobernanza de terceros | Article 5 responsabilidad proactiva cuando se envían datos personales por correo electrónico | ID.AM inventario de activos y servicios |
| Hoja de ruta de aplicación de DMARC | Cláusula 6.1.3, Declaración de Aplicabilidad, A.8.9, A.5.14 | Article 21 higiene cibernética y evaluación de la eficacia | Articles 6, 9 y 10 riesgo relacionado con las TIC, protección y detección | Articles 5 y 32 integridad, confidencialidad y seguridad del tratamiento | GV.RM respuesta al riesgo, PR.PS seguridad de plataformas |
| Registros de revisión de SPF y DKIM | A.8.9 gestión de configuraciones, A.8.24 criptografía, A.5.20 acuerdos con proveedores | Article 21 seguridad de la cadena de suministro y mantenimiento seguro | Article 28 gestión del riesgo de terceros de TIC | Article 32 medidas técnicas y organizativas apropiadas | GV.SC requisitos de proveedores, ID.RA seguimiento de riesgos |
| Validación de MTA-STS y TLS-RPT | A.8.24 uso de criptografía, A.8.21 seguridad de servicios de red, A.8.16 supervisión | Article 21 comunicaciones seguras y políticas de criptografía | Articles 9 y 10 protección, prevención y detección | Article 32 seguridad del tratamiento | PR.DS seguridad de datos, DE.CM supervisión continua |
| Registro de excepciones | Cláusulas 6.1.3 y 8.1, aprobación del propietario del riesgo y riesgo residual | Article 21 medidas correctivas y proporcionadas | Articles 5, 6 y 28 gobernanza y remediación | Article 5 responsabilidad proactiva | GV.RM tolerancia al riesgo y respuesta |
| Registros de triaje de incidentes | A.5.24, A.5.25 y A.5.26 planificación, evaluación y respuesta a incidentes | Article 23 evaluación y notificación de incidentes significativos | Articles 17 y 19 proceso y notificación de incidentes | Articles 33 y 34 notificación y comunicación de brechas cuando proceda | RS.AN análisis, RS.CO comunicación |
NIS2 es especialmente relevante para entidades esenciales e importantes, así como para determinadas categorías de infraestructura digital y proveedores digitales. El Article 20 convierte la gobernanza de la ciberseguridad en una responsabilidad del órgano de administración, mientras que el Article 21 establece la configuración de referencia de gestión de riesgos. Las evidencias de autenticación del correo electrónico ayudan a demostrar que las comunicaciones seguras, las relaciones con proveedores, la gestión de incidentes, la evaluación de la eficacia y la higiene cibernética son operativas, no teóricas.
Para las entidades financieras, DORA es aplicable desde el 17 de enero de 2025. Los Articles 5 y 6 exigen responsabilidad proactiva del órgano de administración y un marco documentado de gestión del riesgo relacionado con las TIC. El Article 17 exige procesos para detectar, gestionar, registrar, clasificar, escalar y remediar incidentes relacionados con las TIC. El Article 28 convierte la gestión del riesgo de terceros de TIC en una responsabilidad formal. Los proveedores de correo electrónico, plataformas de marketing, sistemas de notificación de pagos y herramientas de comunicación con clientes pueden formar parte de esa cadena de dependencias de TIC.
Para GDPR, la cuestión clave es si el correo electrónico se utiliza para tratar datos personales. El Article 5 incluye integridad, confidencialidad y responsabilidad proactiva. El Article 32 exige medidas técnicas y organizativas apropiadas. Si facturas, mensajes de Recursos Humanos, avisos de cuenta, tickets de soporte o correos de incorporación contienen datos personales, la autenticación del correo electrónico y la seguridad del transporte pasan a formar parte de las evidencias de seguridad del tratamiento.
Respuesta a incidentes: cuando los informes se convierten en alerta temprana
Los informes agregados DMARC no son solo evidencias de cumplimiento. Son datos de alerta temprana. Un aumento de fallos de autenticación desde infraestructura desconocida puede indicar suplantación activa, TIC en la sombra, configuración incorrecta de un proveedor o un remitente comprometido.
Conforme al Article 23 de NIS2, las entidades esenciales e importantes deben notificar incidentes significativos sin dilación indebida, mediante una notificación por fases que incluya alerta temprana, notificación de incidente e informe final. No todo intento de suplantación es notificable, pero la organización debe poder evaluar la severidad, la interrupción operativa, la pérdida financiera, el impacto transfronterizo y el daño a los destinatarios.
Conforme al Article 17 de DORA, las entidades financieras deben definir e implementar un proceso de gestión de incidentes relacionados con las TIC, registrar incidentes y amenazas cibernéticas significativas, identificar causas raíz, usar indicadores de alerta temprana, clasificar por severidad y criticidad del servicio, asignar roles, definir comunicaciones y escalar incidentes graves. El Article 19 de DORA aborda después la notificación de incidentes graves relacionados con las TIC.
Para GDPR, la pregunta es si el evento provocó destrucción, pérdida, alteración, divulgación no autorizada o acceso no autorizado a datos personales, de forma accidental o ilícita. Un correo electrónico suplantado que engaña a clientes para que entreguen datos personales a un atacante puede activar una evaluación de brecha de datos personales, aunque los sistemas internos no se hayan visto comprometidos.
La Política de Auditoría y Supervisión del Cumplimiento empresarial Política de Auditoría y Supervisión del Cumplimiento explica por qué son importantes las evidencias disciplinadas:
«Generar evidencias defendibles y una pista de auditoría en apoyo de requerimientos regulatorios, procedimientos judiciales o solicitudes de aseguramiento de clientes.»
De la sección «Objetivos», cláusula 3.4 de la política.
La Política de Auditoría y Supervisión del Cumplimiento para pymes Política de Auditoría y Supervisión del Cumplimiento - pyme añade un requisito de calidad de la evidencia:
«Los metadatos (p. ej., quién los recopiló, cuándo y desde qué sistema) deben documentarse.»
De la sección «Requisitos de implementación de la política», cláusula 6.2.3 de la política.
Por tanto, un expediente de investigación DMARC debe documentar la fuente del informe, la hora de recopilación, el analista, los dominios afectados, las IP sospechosas de remitentes, los resultados de autenticación, la evaluación de impacto en las operaciones de la organización, las decisiones adoptadas y la aprobación de cierre.
Qué pedirán los auditores
Distintos auditores usan distinto lenguaje, pero las evidencias se solapan.
| Perspectiva del auditor | Foco probable | Evidencias que preparar |
|---|---|---|
| Auditor de ISO/IEC 27001:2022 | Si la autenticación del correo electrónico está dentro del alcance, evaluada frente al riesgo, tratada, operada y revisada | Evaluación de riesgos, justificación de la Declaración de Aplicabilidad, registro de activos, tickets de cambio, registros de supervisión, hallazgos de auditoría interna |
| Revisor de controles de ISO/IEC 27002:2022 | Si se han implementado los controles de transferencia de información, registro de eventos, criptografía, servicios de proveedores y servicios de red | Procedimiento de transferencia de información, inventario criptográfico, ajustes de la pasarela, informes DMARC, pruebas TLS, registros de proveedores |
| Evaluador de NIS2 | Si las medidas son adecuadas, proporcionadas, gobernadas por la dirección y vinculadas a la gestión de incidentes y a la seguridad de proveedores | Aprobación de la dirección, evidencias de higiene cibernética, registro de remitentes de proveedores, flujo de trabajo de triaje de incidentes, revisiones de eficacia |
| Auditor de DORA | Si la autenticación del correo electrónico respalda la gestión del riesgo relacionado con las TIC, el riesgo de terceros, la clasificación de incidentes y la resiliencia | Registro de riesgos de TIC, diligencia debida de proveedores, registros de incidentes, paneles de supervisión, seguimiento de remediación, informes a la dirección |
| Revisor de GDPR | Si los datos personales enviados por correo electrónico están protegidos por medidas técnicas y organizativas apropiadas | Registros de flujo de datos, justificación de seguridad del Article 32, controles de cifrado y transporte, procedimiento de evaluación de brechas, evidencias de responsabilidad proactiva |
| Auditor de estilo NIST o ISACA | Si la gobernanza, el riesgo, el diseño del control, su operación, supervisión y mejora son demostrables | Perfil actual y objetivo, resultados de pruebas de controles, POA&M, registro de excepciones, métricas, acciones correctivas |
Espera preguntas prácticas:
- Muéstrame los informes DMARC del último trimestre.
- Muéstrame cómo se revisaron.
- Muéstrame la excepción para este remitente fallido.
- Muéstrame quién aprobó este cambio de SPF.
- Muéstrame si los selectores DKIM están inventariados y revisados.
- Muéstrame cómo se prueba MTA-STS después de cambios en la pasarela de correo.
- Muéstrame cómo los eventos de suplantación entran en el triaje de incidentes.
- Muéstrame cómo se eliminan los remitentes de proveedores al terminar el contrato.
Lista de verificación concisa de auditoría interna para 2026
Usa esta lista como punto de partida para auditoría interna, pruebas de controles o una revisión de evidencias de autenticación del correo electrónico.
- Todos los dominios y subdominios figuran en el registro de activos.
- Los dominios aparcados y defensivos tienen cobertura DMARC.
- Cada remitente autorizado tiene un propietario de negocio y un propietario técnico.
- Los registros SPF se revisan para detectar mecanismos
includeobsoletos y alcance excesivo. - DKIM está habilitado para remitentes legítimos cuando se admite.
- Los selectores DKIM están inventariados y revisados.
- DMARC está desplegado para dominios raíz y subdominios relevantes.
- DMARC tiene una hoja de ruta de aplicación, no una supervisión indefinida.
- Los informes agregados DMARC se revisan con una periodicidad definida.
- MTA-STS está configurado para dominios de correo entrante cuando procede.
- Los informes TLS-RPT se recopilan y se someten a triaje.
- Los cambios de autenticación del correo electrónico siguen la gestión de cambios.
- La incorporación de proveedores incluye requisitos de envío de correo electrónico.
- La baja de proveedores elimina mecanismos
includede SPF, selectores DKIM y permisos de envío. - Las excepciones tienen propietarios del riesgo, fechas de caducidad y controles compensatorios.
- Los picos de suplantación y los fallos de autenticación alimentan la respuesta a incidentes.
- Las evidencias incluyen metadatos, fuente, fecha, recopilador y sistema.
- La dirección recibe métricas periódicas y actualizaciones de riesgo.
El Zenith Blueprint, fase de gestión de riesgos, paso 14, recomienda crear tablas de mapeo regulatorio para las obligaciones aplicables:
«Para cada regulación, si procede, puedes crear una tabla de mapeo sencilla (podría ser un anexo de un informe) que enumere los requisitos clave de seguridad de la regulación y los controles/políticas correspondientes en tu SGSI. Esto no es obligatorio en ISO 27001, pero es un ejercicio interno útil para garantizar que nada se haya pasado por alto. También demuestra a auditores/evaluadores que no gestionas la seguridad en el vacío, sino con conocimiento del contexto legal.»
Para la autenticación del correo electrónico, esa tabla se convierte en el puente entre la realidad técnica de DNS y el aseguramiento a nivel del consejo de administración.
Convierte la autenticación del correo electrónico en evidencias preparadas para auditoría
Puede que tus clientes nunca pregunten si tu registro SPF tiene una sintaxis perfecta. Preguntarán si puedes proteger tu marca, reducir el riesgo de phishing, asegurar las comunicaciones, gestionar proveedores y demostrar que tus controles funcionan.
Clarysec ayuda a las organizaciones a convertir la autenticación del correo electrónico desde configuraciones técnicas frágiles en un sistema de control preparado para auditoría. El siguiente paso práctico es una revisión focalizada de evidencias de autenticación del correo electrónico:
- Construir el registro de dominios y envíos.
- Mapear el estado de SPF, DKIM, DMARC, MTA-STS y TLS-RPT.
- Identificar proveedores, remitentes no autorizados y excepciones.
- Crear una hoja de ruta de aplicación de DMARC.
- Validar las evidencias de gestión de cambios, registro de eventos y respuesta a incidentes.
- Vincular las evidencias con ISO/IEC 27001:2022, NIS2, DORA, GDPR y NIST CSF 2.0.
- Preparar un paquete de evidencias listo para auditoría usando Zenith Blueprint, Zenith Controls y las políticas de Clarysec relevantes.
Si tu organización se está preparando para la certificación ISO/IEC 27001:2022, la preparación para NIS2, el aseguramiento DORA, revisiones de responsabilidad proactiva GDPR o cuestionarios de seguridad de clientes, empieza por los controles de los que los atacantes abusan de forma más visible: tus dominios, tus remitentes y tu cadena de confianza del correo electrónico.
Descarga Zenith Blueprint, usa Zenith Controls para el mapeo de cumplimiento cruzado y ejecuta una revisión de evidencias de autenticación del correo electrónico de 30 días antes de que el próximo incidente de suplantación o solicitud de auditoría fuerce la conversación.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
