¿Qué es el pentesting? Definición, fases, informe y límites

Si has llegado hasta aquí es porque alguien ha puesto la palabra encima de la mesa: un cliente que pide un informe antes de firmar, un pliego que menciona el Esquema Nacional de Seguridad, una entidad certificadora, o simplemente la sensación incómoda de no saber qué aguantaría lo que tienes publicado en internet.

La definición corta la tienes en cualquier parte, empezando por el propio INCIBE, que la explica bien y gratis. Así que esta página no compite en eso. Lo que intenta es otra cosa: contarte el trabajo por dentro —cómo se acota, cómo transcurre, qué llega al final y en qué se te va el dinero— y, sobre todo, ser explícita en la parte que las páginas comerciales suelen esquivar, que es qué cosas un pentest no hace. Comprar bien esto depende más de entender sus límites que de entender su definición.

Conviene que sepas cuál es nuestro interés antes de seguir: vendemos pentesting. Por eso hemos preferido citar las normas a resumirlas, y decir con la misma claridad en qué casos te basta con algo más barato.

Qué es un pentest, en una frase

Un pentest —en registro de contratación, test de intrusión; «pruebas de penetración» en el texto del Esquema Nacional de Seguridad— es un ataque simulado contra un sistema de información, ejecutado por especialistas en seguridad ofensiva con autorización escrita de quien tiene poder de disposición sobre ese sistema, sobre un alcance definido en contrato y dentro de una ventana temporal acordada.

Las tres condiciones destacadas no son adorno jurídico. Quítale una cualquiera y lo que queda ya no es un pentest: sin autorización es un delito, sin alcance es una promesa imposible de cumplir y sin ventana es un riesgo operativo para el negocio, porque nadie sabe si la caída de las tres de la tarde la ha provocado la prueba o un cambio en producción.

Una nota de vocabulario que ahorra malentendidos en una mesa de contratación. En España conviven dos registros y no compiten: en una conversación comercial se dice pentesting, que es lo que la gente escribe en un buscador, y en un pliego, en una política interna o en la carpeta de quien audita se escribe test de intrusión. La forma literal que emplea el Real Decreto 311/2022 es la tercera, y por eso aparece entrecomillada cuando citamos el decreto. Fuera de ese registro no es la expresión que usa el mercado —en español general nombra además un ensayo geotécnico del terreno—, así que no la vas a ver encabezando ninguna de nuestras páginas. No es una manía de estilo: si buscas la palabra equivocada dentro de un pliego, no encuentras la cláusula.

Por qué el resultado es una cadena y no una lista

Aquí está la distinción que ordena todo lo demás, y la que explica por qué dos presupuestos que prometen lo mismo pueden diferir en un factor de cinco.

Quien hace un pentest no se detiene cuando localiza una debilidad. Intenta explotarla, y después intenta encadenarla con otras para ver hasta dónde se llega. El resultado no es un cuadro de alertas ordenado por severidad, es un camino demostrado: de una dirección expuesta a una cuenta, de esa cuenta a un servidor, de ese servidor a la base de datos con los datos de tus clientes.

Esa forma de entregar el resultado es la que hace el informe utilizable. Una lista de debilidades teóricas no se prioriza —todo parece urgente o nada lo parece—, mientras que una cadena de explotación se prioriza sola: si el tercer eslabón se rompe, los dos primeros dejan de importar esta semana. Y se prioriza también en un comité de dirección sin cultura técnica, porque la frase «desde internet y sin credenciales se llega a la tabla de clientes en cuatro pasos» no necesita traducción.

Hay un segundo efecto, menos evidente y bastante más valioso. Las cadenas están hechas casi siempre de piezas que, por separado, nadie habría corregido: una fuga de información menor, una política de contraseñas floja, una cuenta de pruebas que quedó olvidada. Tres hallazgos de severidad baja en cualquier herramienta. Juntos, una toma de control completa. Ninguna suma de análisis individuales produce ese hallazgo, porque el hallazgo es la suma.

La autorización escrita es lo que lo separa de un delito

Un test de intrusión es lícito porque está autorizado. No porque lo haga una empresa con buena reputación, ni porque exista un contrato de servicios genérico, ni porque «al fin y al cabo son sistemas del cliente».

