¿Qué incluye una auditoría de seguridad informática en una empresa?

Para entender qué incluye una auditoría de seguridad informática en una empresa, conviene distinguir la parte organizativa, que evalúa responsabilidades, accesos, copias de seguridad y respuesta ante incidentes, de la técnica, que revisa la configuración de los sistemas, las vulnerabilidades y el código. El precio depende del volumen de sistemas que se revisen y de la profundidad del trabajo: nuestra comprobación de seguridad automatizada cuesta 89-890 € según el alcance, mientras que la auditoría manual de un experto está disponible desde 3.500 €. Aclare primero qué parte necesita y qué evidencias espera, porque la revisión de un sitio web, la evaluación de la gestión de la seguridad de una empresa y la certificación son encargos distintos con resultados distintos.

Imagine que, antes de firmar un contrato, un cliente le exige una auditoría de seguridad informática y adjunta preguntas tanto sobre los permisos de acceso de los empleados como sobre la revisión técnica del sistema. No basta con reenviar el requisito al desarrollador: debe acordar si el cliente espera un informe sobre el sitio web, procesos documentados de la empresa o un certificado de un organismo independiente, y qué sistemas o parte de la actividad debe cubrir esa acreditación. Recomendamos conservar la formulación exacta de la solicitud y aclarar su finalidad antes de elegir al proveedor y aceptar el presupuesto.

Qué incluye una auditoría de seguridad informática: dos trabajos bajo un mismo nombre

Las dos partes responden a preguntas distintas. La parte organizativa examina cómo toma y aplica la empresa las decisiones de seguridad; la técnica, cómo funciona un sistema concreto y si es posible eludir sus protecciones. Por eso, un mismo tema se aborda de formas muy distintas: al evaluar el procedimiento de permisos de acceso, el auditor pide que se le muestre quién aprueba los permisos de un empleado y cómo se revocan; al probar la aplicación, intenta realizar con una cuenta ordinaria acciones que esa cuenta no tiene permitidas. Conviene leer ambos resultados conjuntamente, pero uno no sustituye al otro: una política de acceso bien definida no demuestra que la aplicación la cumpla, y una aplicación segura no demuestra que alguien haya desactivado la cuenta de un empleado que ya no trabaja en la empresa.

Por eso, la palabra «auditoría» por sí sola dice poco en un encargo. Recomendamos añadir dos cosas: los criterios con los que se evaluará el trabajo y las evidencias que espera encontrar en el informe. En una evaluación de vulnerabilidades, se trata de hallazgos con sus prioridades; en las pruebas de penetración, de un mecanismo de protección o una restricción operativa concreta que se intentará eludir; y en una auditoría organizativa de cumplimiento, de un conjunto de requisitos con el que se compararán los documentos y la práctica diaria.

Si elige únicamente una evaluación inicial de deficiencias, denomine así también al resultado, en lugar de llamarlo certificación, y acuerde desde la definición del encargo quién deberá leer ese documento y qué decisión deberá tomar. En una certificación es importante saber quién emitirá el certificado: ISO no certifica empresas directamente y explica la certificación como una declaración escrita de un organismo independiente que acredita el cumplimiento de determinados requisitos. En esa misma explicación, ISO señala que la acreditación demuestra la competencia del organismo de certificación, aunque no es obligatoria; por tanto, afirmar que solo puede certificar un organismo acreditado sería impreciso. Si su cliente exige una certificación acreditada, aclare esa condición antes del contrato y compruebe la acreditación del organismo elegido para evitar recibir después un certificado que el cliente no haya aceptado admitir.

