Las necesarias hacen funcionar el sitio. Las demás miden qué páginas ayudan y qué anuncios traen a quien necesita a DM11. Tú eliges, y puedes revisarlo desde el pie de página.
PENTEST
Un pentest, o prueba de intrusión, es un ataque autorizado y acordado contra tus sistemas, conducido por quien lo hace profesionalmente. No devuelve una lista de fallos posibles: devuelve la demostración de lo que un intruso conseguiría hacer de verdad, con el camino recorrido, la evidencia de cada paso y lo que resistió. Es la diferencia entre saber que la puerta puede estar abierta y ver a alguien entrar por ella.
Ninguna prueba empieza sin autorización formal, alcance escrito y reglas de enfrentamiento firmadas. Eso no es papeleo: es lo que separa una prueba de intrusión de un acceso no autorizado, y lo que protege a ambas partes cuando algo se sale del guion. La DM11 conduce el trabajo con las fases del PTES declaradas en contrato, cobertura de aplicación por OWASP y el camino descrito en el lenguaje de MITRE ATT&CK.
Quién conduce la prueba
CEH, hacker ético certificado por EC-Council
CPTE, ingeniería de pruebas de intrusión por AcadiTI
SYCP y SYWP, pentest y pentest de aplicación web por Solyd
17 años de gobernanza, riesgos y cumplimiento
QUÉ ES
Un pentest lo conduce una persona, con herramientas que ayudan, y no una herramienta con una persona mirando. Ese orden explica casi todo lo que viene después: el precio, el plazo, lo que el informe puede afirmar y por qué dos propuestas con el mismo nombre entregan trabajos que no se pueden comparar. Lo que se compra es la pericia de quien encadena fallos pequeños hasta llegar a algo que importa, y no la cantidad de hallazgos.
Un análisis de vulnerabilidades encuentra y lista fallos conocidos, de forma amplia y sobre todo automática, y es trabajo de rutina que debe correr todo el año. Un pentest confirma lo que se puede explotar de verdad y mide hasta dónde se podría llegar después de la primera puerta. Si el informe que recibiste tiene decenas de páginas de hallazgos clasificados por color y ni una frase sobre lo que alguien consiguió hacer con ellos, compraste un pentest y recibiste un escaneo con otro nombre. Los dos se complementan, y la comparación entera está en la página de pentest y análisis de vulnerabilidades.
Sin autorización formal del responsable del activo, el mismo conjunto de acciones es acceso no autorizado. Por eso el trabajo empieza con un documento que define qué está dentro del alcance, qué está fuera, quién autoriza, en qué ventana, con qué criterio de parada y a quién se avisa si algo se sale del guion. Cuando hay terceros por medio, proveedor de nube, proveedor de acceso o la empresa que opera tu seguridad, el tratamiento de cada uno queda escrito antes del primer paquete.
La DM11 usa el PTES para la estructura de ejecución, de las interacciones previas al informe, el OWASP para la cobertura de aplicación, con el Top 10 y el ASVS, y el MITRE ATT&CK para nombrar el camino recorrido. Los tres resuelven cosas distintas y ninguno sustituye al otro. Un efecto práctico es que tu equipo de infraestructura puede comprobar después si la detección habría visto ese camino, lo que convierte el informe en insumo de mejora y no solo en documento de auditoría.
No existe certificado de pentest, ni aquí ni en ningún sitio, y conviene desconfiar de quien ofrezca uno. Lo que existe es un informe en dos capas, resumen ejecutivo para la dirección e informe técnico con evidencia, reproducción y corrección por hallazgo, más el registro de la nueva prueba de lo corregido. Ese conjunto es lo que va a la auditoría, al cliente que lo pidió y al regulador. Cuando alguien necesita un documento emitido por un tercero acreditado, quien responde es la ISO 27001 o el SOC 2, y este informe entra entero en esas auditorías como evidencia.
CUÁNDO TIENE SENTIDO
En dos de ellos la exigencia viene de fuera y tiene plazo. En el tercero viene de dentro, y suele ser el que produce el resultado más útil.
El PCI DSS exige metodología documentada y prueba anual a quien procesa tarjetas. Las resoluciones de seguridad cibernética del Banco Central de Brasil exigen prueba de intrusión con periodicidad mínima anual, conducida con independencia e imparcialidad por un especialista contratado para esa finalidad. Un cliente grande en due diligence y una auditoría de certificación piden lo mismo en otro formato. En esos casos el informe sale de tu empresa y lo va a leer quien no participó en la prueba.
Una aplicación nueva que expone datos de cliente, una migración a la nube, una integración con un socio que pasó a acceder a tu entorno, una fusión que juntó dos redes que nadie conoce enteras. Aquí el valor no está en encontrar muchos fallos, está en descubrir pronto qué camino nuevo abrió un cambio que todo el mundo aprobó mirando otra cosa.
Es el motivo menos común y el que suele rendir más. Después de comprar protección de puesto, filtro de correo y monitorización, la única forma de saber qué frenan es que alguien intente pasar. La conversación cambia cuando el informe muestra qué bloqueó la defensa, qué solo registró y qué ignoró, porque entonces la siguiente decisión de inversión se toma con datos y no con el folleto del fabricante.
TRADUCIENDO LA PETICIÓN
Contar direcciones no describe el esfuerzo. Estas son las cuatro formas en que suele llegar la petición, con lo que significa cada una y lo que realmente mueve el tamaño del trabajo.
| Qué pidieron | Qué significa realmente | Qué cambia el tamaño |
|---|---|---|
| Necesitamos un pentest de nuestra infraestructura | Prueba de lo expuesto y de lo que hay detrás, con explotación y post-explotación. Es el formato que responde a la exigencia regulatoria y a la due diligence. | Cuántos servicios distintos existen de hecho, y no cuántas direcciones. Un rango grande con servicios repetidos avanza rápido; un entorno heterogéneo, no. |
| Queremos probar nuestra aplicación | Prueba de aplicación con cobertura por OWASP, incluida la lógica de negocio y el control de acceso entre perfiles, que es donde suelen estar los fallos caros. | Cantidad de perfiles de usuario, complejidad de la lógica de negocio, integraciones con terceros y si hay acceso a documentación o al código. |
| El cliente pidió evidencia de prueba anual | Lo que va a leer un tercero es el informe. Necesita alcance, método, fechas, cualificación de quien la ejecutó, hallazgos con evidencia y comprobación de la nueva prueba. | El alcance que acepta quien lo exige, que rara vez es el entorno entero, y si la nueva prueba debe estar concluida dentro del mismo ciclo. |
| Queremos saber si nuestra defensa funciona | El foco sale de la lista de fallos y va a la cobertura de detección: qué bloqueó la defensa, qué solo registró y qué pasó sin dejar rastro. | Si habrá ventana con el bloqueo activo, ventana con el probador habilitado de forma controlada, o las dos, que es lo que separa una buena noticia de una noticia útil. |
La conversación de alcance ocurre antes de la propuesta, y la DM11 ayuda a escribir ese requisito incluso cuando la demanda va a salir al mercado. Sirve para comparar proveedores por trabajo en lugar de por precio.
HISTORIAS
Cambiamos los nombres de los clientes con el mismo sigilo que va a proteger a tu empresa después. Los nombres cambian, el patrón de los problemas se repite. Cuando el cliente lo autoriza, mostramos referencias con nombre en una conversación.
Plataforma digital
La petición llegó como prueba de una aplicación web, con el número de pantallas en la propuesta. La aplicación tenía varios perfiles de usuario, incluido un perfil administrativo usado por socios externos, y ninguna prueba anterior había mirado qué conseguía hacer un perfil con el identificador de otro. El alcance, tal como estaba escrito, no obligaba a nadie a mirar eso.
Reescribimos el requisito de alcance antes de la propuesta, cambiando el recuento de pantallas por una matriz de perfiles: qué debería poder ver cada uno y qué debería rechazarse. La cobertura siguió el OWASP, con el requisito verificado punto por punto, y la explotación siguió hacia la post-explotación para medir el alcance desde cada perfil.
Los fallos más graves no estaban en las pantallas que listaba la petición, sino en la frontera entre dos perfiles, que ningún recuento de pantallas habría alcanzado. El alcance escrito de esa forma se convirtió en la plantilla de las contrataciones siguientes de la empresa.
Comercio minorista
Después de mover parte del entorno a la nube, la empresa mantuvo la rutina de escaneo y dio el asunto por resuelto. La migración se había aprobado por arquitectura, por coste y por disponibilidad. Nadie había preguntado qué quedó alcanzable desde fuera que antes no lo estaba, porque esa pregunta no pertenecía a ninguna de las tres aprobaciones.
Acordamos en las reglas de enfrentamiento el tratamiento del proveedor de nube y la ventana, que es la parte que más retrasa este tipo de prueba. El reconocimiento partió de lo que quedó expuesto después de la migración, y las hipótesis de ataque se ligaron a lo que el negocio no podía perder, y no a lo que era más fácil de probar.
El camino encontrado empezaba en un servicio que existía desde antes y que la migración pasó a exponer. La corrección fue de configuración y salió rápido; lo que quedó fue el cambio de proceso, con la prueba pasando a ser disparador de migración y no un elemento anual suelto en el calendario.
Servicios B2B
La exigencia venía en el contrato: prueba de intrusión anual, con evidencia. La empresa presupuestó el entorno entero, la cifra asustó, y la discusión se convirtió en descuento. Nadie había preguntado al cliente qué alcance aceptaba, y la suposición era que quería todo.
Ayudamos a escribir la pregunta que faltaba y a llevarla al cliente por escrito, junto con lo que traería el informe: alcance, método, fechas, cualificación de quien ejecuta, hallazgos con evidencia y comprobación de la nueva prueba. Con la respuesta, el alcance se diseñó sobre lo que quien lo exige de verdad lee, y la nueva prueba entró en el mismo ciclo en lugar de quedar para después.
El trabajo quedó del tamaño de la exigencia real, y no del tamaño del miedo. Y la empresa tuvo, desde el primer ciclo, el documento que el cliente pedía, con la nueva prueba concluida dentro del plazo del contrato.
CÓMO LO CONDUCIMOS
Cada fase termina con algo que puedes comprobar sin depender de nuestra palabra. Ese es el sentido del método declarado: un informe que otro profesional puede auditar vale más que uno que solo entiende quien lo escribió.
La fase que el comprador más ignora y la que más protege a ambas partes. Queda escrito qué está dentro y qué está fuera, el enfoque, las ventanas, el criterio de parada inmediata, el tratamiento de terceros como proveedor de nube y proveedor de acceso, y si está autorizada cualquier prueba que pueda afectar a la disponibilidad. La autorización formal y los contactos de emergencia se registran antes del primer paquete.
Alcance escrito, con lo que está dentro y lo que está fuera
Reglas de enfrentamiento, ventanas y criterio de parada
Autorización formal para probar y contactos de emergencia
Tratamiento acordado para nube, proveedor de acceso y demás terceros
Hito de entregaAlcance y autorización firmados, sin ningún punto de alcance abierto.
Levantamos lo que existe y lo que el mundo ya sabe de tu empresa, y lo convertimos en hipótesis de ataque ligadas a lo que tu negocio no puede perder. Sin esta fase la prueba se vuelve una búsqueda de fallos sueltos, y el resultado es una lista sin prioridad que nadie sabe usar. Las hipótesis se validan con tu equipo antes de cualquier explotación.
Superficie levantada, separando lo expuesto de lo interno
Información pública sobre la empresa, cuando está en el alcance
Hipótesis de ataque ligadas a lo que el negocio no puede perder
Objetivos priorizados y acordados contigo antes de la explotación
Hito de entregaHipótesis validadas con tu equipo, con prioridad acordada por escrito.
Confirmamos en la práctica lo que se puede explotar, que es la diferencia entre sospecha y hecho, y seguimos para medir hasta dónde se podría llegar después de la primera puerta. La post-explotación es la fase que más falta en las propuestas baratas y la que más cambia una decisión de inversión. En aplicación, la cobertura sigue el OWASP, con el Top 10 y el ASVS. El hallazgo crítico se comunica el mismo día, sin esperar al informe.
Confirmación por explotación, con evidencia de lo obtenido
Alcance real demostrado, con el camino encadenado
Cobertura de aplicación por OWASP, con el requisito verificado punto por punto
Comunicación inmediata del hallazgo crítico, con recomendación inicial
Hito de entregaEl fallo crítico se comunica el mismo día en que se confirma.
El informe sale en las dos capas que el propio PTES define, resumen ejecutivo e informe técnico, con el camino recorrido descrito en el lenguaje de MITRE ATT&CK para que tu equipo compruebe la detección y no solo la corrección. Después de la corrección, repetimos la prueba de lo corregido y registramos el resultado, que es el documento que la auditoría suele pedir junto al informe.
Resumen ejecutivo para la dirección, sin jerga
Informe técnico con evidencia, reproducción y corrección por hallazgo
Camino recorrido nombrado por táctica y técnica de MITRE ATT&CK
Nueva prueba de lo corregido, con el resultado registrado
Hito de entregaCada hallazgo cerrado o aceptado por escrito, con la nueva prueba registrada.
CUÁNTO TARDA
No publicamos plazos estándar porque un plazo publicado se convierte en promesa y el alcance de una prueba de intrusión varía mucho. La primera conversación ya muestra en cuál de estos factores está tu empresa, y es ella la que produce el requisito de alcance.
Un rango grande con servicios repetidos avanza rápido. Una sola aplicación con muchos perfiles de usuario, lógica de negocio compleja e integración con terceros consume mucho más. La conversación de alcance separa los dos casos, y ocurre antes de la propuesta.
Sin información, buena parte del tiempo se va en el reconocimiento, y el resultado se parece a lo que enfrentaría un atacante externo. Con acceso a documentación o al código, ese mismo tiempo se gasta buscando fallos en lugar de buscando puertas. Las dos opciones son legítimas, entregan cosas distintas, y la decisión queda registrada en el alcance.
Un entorno que solo se puede probar fuera del horario comercial, un sistema con pico estacional, una autorización pendiente del proveedor de nube y el aviso previo al proveedor de seguridad gestionada mueven el calendario más que la parte técnica. Esa conversación empieza pronto, porque suele ser la más lenta del proyecto entero.
PREGUNTAS FRECUENTES
Las dudas que aparecen en casi toda primera reunión, respondidas sin rodeos.
El análisis de vulnerabilidades es amplio y sobre todo automático: encuentra y lista fallos conocidos por gravedad, y sirve como rutina a lo largo del año. El pentest es profundo y sobre todo manual: un especialista intenta explotar los fallos para probar lo que un atacante conseguiría hacer, y mide hasta dónde llegaría después de la primera puerta. Uno responde qué puede estar mal; el otro responde qué se puede hacer de verdad. Se complementan, y varias exigencias piden ambos: el PCI DSS, por ejemplo, exige escaneo trimestral y prueba anual.
Hay que hacerlo, y sin eso no empezamos. Sin autorización formal del responsable del activo, el mismo conjunto de acciones deja de ser prueba y pasa a ser acceso no autorizado. El documento define qué está dentro y fuera del alcance, quién autoriza, la ventana de ejecución, el criterio de parada inmediata, si está permitida cualquier prueba que afecte a la disponibilidad, y a quién se avisa si algo se sale del guion. Cuando hay terceros por medio, como proveedor de nube, proveedor de acceso o la empresa que opera tu seguridad, el tratamiento de cada uno también queda escrito antes.
Puede, si nadie lo acuerda antes, y por eso existe la primera fase. En las reglas de enfrentamiento queda escrito si está autorizada cualquier prueba que afecte a la disponibilidad, qué sistemas quedan fuera, en qué ventana ocurre el trabajo, a quién se avisa si algo se sale del guion y cuál es el criterio de parada inmediata. Con eso registrado, el riesgo de indisponibilidad deja de ser suerte y pasa a ser decisión tuya, tomada con información y antes de empezar.
No existe, ni para tu empresa ni para el informe, y conviene desconfiar de quien ofrezca uno. Lo que existe es el informe con método declarado, y son las personas que conducen la prueba las que tienen certificación, como CEH, CPTE y las rutas de pentest de Solyd. Cuando tu cliente o tu auditor necesita un documento emitido por un tercero acreditado, quien responde a eso es la ISO 27001 o el SOC 2, y el informe de la prueba entra entero en esas auditorías como evidencia.
Está, y es un entregable declarado en contrato, no una cortesía. Después de que tu equipo corrige, repetimos la prueba de lo corregido y registramos el resultado por hallazgo, cerrado o aceptado por escrito. Ese registro lo pide la auditoría tanto como el propio informe, porque es el que muestra que la lista no se quedó parada. Si tu plazo de corrección es largo, eso entra en el alcance desde el principio en lugar de convertirse en discusión después.
Pide a cada proveedor que declare, fase a fase, qué va a hacer. Cinco preguntas separan casi todo: qué fases están incluidas, si la post-explotación forma parte o el trabajo termina en la confirmación del fallo, si hay nueva prueba y en qué plazo, quién ejecuta y con qué cualificación, y qué contendrá exactamente el informe. Donde la propuesta dice solo pentest de un número de direcciones, no hay nada que comparar, y la diferencia de precio seguirá sin explicación. La DM11 ayuda a escribir ese requisito incluso cuando tu empresa va a llevar la demanda al mercado.
Depende de quién lo exija y de lo que cambie en tu entorno. El PCI DSS exige prueba anual a quien procesa tarjetas, y las resoluciones de seguridad cibernética del Banco Central de Brasil exigen periodicidad mínima anual con independencia de quien la ejecuta. Fuera de una exigencia formal, la regla práctica es anual, más una prueba siempre que cambie algo relevante: aplicación nueva expuesta, migración de entorno, integración que abrió acceso a un socio. Entre una prueba y otra, quien cubre el año es la gestión de vulnerabilidades, que es trabajo de rutina y no sustituye la prueba.
Sí, y es un trabajo con otro alcance, no una extensión de la prueba tradicional. Un sistema de IA se ataca por caminos que una aplicación común no tiene: manipulación de la entrada para cambiar el comportamiento del modelo, extracción de lo que aprendió, envenenamiento del dato que lo alimenta. La referencia que cataloga esas técnicas es MITRE ATLAS, y no ATT&CK. Si tu caso implica un modelo en producción delante del cliente, la conversación empieza por ahí y suele venir junto con la gobernanza de IA.
Una conversación corta ya produce el requisito fase a fase que tu empresa puede llevar al mercado. Sirve para comparar proveedores con criterio, y sirve para contratarnos sabiendo exactamente qué recibes en cada etapa.
Comparativas sobre este tema
Ver las 13 comparativasPTES · versão 1.0; a edição mais recente do wiki é de dezembro de 2015 · consultado el
OWASP Foundation · edição 2025, primeira revisão desde 2021 · consultado el
OWASP Foundation · ASVS 5.0 · consultado el
The MITRE Corporation · v19.1, publicada em 28/04/2026 · consultado el
Esta página es informativa y describe cómo la DM11 lee y aplica las fuentes anteriores. No reproduce el texto de las normas, no sustituye la lectura del documento oficial y no sustituye una auditoría, una certificación, una evaluación independiente ni el asesoramiento jurídico. Donde la norma exige evaluación formal, quien la conduce es un organismo, auditoría o evaluador acreditado, siempre separado de quien preparó.