Los arts. 197 bis, 197 ter, 264, 264 bis y 264 ter del Código Penal describen las conductas de acceso a sistemas de información e interferencia en ellos realizadas «sin estar debidamente autorizado». Esa expresión es literalmente la frontera. Todo nuestro trabajo se ejecuta con autorización escrita, y no por formalismo: es el elemento que convierte exactamente los mismos actos técnicos en un servicio en lugar de en un tipo penal.

El mandato tiene que fijar cinco cosas, y se comprueban en diez minutos antes de firmar:

1. Quién autoriza.

Una persona con poder de disposición sobre el sistema. El responsable de un departamento que «da el visto bueno» por correo no siempre lo tiene, y esa es la firma que faltaría si algo saliera mal.

2. Sobre qué recae.

Dominios, direcciones IP, aplicaciones, cuentas entregadas, entornos. Escrito con precisión suficiente para que no haya dudas a las once de la noche del segundo día.

3. Qué queda fuera.

Sistemas de terceros, subdominios que no controlas, denegación de servicio, ingeniería social si no se ha contratado, franjas horarias vetadas. La lista de exclusiones protege a las dos partes.

4. Cuándo.

Fecha de inicio, fecha de fin y, si procede, las horas en las que no se toca nada porque hay cierre contable o campaña.

5. A quién se llama.

Un contacto de emergencia localizable por ambas partes durante toda la ventana. Si un servicio se degrada, la llamada tiene que salir en minutos, no a la mañana siguiente.

Y una comprobación que se olvida casi siempre: si el sistema está alojado en un tercero —una nube pública, un proveedor de servicios gestionados, un fabricante de software en modo alojado— hay que mirar también su contrato. Los grandes proveedores de cloud permiten hoy probar tus propios recursos sin autorización previa, pero con reglas: nada de denegación de servicio, nada sobre la infraestructura compartida, nada sobre servicios de otros clientes. Es rápido de verificar y caro de asumir si nadie lo hizo.

Un apunte final que evita un mal rato. Si durante la ventana aparece un compromiso real y previo —alguien ya estaba dentro—, el trabajo se detiene y el hallazgo se escala de inmediato: eso ya no es una prueba, es un incidente. En España, INCIBE-CERT es el equipo de respuesta a incidentes de referencia para los ciudadanos y las entidades de derecho privado, en los términos del Real Decreto-ley 12/2018, y esa vía debe estar escrita en el procedimiento antes de empezar, no improvisada esa tarde.

Pentest, análisis, auditoría y Red Team no son la misma compra

Cuatro términos que los presupuestos mezclan y que responden a cuatro preguntas distintas. Reconocer cuál te están vendiendo es la mitad de la decisión.

La confusión cara es la primera pareja, porque la diferencia de precio entre un análisis y un pentest es de uno a varios y desde fuera las dos líneas de un presupuesto se parecen. La hemos desarrollado entera, con lo que dice el RGPD y lo que dice el ENS sobre cada uno, en análisis de vulnerabilidades o pentest.

La cuarta tiene además un orden lógico que conviene respetar: un ejercicio de Red Team no tiene mucho sentido si todavía aparecen vulnerabilidades conocidas en lo que tienes publicado, porque el ejercicio se resolverá por ahí y no habrás aprendido nada sobre tu capacidad de respuesta. Primero se cierra lo evidente; después se mide si te enterarías.

Caja negra, caja gris y caja blanca

Las tres expresiones describen cuánta información recibe quien prueba antes de empezar. Lo que de verdad deciden no es la calidad del trabajo, sino en qué se gastan las jornadas que has pagado.

Ninguno es superior a los otros, y desconfía de quien te diga lo contrario. La caja negra tiene un atractivo narrativo evidente —«a ver si entráis sin que os contemos nada»— que sale caro: si dedicas tres de diez jornadas a descubrir una infraestructura que podías haber descrito en un documento de dos páginas, has comprado realismo con presupuesto de hallazgos.

Un matiz con consecuencias prácticas: en una aplicación con varios perfiles, la caja gris sin cuentas de todos los roles deja fuera la clase de fallo más frecuente y más grave, que es la escalada horizontal de privilegios —el usuario A ve los pedidos del usuario B—. Si en el alcance solo hay una cuenta, esa comprobación no se ha hecho, y no se ha hecho por decisión de alcance, no por falta de pericia.