Nuestra oferta consiste en la revisión técnica de sistemas web y, en la parte organizativa, podemos ayudar a preparar políticas de seguridad, pero no certificamos empresas ni gestionamos en su nombre un sistema de gestión de la seguridad de la información (SGSI); conviene dejar este límite por escrito también en el encargo. Si el trabajo incluye tanto la revisión del sitio web como la evaluación de la gestión de la empresa, acuerde quién preparará las evidencias técnicas, quién las comparará con los requisitos elegidos y quién será responsable de la evaluación final. De lo contrario, puede esperar de nosotros una evaluación de los procesos de gestión y del auditor organizativo una prueba que no ha contratado. La parte organizativa suele realizarla un consultor de gestión de la seguridad de la información o un auditor ISO/IEC 27001, mientras que el certificado lo emite un organismo de certificación.

Parte organizativa: comparar los documentos con la práctica

El papel lo aguanta todo, por lo que en la parte organizativa conviene comprobar que lo establecido en la política de seguridad cuenta con una persona responsable, los recursos necesarios y evidencias de ejecución, y que existe una actuación prevista para los problemas identificados en la evaluación de riesgos; la guía de ENISA para pequeñas y medianas empresas abarca la responsabilidad de la dirección, la participación y formación de los empleados, las políticas de seguridad, la gestión de proveedores, la protección de accesos y el plan de respuesta ante incidentes. Complete las entrevistas con la dirección y los empleados con la revisión de documentos y ejemplos concretos de trabajo, para que la evaluación permita distinguir el procedimiento previsto de su aplicación e identificar las evidencias que el auditor no haya podido obtener y que aún deban prepararse.

En materia de acceso, un buen auditor no solo examina cómo se asignan las cuentas, sino también cómo se desactivan, si se utiliza autenticación multifactor y qué permisos tienen los proveedores. Por eso conviene incluir entre los ejemplos revisados la salida de un empleado o el cambio de proveedor: es precisamente en esos casos cuando suelen olvidarse las cuentas. Con las copias de seguridad ocurre algo parecido, porque responder «hacemos copias» dice poco. Una copia que nadie haya restaurado nunca puede resultar incompleta durante un incidente, y descubrirlo cuando el sitio web ya no funciona. El inventario de sistemas y dispositivos necesita responsables; los registros de eventos, un procedimiento de revisión; y el plan de respuesta ante incidentes, una persona identificada que tome decisiones y se comunique con los implicados. De lo contrario, el plan se queda en un documento que nadie aplica durante el incidente.

Como criterio puede utilizarse ISO/IEC 27001:2022, que establece los requisitos de un sistema de gestión de la seguridad de la información (SGSI); aquí, «sistema» se refiere a la gestión, no solo a la aplicación que se revisa. La explicación de la norma publicada por BSI enumera 93 controles de la seguridad de la información y cuatro áreas: organizativa, de personas, física y tecnológica. Acuerde qué requisitos evaluará la auditoría y con qué evidencias, porque una referencia a la norma en el presupuesto no aclara si está contratando la evaluación del sistema de gestión o solo una revisión técnica cuyos resultados se utilizarán posteriormente en una auditoría más amplia; deje esa elección por escrito antes de empezar.

Otra base son los CIS Controls v8.1, con 18 grupos de controles, que abarcan desde el inventario de activos de la empresa hasta las pruebas de penetración y reúnen 153 medidas de protección. CIS describe CIS Implementation Group 1 (IG1) como las prácticas básicas de ciberseguridad, con 56 medidas de protección; por tanto, especifique en el encargo el grupo elegido, además del nombre del marco. Exija que el informe vincule cada requisito evaluado con la evidencia recibida y la deficiencia detectada, para que después de las correcciones pueda comprobarse exactamente la misma condición, en lugar de comparar dos evaluaciones generales.

Cuándo exige la ley una auditoría de seguridad informática

