La pregunta llega casi siempre de la misma forma a la mesa del CISO, del DPO o del gerente de TI. ¿Vale la pena contratar un pentest puntual o migrar a un modelo continuo, en el formato Pentest as a Service — PTaaS? La respuesta no está en el producto, está en el contexto de la operación. Un pentest puntual atiende muy bien escenarios en los que el objetivo es evaluar un sistema en un momento específico, generar evidencia formal para auditoría o validar una entrega. El PTaaS atiende escenarios en los que el sistema está en evolución constante y la seguridad necesita acompañar esa evolución semana a semana.
Este artículo describe cómo está estructurada cada una de las dos modalidades, qué incluye cada una, en qué situaciones tiene sentido cada formato y cómo decidir entre ellos.
Las descripciones a continuación reflejan las metodologías que aplicamos. Otros proveedores estructuran alcance, cadencia, entregables y prerrequisitos de forma diferente, y esa variación importa en la comparación de propuestas. Al evaluar una contratación, verifique en cada caso el estándar técnico adoptado, qué está incluido en el alcance, cómo se trata la reprueba y qué evidencia documental se genera al final.
Cómo funciona el pentest puntual
El pentest puntual es una evaluación ofensiva conducida en un intervalo definido, sobre un alcance acordado previamente. La prueba tiene inicio, medio y fin, y al final se entrega un informe técnico con las vulnerabilidades identificadas, evidencias de explotación, clasificación de criticidad y recomendaciones de corrección.
Una evaluación bien ejecutada va más allá del uso de herramientas automatizadas. Los objetivos se prueban manualmente, con desarrollo de herramientas personalizadas cuando el contexto lo exige, garantizando un análisis preciso de cada funcionalidad del sistema evaluado. El alcance incluye no solo las vulnerabilidades conocidas catalogadas en bases públicas, sino también fallas específicas del contexto del sistema, incluyendo lógica de negocio y configuraciones inseguras.
Lea también: Pentest: qué es, para qué sirve y por qué es esencial para la seguridad de su negocio.
Modalidades de ejecución
El pentest puntual suele ejecutarse en una de tres modalidades, elegidas según el objetivo de la evaluación.
Black-box. El equipo de prueba recibe información mínima, como dirección de acceso o enlace de la aplicación, y no hay acceso al código fuente ni interacción con el equipo de desarrollo. Es la modalidad que simula la perspectiva de un atacante externo sin conocimiento previo.
Gray-box. El equipo recibe información adicional, como detalles sobre el sistema y credenciales de usuario, pero sin acceso al código fuente. Equilibra realismo y eficiencia, permitiendo una cobertura razonable cuando hay limitación de tiempo o presupuesto.
White-box. El equipo recibe toda la información relevante, incluyendo código fuente, documentación de APIs y arquitectura, con interacción directa con el equipo de desarrollo. Es la modalidad más eficaz y eficiente para identificar vulnerabilidades, incluyendo fallas de lógica de negocio que difícilmente aparecerían en pruebas cerradas.
Cuándo contratar pentest puntual
El pentest puntual es la elección adecuada cuando:
- La empresa necesita evidencia formal fechada para auditorías, exigencias regulatorias (LGPD, PCI DSS, ISO 27001, Resolución CMN 4.893/2021, Resolución BCB 85/2021) o procesos de due diligence;
- Un sistema nuevo está por entrar en producción y necesita evaluación antes del go-live;
- Hubo un cambio significativo en una aplicación, infraestructura o integración y es necesario validar el impacto en la postura de seguridad;
- El sistema evaluado tiene un ciclo de cambio lento y no justifica acompañamiento continuo;
- La organización todavía está estructurando su programa de pruebas y necesita una línea de base antes de evaluar formatos más complejos.
La periodicidad recomendada es, como mínimo, anual, o tras cambios significativos en el entorno. En engagements bien estructurados, las vulnerabilidades críticas identificadas durante la prueba se comunican inmediatamente al equipo técnico del cliente, incluso antes del informe final, para que las correcciones de emergencia puedan iniciarse en paralelo. Tras las correcciones, la reprueba debe estar prevista en el alcance.
Cómo funciona el PTaaS (Pentest as a Service)
El PTaaS es una modalidad continua de pruebas de seguridad integrada al ciclo de desarrollo del cliente. A diferencia del pentest puntual, el PTaaS presupone acompañamiento sistemático y tiene por objetivo mantener y elevar progresivamente el nivel de seguridad a lo largo del tiempo, y no solo evaluar la postura en un momento específico.
No hay estandarización de mercado para la composición de un PTaaS, y la definición varía bastante entre proveedores. En el modelo que practicamos, el servicio comprende tres actividades continuas, prestadas de forma regular a lo largo de la vigencia del contrato.
Threat Modeling
Modelados de amenazas accionados por el cliente, orientados a identificar y mitigar fragilidades originadas en las decisiones de diseño y arquitectura de los sistemas, en su totalidad o en parte. El cliente cuenta con horas mensuales reservadas para accionar la consultoría sobre nuevos proyectos en desarrollo. El Threat Modeling permite que los riesgos se aborden todavía en la fase de diseño, antes de la implementación.
Pentest Continuo
Pruebas de intrusión en ciclos cortos, típicamente de una semana, sobre los incrementos entregados por el equipo del cliente. Cada ejecución verifica la seguridad de la implementación realizada y puede demandar la inserción de actividades en los backlogs para la corrección de las vulnerabilidades identificadas. Las pruebas se apoyan en el acceso directo a los repositorios de código del cliente, lo que permite la ejecución en modalidad white-box y la correlación directa entre vulnerabilidades observadas en runtime y los puntos exactos del código donde residen.
Esa correlación es lo que diferencia el pentest continuo apoyado en código de los modelos cerrados de prueba. Cuando se identifica una vulnerabilidad, el equipo de desarrollo recibe no solo la descripción del problema, sino la indicación directa del fragmento de código donde reside la falla, reduciendo significativamente el tiempo de remediación.
Validación de correcciones
Tras la aplicación de correcciones por el cliente, se realizan repruebas para verificar la efectividad de las medidas adoptadas. La validación está incluida en el servicio dentro del límite de horas semanales, sin necesidad de nuevos engagements en cada ciclo de remediación.
Estándar técnico aplicado
Las pruebas siguen la versión estable más reciente del OWASP Web Security Testing Guide (WSTG), complementada por la verificación de los ítems de las listas OWASP Top 10 y CWE Top 25 Most Dangerous Software Weaknesses en su versión vigente. Los ítems pueden considerarse no aplicables según las características del entorno, y pueden incluirse técnicas adicionales a criterio técnico o por solicitud del cliente.
Onboarding y ciclo de mantenimiento
El PTaaS se ejecuta en dos fases secuenciales.
La primera es el onboarding inicial, con el objetivo de establecer una línea de base de seguridad. Incluye el reconocimiento de la arquitectura, componentes y flujos de los sistemas en alcance, la configuración de los accesos a los repositorios y credenciales necesarias, Threat Modeling inicial y un pentest abarcador para el mapeo de las vulnerabilidades existentes. La duración del onboarding varía según la complejidad y el número de sistemas involucrados.
Concluido el onboarding, el servicio entra en régimen de mantenimiento continuo. Las actividades de Threat Modeling, Pentest y Validación de correcciones pasan a ocurrir en ciclos cortos, acompañando la evolución de los sistemas, con foco en identificar vulnerabilidades introducidas por nuevas funcionalidades y validar la efectividad de las correcciones aplicadas.
Escaneo de infraestructura
Como actividad opcional, suele ofrecerse el escaneo automatizado de infraestructura, con periodicidad anual o semestral, sin limitación de número de activos. Esta actividad corre en paralelo al núcleo del PTaaS, en ventanas de ejecución acordadas previamente.
Acceso a repositorios
El acceso de lectura a los repositorios de código fuente es un prerrequisito esencial del PTaaS. Es lo que viabiliza el pentest en modalidad white-box y la correlación entre vulnerabilidades y código. Las plataformas comúnmente soportadas incluyen GitHub, GitLab y Bitbucket. El acceso debe ser exclusivamente de lectura, sin posibilidad de commits, alteraciones o exclusiones. El código fuente se trata como información confidencial, sin almacenamiento permanente, sin compartición con terceros y sin uso para cualquier finalidad distinta de la ejecución de las actividades contratadas.
Cuándo contratar PTaaS
El PTaaS tiene sentido cuando:
- La empresa desarrolla software internamente y tiene ciclos de release frecuentes;
- La operación demanda acompañamiento de seguridad integrado al ciclo de desarrollo, y no evaluaciones aisladas;
- La organización necesita evidencia permanente y continua de gestión de vulnerabilidades para auditorías, due diligence o exigencias de clientes;
- Hay un equipo interno con capacidad de absorber hallazgos a lo largo del tiempo, aplicando correcciones y accionando repruebas;
- El liderazgo técnico busca no solo identificar vulnerabilidades, sino reducir progresivamente el tiempo entre la introducción y la detección de nuevas fallas.
La duración mínima del contrato es típicamente de doce meses. Esa duración es necesaria por la naturaleza del servicio, que exige onboarding inicial seguido de un ciclo continuo de mantenimiento para entregar valor consistente. Las contrataciones cortas no permiten que el servicio alcance el punto en el que se genera la mayor parte del valor, que es la fase de acompañamiento sistemático tras establecida la línea de base.
Pruebas de intrusión como exigencia regulatoria en el sector financiero
Desde diciembre de 2025, las normas de seguridad cibernética del Banco Central de Brasil tratan las pruebas de intrusión como control mínimo necesario a ser abordado por la Política de Seguridad Cibernética. La Resolución CMN 5.274, del 18/12/2025, modificó la Resolución CMN 4.893/2021, aplicable a las instituciones autorizadas a funcionar por el BCB. La Resolución BCB 538, de la misma fecha, modificó la Resolución BCB 85/2021, aplicable a instituciones de pago, sociedades corredoras y distribuidoras de títulos y valores mobiliarios y sociedades corredoras de cambio. Las modificaciones están reflejadas en ambos textos.
En ambas normas, la evaluación y la corrección de vulnerabilidades pasó a abarcar, como mínimo, pruebas de intrusión (art. 3º, § 2º, inciso VIII de la Resolución CMN 4.893). El nuevo art. 22-A de esta resolución determina que esas pruebas tengan periodicidad mínima anual, sean realizadas con independencia e imparcialidad por persona natural o empresa especializada contratada por la institución para esa finalidad, sin perjuicio de la realización de pruebas por equipos de la propia institución, y tengan los resultados de su ejecución documentados, especialmente las vulnerabilidades identificadas y los planes de acción establecidos para sus correcciones. Las instituciones en funcionamiento tenían hasta el 1º de marzo de 2026 para promover las adaptaciones necesarias.
Para quien está en el alcance de esas normas, el requisito incide directamente sobre la decisión de formato. Lo que la norma exige es una prueba anual, documentada y conducida con independencia e imparcialidad. Un contrato de PTaaS produce evidencia continua de gestión de vulnerabilidades y atiende bien la exigencia de pruebas y análisis periódicos, pero el cumplimiento del art. 22-A depende de cómo esté estructurado el engagement, de quién lo ejecuta y de cómo se consolidan los resultados en documentación fechada. Es un punto a verificar en el diseño del servicio, no a presumir por la contratación de un modelo continuo.
Nuestra evaluación aquí es técnica. El encuadramiento regulatorio aplicable a cada institución debe tratarse con su área de compliance o asesoría jurídica.
Las diferencias que importan en la práctica
Reducir el debate a "continuo vs. puntual" simplifica demasiado la decisión. Las distinciones que efectivamente orientan la elección son las siguientes.
Profundidad vs. cadencia
El pentest puntual permite una inmersión prolongada en un alcance definido. El equipo tiene tiempo para mapear lógica de negocio, encadenar vulnerabilidades, explorar caminos de escalamiento de privilegios e identificar fallas que dependen de análisis contextual. El PTaaS distribuye el esfuerzo a lo largo del tiempo, con ventanas más cortas y enfocadas en incrementos. Para sistemas que cambian poco, el puntual cubre más. Para sistemas que cambian cada semana, el continuo cubre lo que el puntual no consigue: las alteraciones entre una evaluación y otra.
Relación con el equipo de desarrollo
En el pentest puntual en modalidad white-box, la interacción con el equipo de desarrollo existe, pero es puntual y limitada al período de la prueba. En el PTaaS, esa interacción es continua, con Threat Modeling accionado en nuevos proyectos y Pentest Continuo acompañando incrementos. La consecuencia práctica es que el PTaaS funciona como una capa permanente de revisión de seguridad al lado del equipo de producto.
Tipo de evidencia generada
El pentest puntual genera un informe formal, fechado, con alcance y metodología documentados. Es la evidencia que auditores, reguladores y clientes corporativos esperan ver en procesos de due diligence. El PTaaS genera evidencia continua de gestión de vulnerabilidades, lo que atiende requisitos que demandan no solo la existencia de pruebas, sino la demostración de una práctica recurrente y documentada de monitoreo de seguridad.
Modelo contractual
El pentest puntual se contrata por proyecto, con alcance cerrado y plazo definido. El PTaaS se contrata por vigencia mínima de doce meses, con horas semanales asignadas y actividades distribuidas en ciclos. En empresas con pocos activos críticos y cambio lento, el puntual suele ser más eficiente. En empresas con desarrollo activo y múltiples releases, el PTaaS diluye el costo unitario por prueba y reduce el overhead de contratación recurrente.
Cómo decidir
Las preguntas a continuación suelen ser suficientes para orientar la elección.
- ¿Cuál es el disparador de la contratación? Si el objetivo es atender una exigencia regulatoria puntual, validar una entrega antes de producción o generar un informe formal para auditoría, el pentest puntual entrega el artefacto esperado. Si el objetivo es establecer una práctica continua de validación de seguridad en el ciclo de desarrollo, el PTaaS es el formato adecuado.
- ¿Con qué frecuencia cambian los activos críticos? Releases semanales o diarios justifican la discusión sobre PTaaS. Cambios anuales o semestrales raramente exigen prueba continua.
- ¿El equipo interno consigue absorber hallazgos continuamente? Sin capacidad de remediación ágil, el PTaaS se transforma en backlog acumulado. El pentest puntual, con volumen controlado por ventana, suele ser más realista para equipos que todavía están estructurando su proceso de gestión de vulnerabilidades.
- ¿Cuál es la expectativa respecto a la integración con desarrollo? Si el objetivo es tener seguridad presente desde el Threat Modeling de nuevos proyectos hasta la validación de cada incremento, el PTaaS entrega esa integración. Si el objetivo es una evaluación independiente en momentos definidos, el puntual atiende.
- ¿Existe horizonte para un contrato de doce meses? La duración mínima del PTaaS no es un detalle contractual, es una consecuencia técnica del servicio. Las empresas que no consiguen comprometer doce meses deben comenzar por el pentest puntual y estructurar el programa antes de migrar al modelo continuo.
Los dos modelos no son excluyentes
Pentest puntual y PTaaS no compiten entre sí. Atienden objetivos diferentes en momentos diferentes del programa de seguridad de la empresa. Las organizaciones maduras frecuentemente combinan los dos formatos: el PTaaS da ritmo al ciclo de validación de seguridad durante el desarrollo, y el pentest puntual entrega profundidad en momentos específicos, como auditorías regulatorias, lanzamientos de productos críticos o evaluaciones independientes solicitadas por clientes e inversores.
La pregunta correcta para un gestor de TI o un CISO no es "cuál modelo es mejor". Es "cuál combinación atiende la realidad operacional de la empresa, la exigencia regulatoria aplicable y la capacidad del equipo interno".
Para las empresas que todavía están estructurando el programa de pruebas, el punto de partida suele ser el pentest puntual en modalidad white-box, con periodicidad definida según la criticidad de los sistemas. Para las empresas con desarrollo activo y exigencia de demostración continua de gestión de seguridad, el PTaaS ofrece el formato adecuado para integrar seguridad al ciclo de producto.
BrownPipe actúa desde 2012 con pentest y protección de datos, ofreciendo tanto pentest puntual en las modalidades black-box, gray-box y white-box como PTaaS estructurado en Threat Modeling, Pentest Continuo y Validación de correcciones, siempre apoyados por el estándar OWASP. Si desea discutir el escenario específico de su operación y entender qué formato atiende mejor su contexto, póngase en contacto.