Qué se puede someter a un pentest

El principio no cambia con el objetivo; lo que cambia es la metodología y el perfil de quien lo ejecuta.

• Aplicaciones web y API — portales de cliente, aplicaciones internas, servicios REST y GraphQL. Es el alcance más demandado y donde aparecen los fallos de autorización y de lógica de negocio. La metodología pública de referencia es la OWASP WSTG, y se puede exigir por nombre en un pliego.
• Infraestructura y red — perímetro externo e interno, servidores, segmentación, y muy especialmente Active Directory, que sigue siendo el camino más corto entre un puesto de trabajo cualquiera y el control del dominio.
• Aplicaciones móviles — iOS y Android, con su parte de cliente, su almacenamiento local y el servicio al que hablan por detrás, que es donde suele estar el problema de verdad.
• Entornos cloud — AWS, Azure, Google Cloud, Microsoft 365. Aquí la vulnerabilidad clásica pesa poco y la configuración pesa casi todo: permisos excesivos, identidades con más alcance del necesario, almacenamiento accesible sin autenticar.
• OT, ICS e IoT — entornos industriales y dispositivos con firmware propio, donde una herramienta de red llega a la superficie del aparato y no más allá, y donde el criterio de «no interrumpir» manda sobre todo lo demás.
• Integraciones con IA y LLM — inyección de instrucciones, fuga del contexto, abuso de herramientas conectadas al modelo y envenenamiento de las fuentes en arquitecturas RAG. Es una superficie nueva con su propio catálogo de fallos, y la tratamos aparte en pentesting de integraciones LLM.
• Ingeniería social — phishing, vishing y smishing, con resultados siempre agregados y nunca nominales. En España este alcance tiene además requisitos previos propios, que no son opcionales: los tratamos en simulación de phishing y derechos de los trabajadores.

Un encargo típico combina dos o tres de estas líneas, y la elección debería salir de dónde están tus datos y tu dinero, no de dónde es más cómodo empezar. Dejar fuera una superficie entera —la red interna, el móvil, la nube— no ahorra riesgo: lo esconde.

Cómo transcurre, fase por fase

Los nombres cambian según el referencial —PTES, la OWASP WSTG para web, la MASTG para móvil, las guías CCN-STIC publicadas por el Centro Criptológico Nacional cuando el contexto es el Esquema Nacional de Seguridad—, pero el orden es el mismo en todos.

Dos fases concentran casi todo el valor y casi todos los problemas. La primera, porque un alcance mal acotado produce un informe correcto que responde a la pregunta equivocada. Y la sexta, porque sin post-explotación tienes la noticia de que alguien puede entrar, pero no la información que de verdad ordena tu trimestre, que es qué se lleva una vez dentro.

La contraauditoría: el paso que decide si el trabajo sirvió

Después de que tu equipo corrija, alguien tiene que volver a comprobar los hallazgos señalados. Eso es la contraauditoría —también la verás llamada retest—, y no es un test nuevo: se revisan los puntos concretos del informe anterior y se deja constancia de cuáles están cerrados.

Merece un apartado propio por una razón muy concreta: es lo que convierte tu documentación de «problema detectado» en «problema resuelto», y lo segundo es lo que te van a pedir. Un informe con veinte hallazgos y sin verificación posterior demuestra, ante quien lo lea con atención, que sabías lo que tenías mal. No demuestra que lo arreglaras.

En Haxoris la contraauditoría va incluida en el precio del servicio. En otros proveedores se factura como jornadas adicionales, lo cual es perfectamente legítimo siempre que aparezca en el presupuesto: pregúntalo antes de firmar, porque es la partida que más cambia la comparación entre dos ofertas que parecían iguales.

El informe es el producto

Todo lo anterior es trabajo no transmisible. Lo único que queda en tus manos es el informe, así que conviene saber qué tiene que llevar dentro.