Según la decisión de la Comisión Europea de 8 de julio de 2026, España aún no había notificado la transposición completa de la Directiva (UE) 2022/2555 (NIS2). A esa fecha no había una obligación española de auditoría basada en las categorías de «entidades esenciales e importantes» de NIS2. El marco vigente lo forman el Real Decreto-ley 12/2018 y el Real Decreto 43/2021: se aplica a los operadores designados de servicios esenciales y a los proveedores de mercados en línea, motores de búsqueda en línea y servicios de computación en nube, con exclusión de las microempresas y pequeñas empresas proveedoras de esos servicios digitales. El artículo 32 del Real Decreto-ley 12/2018 no impone a todos los operadores de servicios esenciales la obligación general de contratar periódicamente una auditoría externa: la autoridad competente puede auditar sus redes y sistemas, exigir una auditoría por una entidad externa, solvente e independiente y requerir que se subsanen las deficiencias. El artículo 15.4 del Real Decreto 43/2021 permite exigir ese informe externo cuando el volumen o la complejidad de la inspección lo aconsejen. Según el artículo 9 del real decreto-ley, para los operadores esenciales que también sean críticos conforme a la Ley 8/2011, la autoridad es la Secretaría de Estado de Seguridad, a través del Centro Nacional de Protección de Infraestructuras y Ciberseguridad (CNPIC); para los demás, la autoridad sectorial indicada en el artículo 3 del Real Decreto 43/2021. Para los proveedores de servicios digitales es la Secretaría de Estado de Digitalización e Inteligencia Artificial. Si el operador o proveedor pertenece al sector público conforme a la Ley 40/2015 y no es operador crítico, corresponde al Ministerio de Defensa, a través del Centro Criptológico Nacional (CCN). El artículo 33 solo permite inspeccionar a los proveedores de servicios digitales cuando se tenga noticia de un incumplimiento y no recoge la facultad de exigir esa auditoría externa. CCN-CERT, INCIBE-CERT y ESPDEF-CERT son los equipos de respuesta a incidentes de referencia: reciben notificaciones y prestan apoyo cuando se les solicita; esa función no los convierte en la autoridad que ordena la auditoría.

Por su parte, el Real Decreto 43/2021 exige a los operadores designados de servicios esenciales una Declaración de Aplicabilidad de medidas de seguridad, firmada por el responsable de seguridad de la información e incluida en la política de seguridad aprobada por la dirección. Debe remitirse a la autoridad competente en los seis meses siguientes a la designación del operador y revisarse al menos cada tres años; no es una auditoría externa. El responsable debe efectuar controles periódicos de seguridad, sin un intervalo fijado por el decreto, que tampoco exige pruebas de penetración periódicas. Su artículo 6.5 remite, en la medida en que resulte aplicable, al anexo II del derogado Real Decreto 3/2010 y permite otros estándares reconocidos internacionalmente; esa referencia no equivale a exigir un certificado del Esquema Nacional de Seguridad (ENS). Por separado, el ENS, regulado por el Real Decreto 311/2022, se aplica a los sistemas del sector público y a los privados que, mediante contrato, le prestan servicios o soluciones para el ejercicio de sus competencias y potestades administrativas. Para acreditar la conformidad, la categoría BÁSICA solo requiere una autoevaluación y una declaración de conformidad; las categorías MEDIA y ALTA requieren una auditoría de certificación. Las auditorías ordinarias deben realizarse al menos cada dos años, y las extraordinarias, tras cambios sustanciales que puedan afectar a las medidas de seguridad; estas últimas reinician el cómputo. El plazo admite hasta tres meses adicionales por fuerza mayor no imputable al titular del sistema. El refuerzo R6 de la medida op.mon.3 del anexo II exige para la categoría ALTA verificaciones de configuración, análisis de vulnerabilidades y pruebas de penetración periódicas o tras incidentes que revelen vulnerabilidades nuevas o subestimadas; no fija un intervalo en años ni una prueba previa a la puesta en servicio, y no se exige a la categoría MEDIA. Además, el artículo 26 del Reglamento (UE) 2022/2554 (DORA) exige pruebas de penetración basadas en amenazas al menos cada tres años solo a las entidades financieras identificadas por la autoridad competente, que puede modificar el intervalo; quedan excluidas las microempresas y las entidades del artículo 16.1, párrafo primero. Por tanto, si recibe una oferta para realizar una «auditoría obligatoria», pida que se identifiquen la obligación concreta y su condición: preparar la Declaración de Aplicabilidad, elaborar el informe de auditoría requerido por la autoridad conforme al artículo 32 del Real Decreto-ley 12/2018 y al artículo 15.4 del Real Decreto 43/2021, realizar una autoevaluación o auditoría de certificación ENS para una categoría concreta y efectuar una prueba DORA para una entidad financiera identificada son encargos distintos.

