Una auditoría de ciberseguridad es, en cristiano, una revisión profesional y documentada del estado de seguridad de una empresa. La hace un equipo externo, sigue una metodología reconocida, y termina con un informe que dice qué falla, cómo de grave es y qué hay que tocar para corregirlo. No es un escáner automático, no es un cuestionario de compliance, y no es lo mismo que un pentesting: es el paraguas que cubre varios tipos de evaluación según la pregunta que necesite responder la organización.
Esta guía explica los tres grandes tipos de auditoría que existen, cuándo conviene cada uno, qué fases tiene un proyecto serio, qué entregables debes exigir, cómo encaja con NIS2, DORA, ENS e ISO 27001, qué cuesta y dura de media en el mercado español, y qué señales separan a un proveedor sólido de uno que va a vender un informe vacío.
Qué es exactamente una auditoría de ciberseguridad
Una auditoría de ciberseguridad es un proyecto acotado en tiempo y alcance que evalúa el nivel real de seguridad de una organización, un sistema concreto o un proceso. La ejecuta un proveedor externo (o un equipo interno independiente con autoridad explícita), usa metodologías estándar y produce evidencia auditable.
Hay tres tipos según lo que evalúa:
- Auditoría técnica. Evalúa la seguridad real de activos tecnológicos: aplicaciones web y móviles, infraestructura interna y externa, entornos cloud, dispositivos IoT/OT, redes inalámbricas. El método más común aquí es el pentesting.
- Auditoría organizativa. Evalúa políticas, procedimientos, formación, gobernanza, gestión de incidentes y la madurez del programa de seguridad. Mira a las personas y a los procesos, no solo a los sistemas.
- Auditoría de cumplimiento. Verifica que una organización cumple los controles exigidos por una norma concreta: NIS2, DORA, ENS, ISO 27001, PCI DSS, SOC 2. Suele combinarse con las dos anteriores para tener evidencia técnica y documental a la vez.
La pregunta que responde una auditoría de ciberseguridad bien planteada es directa: ¿qué riesgos reales tiene mi organización ahora mismo y qué tengo que hacer para reducirlos?. La trampa habitual es contestarla con un PDF lleno de gráficos pero sin acciones concretas, sin priorización por impacto y sin plazos. Esa auditoría no sirve.
En una auditoría profesional cabe esperar:
- Alcance escrito: qué activos entran, qué activos quedan fuera, qué técnicas se autorizan, qué ventanas horarias se respetan.
- Autorización formal por parte del titular de los activos (las rules of engagement).
- Equipo identificado, con certificaciones (OSCP, OSEP, OSWE, CEH, CISA, CISM, CISSP según el tipo) y experiencia documentable.
- Combinación de técnica manual y herramientas profesionales (Burp Suite, Nessus, Nmap, BloodHound, scripts propios, cuestionarios estructurados ISO/NIS2).
- Entregable doble: informe ejecutivo para dirección y informe técnico detallado para los equipos que tienen que arreglar.
- Plan de remediación priorizado con esfuerzo estimado y responsables.
- Sesión de presentación y retest cuando se han aplicado las correcciones más críticas.
Tipos de auditoría de ciberseguridad
| Tipo | Qué evalúa | Cuándo usarla | Estándares de referencia |
|---|---|---|---|
| Auditoría técnica (pentesting) | Vulnerabilidades reales en aplicaciones, redes, cloud, móviles, IoT | Antes de un lanzamiento, periódicamente o tras un cambio mayor de arquitectura | OWASP Top 10, OWASP MASVS, PTES, OSSTMM |
| Auditoría organizativa | Políticas, procesos, gobernanza, formación, plan de respuesta a incidentes | Para medir madurez del programa o priorizar inversión en seguridad | ISO 27001 Anexo A, NIST CSF, ENS Anexo II |
| Auditoría de cumplimiento normativo | Adherencia a una norma concreta (NIS2, DORA, ENS, ISO 27001, PCI DSS) | Para certificarse, demostrar cumplimiento ante un cliente B2B o evitar sanciones | El propio cuerpo normativo más Magerit, ISO 27002 |
| Análisis de riesgos | Probabilidad e impacto de amenazas sobre activos clave | Como paso previo a definir el plan de seguridad | Magerit, ISO 27005, FAIR |
| Forense post-incidente | Reconstrucción de qué pasó, cómo entró el atacante, qué se llevó | Inmediatamente tras un incidente de seguridad detectado | NIST SP 800-86, RFC 3227 |
La mayoría de proyectos serios combinan auditoría técnica + auditoría organizativa porque medir solo lo técnico deja gaps de proceso, y medir solo lo organizativo no detecta fallos reales explotables. Las auditorías de cumplimiento (NIS2, DORA, ENS) suelen exigir evidencia de ambas.
Auditoría vs pentesting vs Red Team vs análisis de vulnerabilidades
Estos cuatro términos se mezclan en pliegos y propuestas con frecuencia, y no son lo mismo. Cada uno responde una pregunta distinta:
| Servicio | Pregunta que responde | Profundidad | Duración típica |
|---|---|---|---|
| Análisis de vulnerabilidades | ¿Qué vulnerabilidades conocidas detecta una herramienta automática? | Baja, lista de hallazgos sin priorización profunda | 1 a 3 días |
| Pentesting | ¿Qué fallos hay en este activo y cómo de graves son si los explotan? | Media a alta, manual con cadenas de ataque | 1 a 4 semanas |
| Auditoría de ciberseguridad | ¿Cuál es el estado de seguridad global de mi organización? | Variable, abarca técnica + procesos + cumplimiento | 4 semanas a 3 meses |
| Red Team | ¿Podríamos comprometer el negocio sin que el SOC se enterara? | Muy alta, simulación realista con sigilo y persistencia | 6 semanas a 6 meses |
Una analogía simple: el análisis de vulnerabilidades es la analítica de sangre estándar, el pentesting es la prueba de esfuerzo cardiológica con un especialista, la auditoría de ciberseguridad es la revisión completa con varias especialidades coordinadas, y el Red Team es un ejercicio simulado en condiciones extremas con cardiólogo, neumólogo y traumatólogo mirando a la vez.
Para profundizar: hemos publicado guías específicas sobre qué es un pentesting, qué es un Red Team y las diferencias entre auditoría de caja blanca, negra y gris. Si tu necesidad es una prueba técnica acotada antes que una auditoría completa, los servicios de pentesting profesional y auditoría de infraestructura son los puntos de entrada más directos.
Las fases de una auditoría de ciberseguridad
Aunque cada proveedor tiene su propia metodología, una auditoría seria sigue siempre las mismas fases. Si tu propuesta no las describe explícitamente, falta rigor.
1. Definición de alcance y kick-off
Antes de tocar nada, se fija por escrito qué entra y qué no entra. Qué aplicaciones, qué rangos IP, qué cuentas, qué entornos, qué países, qué técnicas se autorizan (phishing sí o no, denegación de servicio sí o no, ingeniería social sí o no), qué ventanas horarias y qué interlocutores reciben los avisos. La frase "todo el perímetro" no es un alcance, es una receta para malentendidos.
2. Recopilación de información
El equipo auditor recopila datos sobre los activos en alcance: arquitectura, tecnologías, accesos de prueba, documentación existente, informes previos. En una auditoría organizativa se entrevistan responsables de seguridad, IT, RRHH y dirección. En una técnica se enumera la superficie de ataque con herramientas y OSINT.
3. Análisis y pruebas
Es el grueso del proyecto. En auditoría técnica se ejecutan pruebas manuales y automáticas para identificar vulnerabilidades reales. En auditoría organizativa se revisa documentación, políticas, registros de incidentes, planes de continuidad y formación. En auditoría de cumplimiento se mapea cada control de la norma contra evidencia documental y técnica.
4. Validación y explotación controlada (solo técnica)
Para los hallazgos técnicos relevantes se intenta una explotación controlada para confirmar que la vulnerabilidad es real, medir su impacto y descartar falsos positivos. Aquí es donde un proveedor serio se diferencia del que solo entrega resultados de un escáner: la prueba de concepto reproducible.
5. Documentación
Cada hallazgo se documenta con severidad CVSS o equivalente, evidencia (capturas, peticiones HTTP, registros), impacto técnico y de negocio, y recomendación de remediación. Los hallazgos se agregan en dos informes: ejecutivo (legible para dirección, 5 a 10 páginas) y técnico (detallado por hallazgo, 40 a 200 páginas según alcance).
6. Presentación de resultados y plan de acción
Sesión de cierre con el equipo cliente. Repaso de los hallazgos críticos, priorización conjunta, definición de quién corrige qué y en qué plazo. Esta sesión es la que convierte un informe en algo accionable.
7. Retest
Pasadas unas semanas (típicamente 4 a 8) el auditor vuelve a verificar las correcciones de los hallazgos críticos y altos. Sin retest, una auditoría se queda a medias: tienes los hallazgos, pero nadie confirma que están realmente corregidos.
Cuándo necesitas una auditoría de ciberseguridad
Los disparadores típicos en una empresa española en 2026 son cinco:
- Obligación legal o contractual. NIS2 exige a entidades esenciales e importantes realizar pruebas periódicas. DORA exige a entidades financieras pruebas avanzadas de resiliencia. ENS exige a la administración pública (y sus proveedores) auditorías cada dos años. Un cliente B2B puede exigir una auditoría como condición para firmar contrato.
- Lanzamiento o cambio mayor. Una nueva aplicación, una migración a cloud, una integración con un tercero crítico, una adquisición. Cada uno introduce superficie nueva que no estaba en la auditoría anterior.
- Incidente de seguridad reciente. Tras un incidente, una auditoría sirve para confirmar que el atacante ya no está dentro y que las vías por las que entró están cerradas.
- Due diligence. Una compraventa, una inversión o una integración requieren conocer el estado de seguridad de la otra parte. Una auditoría es la evidencia objetiva.
- Renovación cíclica. El estándar de mercado para empresas con activos críticos es una auditoría completa anual y pentests específicos cuando hay cambios mayores.
Si tu empresa cae en algún supuesto de NIS2 o DORA y aún no has hecho una auditoría con evidencia documental en los últimos 12 meses, lo razonable es planificarla antes de la próxima revisión normativa. Las multas de NIS2 alcanzan los 10 millones o el 2% de la facturación global anual para entidades esenciales.
Marco normativo: NIS2, DORA, ENS e ISO 27001
Casi todas las auditorías de ciberseguridad en España están motivadas, en mayor o menor medida, por una norma. La relación rápida:
| Norma | A quién aplica | Qué exige en auditoría |
|---|---|---|
| NIS2 | Entidades esenciales e importantes (energía, salud, transporte, banca, agua, administraciones, infraestructura digital y otros 11 sectores) | Pruebas técnicas periódicas, evaluación de riesgos, gestión de incidentes, supply chain |
| DORA | Entidades financieras y sus proveedores TIC críticos | Pruebas TLPT (Threat-Led Penetration Testing) bajo TIBER-EU, gestión de riesgos TIC, resiliencia operativa |
| ENS | Administraciones públicas españolas y sus proveedores | Categorización, declaración de aplicabilidad, auditoría bianual obligatoria |
| ISO 27001 | Voluntaria, certificable, demandada por clientes B2B | Auditoría interna anual + auditoría externa de certificación |
| PCI DSS | Cualquier organización que almacene, procese o transmita datos de tarjeta | ASV scan trimestral + pentest anual |
Para entender mejor cada norma: NIS2 paso a paso para empresas españolas, DORA: cumplimiento para empresas financieras, ENS para pymes, ISO 27001 explicada.
Coste y duración de mercado
Los rangos que se ven en el mercado español 2026 para auditorías de ciberseguridad varían mucho según alcance y profundidad. A modo orientativo (cifras industry-wide, no propuesta):
| Tipo de auditoría | Rango de coste de mercado | Duración típica |
|---|---|---|
| Auditoría técnica web/app móvil (alcance medio) | 4.000 a 15.000 € | 1 a 3 semanas |
| Auditoría de infraestructura interna y externa | 8.000 a 30.000 € | 2 a 5 semanas |
| Auditoría cloud (AWS, Azure, GCP) | 6.000 a 25.000 € | 2 a 4 semanas |
| Auditoría organizativa ISO 27001 / NIS2 | 10.000 a 40.000 € | 4 a 10 semanas |
| Auditoría de cumplimiento ENS | 8.000 a 25.000 € | 4 a 8 semanas |
| Red Team full-scope | 30.000 a 150.000 € | 6 semanas a 6 meses |
| TLPT bajo TIBER-EU (DORA) | 80.000 a 300.000 € | 3 a 6 meses |
Si te ofrecen una auditoría completa "todo incluido" por debajo de 2.500 €, no es una auditoría: es un escáner automático con un PDF encima.
Cómo elegir un proveedor de auditoría de ciberseguridad
Cinco criterios separan a un proveedor sólido de uno que vende humo:
- Equipo técnico real. Pide CVs de las personas que harán el trabajo (no del comercial). Busca certificaciones técnicas vigentes: OSCP, OSEP, OSWE, OSCE3, GPEN, eCPPT. Para auditorías de cumplimiento, CISA, CISM, ISO 27001 LA.
- Metodología documentada. Si la propuesta no menciona explícitamente OWASP Top 10, OWASP MASVS, PTES, OSSTMM, NIST o el cuerpo normativo correspondiente, es señal mala. La metodología no es marketing, es el marco que garantiza que no se queda nada sin probar.
- Muestra de informe sanitizada. Pide ver un informe real (con clientes ocultos). Si solo te enseñan una plantilla con datos ficticios, no han hecho muchos.
- Independencia. El auditor no debe ser quien implantó la solución que audita. Es la regla básica de auditoría que se sigue olvidando en seguridad.
- Plan de remediación y retest incluidos. Un proveedor que entrega el informe y desaparece no está vendiendo una auditoría, está vendiendo un PDF. La diferencia se nota cuando llega el momento de corregir.
Hemos profundizado en este tema en Cómo elegir empresa de pentesting y Empresas de ciberseguridad en España: cómo elegir.
Qué entregables exigir
Un proyecto de auditoría serio entrega, como mínimo:
- Informe ejecutivo (5 a 10 páginas): contexto, alcance, resumen de hallazgos por severidad, riesgos clave, recomendaciones priorizadas. Legible por dirección sin conocimiento técnico.
- Informe técnico (40 a 200 páginas): un capítulo por hallazgo con título, descripción, impacto, severidad CVSS, evidencia, recomendación de remediación, referencias OWASP/CWE.
- Anexos: inventario de activos auditados, herramientas utilizadas, cronograma del proyecto, registros de actividad.
- Plan de remediación: tabla con cada hallazgo, esfuerzo estimado, responsable propuesto y plazo recomendado.
- Sesión de presentación de resultados con dirección y equipo técnico.
- Retest documentado de los hallazgos críticos y altos tras la remediación.
Si la propuesta no incluye plan de remediación y retest, falta la mitad del proyecto.
Auditoría de ciberseguridad: errores frecuentes
Cinco errores que volvemos a ver año tras año en proyectos que llegan a nuestras manos tras una auditoría previa que no funcionó:
- Alcance demasiado amplio sin profundidad. "Audita todo nuestro perímetro" sin priorizar produce un informe largo y superficial. Mejor un alcance acotado y profundo, e iterar.
- Sin equivalencia con la realidad de negocio. El auditor encuentra un IDOR en una API interna y lo marca como crítico sin saber que esa API solo es accesible desde la VPN del equipo de desarrollo. Sin contexto de negocio, la priorización está mal.
- Informe sin retest. El esfuerzo de corregir se diluye si nadie valida que las correcciones funcionan.
- Auditor sin certificaciones técnicas reconocidas. Una "auditoría" hecha con un Nessus y un PDF generado automáticamente no es una auditoría.
- Cero coordinación con el equipo defensivo. Si tu SOC no sabe que hay una auditoría en marcha, o gasta su tiempo respondiendo al auditor como si fuera un atacante real, o no detecta nada y nadie se entera de que su capacidad de detección tiene fallos.
Preguntas frecuentes
¿Cada cuánto hay que hacer una auditoría de ciberseguridad?
El estándar de mercado es anual para empresas con activos críticos, complementada con pentests específicos cuando hay cambios mayores (nuevo producto, migración cloud, integración crítica). NIS2 exige pruebas periódicas sin fijar frecuencia exacta. DORA exige TLPT al menos cada tres años para entidades grandes. ENS exige auditoría bianual.
¿Auditoría interna o auditoría externa?
Una auditoría externa aporta independencia, comparativa con otras organizaciones y, en muchos casos, validez normativa que la interna no tiene. La interna sirve como preparación o como seguimiento, pero no la sustituye. Para evidenciar cumplimiento (ISO 27001, ENS) se necesita auditor externo.
¿Qué diferencia hay entre auditoría y compliance check?
Una auditoría evalúa el estado real con evidencia técnica y documental. Un compliance check rellena un cuestionario sin verificar evidencia. Lo segundo no resiste una inspección regulatoria seria.
¿Hace falta detener los sistemas durante una auditoría?
En la mayoría de casos no. Una auditoría técnica profesional se ejecuta sobre sistemas en producción con técnicas no intrusivas, y las pruebas más agresivas se coordinan con tu equipo en ventanas horarias acordadas. En entornos OT/industriales se trabaja sobre réplicas o en ventanas de mantenimiento programadas.
¿La auditoría incluye corregir las vulnerabilidades?
No por defecto. La auditoría identifica y documenta. La corrección la ejecuta tu equipo (interno o externo). Algunos proveedores ofrecen el servicio de remediación como proyecto separado, pero mantener al mismo equipo en auditoría y remediación es problemático por independencia.
¿Se puede auditar entornos cloud sin permisos completos?
Para una auditoría cloud profesional se necesita acceso de lectura a los recursos cloud (IAM, configuraciones, logs). Las pruebas no requieren permisos de escritura ni cambios en producción. El acceso se concede de forma temporal y con cuentas dedicadas auditables.
¿Cuánto tarda en estar listo el informe?
El borrador suele entregarse 1 a 2 semanas tras el cierre de la fase de pruebas. La versión final tras incorporar comentarios del cliente sale 1 a 2 semanas después. Los proveedores que entregan informe el mismo día que terminan las pruebas suelen ser los que entregan informes débiles.
¿Una auditoría me ayuda a renovar mi seguro de ciberriesgos?
Sí. La mayoría de aseguradoras de ciberriesgo en España exigen evidencia técnica reciente (auditoría o pentest de los últimos 12 a 24 meses) para mantener cobertura o reducir prima. Sin esta evidencia, las pólizas se encarecen o se cancelan tras un incidente.
Por dónde empezar
Si tu empresa necesita una auditoría de ciberseguridad y no sabes por dónde empezar, el orden razonable es:
- Identifica el motivo real: cumplimiento, lanzamiento, incidente, due diligence, renovación cíclica. El motivo define el tipo de auditoría.
- Define el alcance prioritario: aplicaciones más expuestas, infraestructuras más críticas, normativa más urgente.
- Pide tres propuestas a proveedores con equipo técnico real (no comerciales puros).
- Compara metodología, equipo y entregables, no solo precio. La diferencia entre la auditoría barata y la cara no es el coste, es lo que recibes.
- Planifica el retest desde el principio, no como add-on.
En Secra ofrecemos las siguientes líneas de auditoría técnica:
- Auditoría de aplicaciones web y móviles (OWASP Top 10, MASVS, APIs)
- Auditoría de infraestructura interna y externa (perímetro, Active Directory, hardening)
- Auditoría cloud para AWS, Azure y GCP (IAM, S3/Blob/GCS, CIS Benchmarks)
- Auditoría de redes inalámbricas (WPA2/WPA3, rogue APs, segmentación)
- Auditoría IoT y OT (firmware, Modbus/DNP3, segmentación IT/OT)
- Ejercicios de Red Team (APT simulada, evasión, detección)
En paralelo acompañamos en consultoría GRC para NIS2, DORA, ENS e ISO 27001 cuando la auditoría está motivada por cumplimiento.
Si quieres revisar tu caso, puedes contactar con nosotros y te decimos qué tipo de auditoría encaja antes de hablar de propuesta.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.