• Una síntesis para dirección: qué se probó, qué se demostró, qué significa para el negocio. En lenguaje llano y sin capturas de terminal.
• Por cada hallazgo, la prueba de concepto reproducible: peticiones, capturas, el camino exacto que se siguió. Si no se puede reproducir, no está demostrado.
• Una valoración de riesgo contextual, no la puntuación heredada de una ficha. Un 6,5 en el portal de clientes suele ser más urgente que un 9,8 en una maqueta aislada sin datos reales.
• Una recomendación de corrección concreta, referida a tu tecnología y no a un párrafo genérico que valdría para cualquiera.
• Una priorización utilizable: qué se corrige esta semana, qué este mes y qué este trimestre.
• El alcance y la fecha, explícitos. Son lo que da valor probatorio al documento y lo que impide que se use dos años después como si siguiera vigente.

A esto se suma la sesión de presentación de resultados, que en España se da por supuesta y en algunas ofertas no está: una reunión donde se explican los hallazgos y se responden preguntas. La nuestra se hace por videollamada y en español.

La prueba del algodón antes de firmar con cualquiera es pedir un informe de ejemplo anonimizado y mirar una sola cosa: la prueba de concepto asociada a un hallazgo serio. Está o no está. El resto de la conversación depende de eso, y lo hemos desarrollado pregunta a pregunta en cómo elegir una empresa de pentesting.

Lo que un pentest no hace

Esta es la sección por la que existe la página, y la que casi nunca aparece en una oferta comercial. Un pentest es una herramienta excelente dentro de sus límites, y cara fuera de ellos.

1. No demuestra que no haya vulnerabilidades.

Demuestra qué se encontró en un alcance concreto, con unas jornadas concretas y en una fecha concreta. La ausencia de hallazgos graves es una buena noticia sobre esas condiciones, no un certificado de ausencia de fallos. Cualquier proveedor que te venda lo segundo te está vendiendo algo que no existe.

2. No es una certificación ni un sello.

La certificación la expide un organismo de certificación acreditado; un informe técnico es la evidencia que se presenta ante él. Esto vale para la ISO 27001, donde el trabajo alimenta los controles A.8.8 y A.8.29 pero no los certifica —lo explicamos en pentesting para ISO 27001—, y vale igualmente para el Esquema Nacional de Seguridad, donde la auditoría del art. 31 y la conformidad del art. 38 tienen su propia vía y sus propios actores. Quién puede hacer cada cosa está en quién puede auditar el ENS.

3. Es una foto con fecha, no una garantía continua.

Cada día se publican vulnerabilidades nuevas. Un sistema sano el martes puede tener un fallo crítico el miércoles sin que nadie haya tocado una línea de código. Por eso el pentest anual convive con un análisis de vulnerabilidades recurrente y no lo sustituye: uno es profundidad de ciclo largo, el otro es higiene de ciclo corto.

4. No mide tu capacidad de detección y respuesta.

En un pentest tu equipo sabe que hay una prueba en marcha, y las reglas de enfrentamiento a menudo piden expresamente que no se bloquee al equipo que prueba para no desperdiciar jornadas. Eso significa que el ejercicio no responde a «¿nos habríamos dado cuenta?». Esa pregunta la responde un ejercicio de Red Team, que es otro producto, con otro presupuesto y otro calendario.

5. No cubre lo que quedó fuera del alcance.

Parece obvio y es la causa número uno de decepción. Si el alcance eran dos aplicaciones y la intrusión real llega un año después por un servidor de pruebas que nadie incluyó, el informe no falló: el alcance falló. Revisa las exclusiones con la misma atención que el precio.

6. No corrige nada por sí solo.

El informe es el principio del trabajo, no el final. Si nadie de tu lado se hace cargo de los hallazgos, con responsable y fecha, lo que has comprado es un documento caro que además deja constancia de que estabas al tanto. La concienciación de la plantilla, el parcheo y la gestión de vulnerabilidades siguen siendo trabajo tuyo, y el pentest no los reemplaza.

Dicho todo esto, hay una expectativa que sí puedes tener y que se cumple siempre: después de un pentest bien hecho sabes, con nombres y pasos, qué es lo peor que le puede pasar hoy a tu organización por la vía técnica. Ninguna otra compra de seguridad te da eso.

¿Quién puede hacer un pentest en España?

Ninguna norma española reserva el test de intrusión a una profesión regulada ni exige un registro para prestarlo. La Ley 5/2014, de Seguridad Privada, no incluye la seguridad informática entre las actividades reservadas de su art. 5.1, de modo que no hace falta autorización del Ministerio del Interior ni inscripción en ningún registro de seguridad privada para hacer este trabajo. Lo que hace lícito el encargo es la autorización escrita del titular del sistema.