Parte técnica: de las direcciones públicas al código

En la especificación técnica, enumere las direcciones públicas, los registros DNS, los servicios expuestos y la configuración TLS, así como la configuración del servidor o del entorno en la nube, las aplicaciones web y el código fuente cuya revisión autoriza. Indique en cada parte si el proveedor tendrá acceso a la configuración o evaluará únicamente lo visible desde el exterior, porque son trabajos distintos. La clasificación de técnicas de pruebas de seguridad del NIST distingue la revisión de documentos, registros y configuraciones de la identificación y el análisis de objetivos, así como de la confirmación de vulnerabilidades; puede utilizar esta clasificación para describir con mayor precisión en el presupuesto los métodos elegidos y el resultado esperado.

Para las aplicaciones web, OWASP Top 10:2025 ofrece un lenguaje común: diez categorías de riesgos, cuyas dos primeras son los fallos de control de acceso y la configuración insegura. La lista no comprueba nada por sí sola, de modo que un buen auditor convierte cada categoría en una pregunta sobre su aplicación: en el control de acceso, eso significa intentar realizar las acciones de un rol con la cuenta de otro; en la categoría de diseño inseguro, elegir un proceso de negocio cuyas reglas puedan eludirse. Complete la referencia a OWASP con la extensión de la revisión, para que ambas partes tengan claro qué funciones y roles de usuario se incluyen realmente en el trabajo.

En la parte de correo electrónico, prevea la evaluación de SPF, DKIM y DMARC y vincule el encargo con los sistemas desde los que la empresa envía mensajes: desde el 1 de febrero de 2024, los requisitos de Google para remitentes establecen que todo remitente a cuentas de Gmail configure SPF o DKIM, y que quienes envíen más de 5.000 mensajes al día configuren SPF, DKIM y DMARC. La política DMARC puede ser «none», pero, en los envíos directos, el dominio del campo From debe estar alineado con el dominio SPF o DKIM. Por eso, pida que se evalúen tanto la configuración como las vías de envío que utiliza, sin limitarse a marcar la presencia de los registros del dominio.

En nuestras auditorías, el hallazgo más frecuente es la falta de instalación de actualizaciones de PHP, del núcleo del sistema de gestión de contenidos y de los frameworks. Por eso recomendamos incluir en la especificación técnica un inventario de las versiones, los plugins y las dependencias utilizados, y pedir que cada hallazgo identifique el componente concreto y la actuación necesaria. Así, el desarrollador recibe una tarea que puede ejecutar, en lugar de una observación genérica sobre un sitio web desactualizado. Si lo más importante para usted es qué pueden hacer los usuarios en el sistema, el inventario de versiones no basta: también hacen falta pruebas de control de acceso y pruebas de lógica de negocio. En nuestra experiencia hemos encontrado fallos críticos que permitían a cualquier usuario obtener permisos de administrador y cuya corrección acabó requiriendo reescribir por completo el núcleo del sistema; un inventario de versiones no habría detectado un fallo así.