Tampoco existe un registro habilitante de empresas de ciberseguridad. El Catálogo de INCIBE es un directorio de proveedores, y el propio INCIBE advierte de que figurar en él no equivale a una certificación ni a una acreditación. Que un proveedor esté o no en ese listado no dice nada sobre la calidad de su trabajo.

Hay dos ámbitos donde sí existe una puerta estrecha, y conviene nombrarlos para no confundirlos con el caso general: la certificación de conformidad con el ENS, que corresponde a entidades de certificación acreditadas por ENAC, y las pruebas dirigidas por amenazas del sector financiero, con su propio marco de proveedores. Ni una ni otra son la contratación ordinaria de un pentest por una empresa privada. Y tampoco hay ninguna norma que obligue a que tu proveedor esté establecido en España: la cuestión, con los textos delante, está en contratar una empresa de pentesting no española.

Así que el examen del proveedor te corresponde a ti, y se hace con preguntas comprobables: quién en concreto va a ejecutar el trabajo y con qué certificaciones individuales, qué metodología se seguirá y por su nombre, un informe de ejemplo anonimizado antes de firmar, qué pasa con las evidencias recogidas y bajo qué contrato de encargado de tratamiento, y si la contraauditoría entra en el precio.

Qué dicen las normas, sin exagerar

El mercado español tiene un problema de tono en este punto: se vende miedo regulatorio más a menudo de lo que se citan los textos. Aquí van los textos.

RGPD, art. 32.1.d). Es la disposición europea que más se acerca a nombrar este trabajo. Obliga al responsable y al encargado del tratamiento a aplicar medidas apropiadas al riesgo, incluyendo, «en su caso», la siguiente:

«un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento»

No dice «pentest» ni fija ninguna frecuencia. Dice tres cosas que sí importan: que hace falta un proceso, no un informe suelto; que sea regular, con una periodicidad que te toca a ti justificar por escrito; y que se mida la eficacia de las medidas, que es justo lo que una exportación de herramienta no mide. Es el texto que lee la Agencia Española de Protección de Datos cuando examina la seguridad de un tratamiento después de una brecha.

Esquema Nacional de Seguridad, Real Decreto 311/2022. Nombra las pruebas dentro del refuerzo R6 de la medida op.mon.3 del Anexo II, junto a la verificación de configuración y al análisis de vulnerabilidades, y ese refuerzo entra por la cláusula de aplicación de la categoría ALTA. El decreto no fija frecuencia: dice «periódicamente» y añade un disparador, los incidentes que revelen vulnerabilidades nuevas o subestimadas. Qué exige exactamente y qué no, con el articulado delante, está en qué exige realmente el ENS sobre pentesting.

Reglamento de Ejecución (UE) 2024/2690. Es directamente aplicable desde el 18 de octubre de 2024 a un grupo cerrado de entidades de infraestructura digital y servicios gestionados, y contiene la respuesta más sensata que ha dado hasta ahora una norma a la pregunta de la frecuencia: el punto 6.5.2 de su anexo exige determinar la necesidad, el alcance, la frecuencia y el tipo de prueba a partir del análisis de riesgos, ejecutarla con metodología documentada y dejar registro de tipo, alcance, fecha y resultados. Traducido: la pregunta correcta no es «¿qué es obligatorio?», sino «¿qué riesgo tengo y qué prueba lo mide?».

NIS2. A 12 de septiembre de 2026, la Directiva (UE) 2022/2555 no está transpuesta al derecho español, y el régimen operativo sigue siendo el Real Decreto-ley 12/2018 con el Real Decreto 43/2021. Qué obliga hoy, qué no y qué conviene ir preparando lo tratamos en NIS2 en España: qué obliga hoy y qué no, y la preparación técnica, en pentesting para NIS2.

ISO 27001. Los controles A.8.8, sobre gestión de vulnerabilidades técnicas, y A.8.29, sobre pruebas de seguridad en desarrollo y aceptación, esperan cosas distintas: el primero, un dispositivo documentado con seguimiento; el segundo, pruebas y no inventarios. Cómo encajan los dos con NIS2 está en ISO 27001 y NIS2.

La conclusión honesta es esta: en la mayoría de las organizaciones españolas la obligación de hacer un pentest no llega por una ley, llega por un contrato. Un cliente grande que exige el informe antes de firmar, un pliego que lo pide, una entidad certificadora que lo espera como evidencia, una aseguradora que lo valora. Esa es la presión real, y es suficiente.

Cuánto cuesta y cada cuánto se repite

El precio se calcula en jornadas de trabajo multiplicadas por una tarifa diaria, sin IVA, y no en una lista de precios por producto. Las jornadas dependen del alcance: cuántas aplicaciones, cuántos roles, qué profundidad, si hay acceso al código, si entra la contraauditoría.

Como referencia de orden de magnitud: una aplicación web de tamaño medio suele cubrirse en un rango de cinco a diez jornadas, y las tarifas publicadas en el mercado español se mueven en una horquilla amplia. Nuestra tarifa por jornada está en la mitad baja de esa horquilla, del orden de 800 a 1.000 € sin IVA, y no es una promoción: somos un proveedor europeo sin una estructura comercial en España que financiar, y eso se nota en la tarifa, no en las jornadas. Las horquillas del mercado y cómo leer un presupuesto línea a línea están en cuánto cuesta un pentest en España.

Quien te dé una cifra antes de conocer el alcance está adivinando, o está presupuestando una pasada automatizada.

Sobre la cadencia, el esquema que aguanta bien una revisión externa es sencillo:

1. Análisis de vulnerabilidades recurrente sobre lo expuesto a internet, con una pasada extra tras cada cambio relevante.
2. Un pentest al año sobre lo que sostiene el negocio.
3. Un pentest adicional tras cada cambio mayor: una aplicación nueva, una migración, un cambio en la arquitectura de autenticación, una integración nueva con un tercero.
4. Contraauditoría después de cada corrección, porque es lo que documenta la solución y no el problema.
5. Una revisión anual de la propia decisión, que es literalmente lo que pide el punto 6.5.3 del anexo del Reglamento (UE) 2024/2690 a las entidades que alcanza, y buena práctica para todas las demás.

Si es tu primer pentest: seis decisiones por orden

1. Decide qué quieres demostrar. «Que el portal de clientes aguanta» y «que cumplimos con lo que nos pide el cliente X» llevan a alcances distintos y a informes distintos.
2. Escribe el alcance antes de pedir precio. Aplicaciones, entornos, roles, integraciones, exclusiones. Cuatro líneas honestas valen más que un formulario largo.
3. Elige el enfoque. Caja gris con cuentas de todos los roles es la respuesta correcta en la mayoría de los casos.
4. Cierra las reglas de enfrentamiento. Ventana, franjas vetadas, contacto de emergencia, qué se hace si aparece un compromiso real.
5. Prepara a tu equipo. Alguien que pueda dar acceso el primer día y responder dudas durante la semana ahorra jornadas enteras.
6. Planifica la corrección antes del informe. Reserva capacidad de desarrollo y sistemas para las semanas posteriores. Un informe que llega a un equipo sin tiempo para actuar es un informe que envejece en una carpeta.

Y una recomendación que ahorra dinero de verdad: si nunca has hecho nada, no empieces por el ejercicio más ambicioso. Un análisis de vulnerabilidades sobre lo expuesto suele despejar el ruido barato, y el pentest posterior se dedica entonces a lo que ninguna herramienta puede ver. Si lo que tienes delante es una auditoría con fecha, el orden cambia y la lista de deberes previos está en cómo prepararse para una auditoría de ciberseguridad.

Preguntas frecuentes

Por dónde empezar

Si ya sabes qué quieres probar, la página de test de intrusión describe cómo trabajamos, qué entra en el precio y qué recibes al final. Si todavía no lo tienes claro, describe el alcance en cuatro líneas y solicita presupuesto: cerramos el alcance contigo antes de dar una cifra, y te decimos si lo que necesitas hoy es algo más barato.

Nuestros servicios relacionados: pentesting y tests de intrusión de tus aplicaciones e infraestructuras · pentesting de aplicaciones web y API · auditoría de infraestructura con tests de intrusión externos e internos · análisis de vulnerabilidades de tus sistemas y aplicaciones