La pregunta sobre qué puede hacer un usuario es distinta de la pregunta sobre las versiones instaladas, y cada una necesita sus propias evidencias en el informe. El NIST define el análisis de vulnerabilidades como una técnica para identificar equipos, sus características y las vulnerabilidades asociadas; en nuestra comprobación de seguridad automatizada, ese análisis es una de las fases del trabajo técnico. Según la explicación del NIST sobre las pruebas de penetración, estas se caracterizan por reproducir ataques reales para buscar formas de eludir las protecciones y, a menudo, combinaciones de vulnerabilidades que permitan obtener un acceso más amplio. Examinamos con más detalle la elección de estas pruebas en el artículo sobre pruebas de penetración; en el encargo de auditoría, lo importante es determinar qué deficiencias se limitará a buscar el proveedor, para cuáles intentará demostrar su explotación práctica dentro de los límites acordados y qué actuaciones quedarán expresamente fuera del trabajo.

Cómo se desarrolla la auditoría, del encargo a la reverificación

Empiece por una descripción escrita del alcance de la auditoría que identifique los sistemas, las aplicaciones, las direcciones y los roles de usuario que se revisarán y señale claramente qué quedará fuera del encargo. Añada el objetivo y los límites del trabajo: qué actuaciones autoriza, en qué entorno se realizarán, quién puede detener la revisión y con quién debe contactarse ante una situación imprevista. Por ejemplo, para un sistema de pedidos, acuerde por separado cómo se probarán las acciones que, de otro modo, generarían un pedido real. El responsable del mantenimiento también debe leer este acuerdo, para que las actuaciones autorizadas, los accesos y las personas de contacto estén acordados antes de comenzar el trabajo técnico.

Antes de empezar, prepare los documentos y las personas que participarán en las entrevistas en la medida que requiera el encargo: para la parte organizativa, políticas, ejemplos de asignación de accesos, registros de restauración de copias de seguridad y el plan de respuesta ante incidentes; para la técnica, la descripción del sistema y los accesos acordados, indicando también lo que todavía no tiene. Si se revisa una copia, documente sus diferencias respecto al sistema utilizado habitualmente y acuerde cómo se reflejarán en el informe, para que el lector pueda comprender después a qué entorno se aplican los resultados y qué cuestiones han quedado abiertas por falta de documentos, acceso o disponibilidad de una función. Para el trabajo técnico, acuerde horarios concretos de pruebas y un procedimiento de comunicación; para la evaluación documental, establezca un plazo para que sus compañeros puedan aportar aclaraciones, de modo que el resultado distinga claramente lo comprobado de lo que aún no se ha confirmado.

Si el proveedor encuentra un problema importante durante el trabajo, exija que lo comunique por el procedimiento acordado mientras continúa con el resto, sin esperar a la fecha de entrega del informe completo. Acuerde también quién decidirá si se sigue probando ese punto y cómo se registrarán las autorizaciones o restricciones recibidas, porque esas decisiones serán necesarias para explicar hasta dónde se ha podido confirmar el hallazgo concreto.

El plazo debe incluir tiempo para las correcciones

La auditoría con nuestro sistema tarda unos días, mientras que el trabajo de auditoría manual requiere 1-3 semanas según el alcance de la auditoría; puede haber una espera antes de empezar, en función de la carga de trabajo del auditor. La página del servicio indica un intervalo total de ejecución de 1-60 días, por lo que no debe interpretar estas descripciones como un único plazo garantizado. Antes de contratar, acuerde la fecha de inicio, la entrega del informe y la reverificación. Si tiene una fecha fijada por un cliente o una licitación, reserve también tiempo para revisar y corregir los hallazgos y para que su equipo responda a las preguntas: la fecha de finalización de la revisión y la fecha en la que desea haber subsanado las deficiencias son hitos distintos de la planificación.

Nuestra oferta de auditoría manual de un experto incluye una reverificación en los 30 días posteriores a las correcciones. Para aprovecharla, acuerde al entregar el informe quién corregirá cada hallazgo, quién comunicará la finalización del trabajo y qué evidencias volverá a comprobar el proveedor. Defina por separado el volumen y el pago de las correcciones, porque el precio de la auditoría no constituye un acuerdo sobre todo el desarrollo posterior. Puede realizar las correcciones con su equipo y nosotros las comprobaremos después, o encargárnoslas como un trabajo independiente que presupuestaremos tras el informe. En el informe de reverificación, exija que se distinga una deficiencia subsanada de otra aplazada o aún no verificada, y que se indique el estado del sistema utilizado, para que su equipo y el destinatario del informe dispongan de una respuesta clara y común para cada hallazgo inicial.

Qué exigir al informe de auditoría

Al principio del informe, exija un resumen comprensible para la dirección sobre el objetivo de la revisión, los sistemas cubiertos y los hallazgos más importantes, de manera que puedan tomarse decisiones sobre el trabajo y los recursos sin releer todo el material técnico. Pida que en ese mismo apartado se indiquen también las limitaciones del trabajo. Si no se ha dispuesto del código fuente o no se ha examinado un rol de usuario, pida que se diga expresamente, en lugar de dejar que el lector adivine qué significa la breve valoración del estado del sistema. Evalúe ese resumen según permita a su responsable identificar la siguiente decisión, la persona responsable y la pregunta que aún no tiene respuesta.

Para cada hallazgo técnico, exija su ubicación en el sistema, las circunstancias en que se detectó, el rol de usuario utilizado, la descripción de los pasos para reproducirlo y las evidencias del resultado. Para una no conformidad organizativa, pida que, junto a la referencia al requisito, se identifique el documento o ejemplo de trabajo en el que se basa la evaluación. La recomendación de corrección debe dejar claro qué hay que cambiar exactamente: concrete una formulación como «revisar los accesos» hasta identificar los permisos y la función que su desarrollador debe modificar, e indique el comportamiento esperado tras la corrección. Así, el informe servirá tanto para asignar la tarea como para comprobarla después, sin obligar a cada nuevo lector a reinterpretar la intención del auditor.

Si el informe utiliza CVSS, pida que se indique también la versión: FIRST publica CVSS, incluida la versión 4.0, cuya escala de gravedad utiliza las categorías «ninguna» (0,0), «baja» (0,1-3,9), «media» (4,0-6,9), «alta» (7,0-8,9) y «crítica» (9,0-10,0); el uso de esas denominaciones es opcional. Junto a la cifra, exija una justificación y una explicación referida a la actividad de su empresa: por ejemplo, a qué operación o conjunto de datos afecta el hallazgo y por qué se recomienda corregirlo en ese orden. Así podrá debatir la prioridad a partir de las circunstancias descritas, no solo de la puntuación.

Utilizamos nuestra experiencia con estos fallos críticos para exigir una descripción clara de sus consecuencias, no para afirmar que todos los sitios web necesitan una reconstrucción: el informe debe permitir distinguir una corrección concreta de un problema cuya solución exige revisar el funcionamiento básico del sistema. Si el informe propone una reelaboración amplia, pida que se muestren las evidencias que respaldan esa recomendación, qué puede corregirse por separado y qué cuestión quedaría sin resolver si la empresa eligiera solo una parte del trabajo propuesto.

Si el equipo técnico lo necesita, solicite como anexo el archivo de resultados sin procesar del escáner, pero vincule la aceptación del informe a las evidencias, las prioridades y las recomendaciones de corrección ejecutables que espera de su encargo; no utilice la cantidad de líneas como medida de calidad. Pida al proveedor que explique un hallazgo de principio a fin: cómo se detectó, qué demuestra el resultado, cómo afecta a su sistema y cómo se comprobará tras los cambios que se ha subsanado. Pídale también que identifique todo lo que aún sea una suposición en esa conclusión. Esta revisión aporta una base concreta para aceptar el informe y repartir el trabajo posterior.

Por qué varían tanto los precios de las auditorías

Los precios varían principalmente porque las ofertas cubren distintos números de sistemas y distintas profundidades de trabajo: el análisis automatizado y el inventario de versiones cuestan cientos de euros, mientras que las pruebas manuales de control de acceso y pruebas de lógica de negocio, la auditoría de código fuente y la reverificación requieren jornadas de trabajo de un experto. En nuestro servicio de auditoría de seguridad web, la comprobación de seguridad automatizada cuesta 89-890 € según el alcance y está destinada a sistemas WordPress, Laravel, Drupal, Joomla y Moodle. La oferta incluye un análisis automatizado de vulnerabilidades, la comprobación de versiones, plugins y dependencias, la evaluación de la configuración y los ajustes del servidor, y un informe con hallazgos y prioridades. Utilice ese contenido al comparar el precio con otra oferta y aclare qué instalaciones suyas se revisarán. Relacione el importe inferior del intervalo con el alcance acordado, para no aplicar el precio de revisar un sitio web a todos los sistemas de la empresa cuando el proveedor todavía no ha evaluado sus límites.

Nuestra auditoría manual de un experto está disponible desde 3.500 € e incluye una revisión manual conforme a OWASP Top 10, pruebas de control de acceso y pruebas de lógica de negocio para intentar eludir sus reglas, una auditoría de código fuente y pruebas de penetración autorizadas. La auditoría de código fuente está prevista para Laravel, WordPress y soluciones desarrolladas a medida; en el informe ordenamos los hallazgos según el riesgo real y añadimos una recomendación de corrección a cada uno. La oferta incluye también una reverificación tras las correcciones. La expresión «desde» sigue siendo válida aunque su sistema solo tenga una dirección pública, porque para presupuestarlo aún deben acordarse las funciones, los roles y el código que se revisará.

Una comprobación completa con nuestro sistema suele costar 500-800 €. Es el importe que observamos con mayor frecuencia dentro del intervalo de precios de la comprobación de seguridad automatizada, no un precio independiente por evaluar conjuntamente la gestión de la empresa, todos sus sistemas y la certificación; por tanto, vincule la palabra «completa» con el alcance técnico concreto que hayamos acordado. Para la mayoría de los sitios web recomendamos una comprobación de seguridad automatizada periódica, que pueda repetirse con frecuencia, y una auditoría manual de un experto cuando el sistema procese pagos, datos personales o sea crítico para el negocio, porque los fallos de permisos de acceso y las formas de eludir la lógica de negocio solo los detecta una persona. En la práctica funciona bien combinar comprobaciones de seguridad automatizadas periódicas con una auditoría manual anual.

Esta distinción también ayuda al hablar del presupuesto: si necesita respuestas sobre los componentes y la configuración del sitio web, pida un presupuesto para ese trabajo; si la pregunta principal es si pueden eludirse los permisos de usuario o las reglas de negocio, incluya las pruebas manuales correspondientes y permita que el proveedor valore ese trabajo por separado.

Para comparar, prepare una descripción idéntica de los sistemas, las aplicaciones, los roles de usuario y, si necesita también la parte organizativa, los centros de actividad de la empresa. Después, pida que se indiquen por separado las actuaciones automatizadas y las manuales. Imagine un presupuesto solo para el sitio web público y otro para ese mismo sitio web junto con el área de clientes, la administración y el código fuente: antes de comparar las cifras, aclare los límites de cada oferta. Registre también para cada parte los accesos necesarios, los criterios de cumplimiento elegidos y el destinatario del informe. Así ofrece al proveedor una base concreta para calcular el presupuesto y se permite detectar tareas omitidas.

Aclare por separado si el precio incluye explicar los hallazgos a su desarrollador, relacionarlos con los requisitos de la norma elegida y realizar la reverificación, así como dónde termina la auditoría y empieza el desarrollo de las correcciones. Recomendamos que, al definir el presupuesto de auditoría, también se tome una decisión sobre la subsanación de las deficiencias detectadas. Si los precios siguen siendo muy distintos entre ofertas con la misma extensión, pida a los proveedores que expliquen el trabajo y sus límites mediante una función concreta, como un cambio de acceso de usuario, en lugar de añadir nombres de servicios. Así podrá elegir según el resultado concreto y las responsabilidades, sin depender de una promesa de seguridad integral.

Cuándo necesita una empresa una auditoría de seguridad informática

Recomendamos contratar una auditoría cuando la empresa deba tomar una decisión concreta sobre seguridad o presentar una acreditación verificable, y determinar desde el principio si esa decisión afecta a la gestión, al estado técnico o a ambos. Si el motivo es NIS2, aclare primero su condición y los requisitos aplicables, utilizando también nuestro artículo sobre NIS2 y su ámbito de aplicación; después, defina el encargo. El orden es importante: aclare la aplicabilidad de los requisitos y la acreditación necesaria antes de elegir el servicio, para que contratar un informe técnico no se convierta en su única respuesta a una cuestión que también exige evaluar las responsabilidades y los procesos de la empresa. Si el sitio web no tiene cuentas de usuario, pagos ni tratamiento de datos personales y nadie exige una acreditación, normalmente no hace falta una auditoría amplia: instale primero las actualizaciones y bastará con una comprobación de seguridad automatizada.

Si una aseguradora o un cliente exige la revisión, pídale que concrete el resultado esperado y facilite al proveedor el texto del requisito. Por ejemplo, distinga una pregunta sobre formación de empleados o pruebas de restauración de copias de seguridad de un requisito de revisión de los permisos de acceso de la aplicación, y prepare las evidencias correspondientes para responder. Si un cuestionario de proveedores exige acreditar un proceso de seguridad más amplio que el cubierto por su auditoría técnica, acuerde con el cliente la información adicional y designe en la empresa a una persona que la recopile, en lugar de ampliar el significado del informe técnico. Aclare también si el destinatario espera el propio informe, respuestas a preguntas concretas u otra forma de acreditación, y en qué plazo.

Para una licitación, conserve el tipo de revisión exigido y las condiciones de cualificación del proveedor exactamente como los haya formulado la entidad contratante, y resuelva las dudas antes de solicitar un presupuesto para evitar tener que rehacer la oferta después de empezar. Examinamos la elección con más detalle en el artículo sobre la revisión de seguridad exigida en una licitación; para preparar la especificación técnica, puede enviarnos el texto del requisito y la descripción del sistema. Indique también la fecha de presentación, la documentación disponible y quién realizará las correcciones por su parte, porque la conversación sobre la ejecución de la revisión debe abarcar tanto la preparación del informe como la capacidad de su equipo para trabajar con sus resultados antes de la fecha requerida.

Después de un incidente y entre las revisiones programadas

Después de un incidente, recomendamos orientar el encargo de auditoría a la pregunta concreta que siga sin respuesta: si la corrección subsana el problema detectado, si debe buscarse un fallo de acceso similar en otra función y cómo comprobará la empresa en adelante que se cumple el procedimiento correspondiente. Entregue al proveedor una descripción de los hechos conocidos y distinga los hechos confirmados de las suposiciones. Si desea esclarecer cómo se desarrolló el incidente, identifique ese trabajo por separado y acuerde su resultado, sin dar por supuesto que una auditoría general del sitio web responderá automáticamente a todas las preguntas sobre el incidente. Mantenga, además, la relación entre las correcciones que se revisen y los hallazgos originales, para poder indicar después de los cambios qué problema concreto volvió a comprobar y cómo.

Nuestros clientes suelen contratar una auditoría una o dos veces al año; se trata de una observación de nuestra experiencia, no de un intervalo establecido para todas las empresas. Recomendamos anotar en su plan, junto a la próxima fecha, los cambios que le llevarán a reconsiderar la extensión de la revisión, como un nuevo rol de usuario, una función de acceso reescrita o un cambio de proveedor con permisos en el sistema. Encargue a la persona responsable que compare esos cambios con el alcance de la auditoría anterior y proponga la parte concreta que debe revisarse. Conserve los hallazgos sin resolver del informe anterior en el siguiente encargo, junto con las decisiones de aplazarlos, para que la nueva revisión parta de la situación conocida.