Qué incluye un pentest, cuánto cuesta y cómo elegir proveedor

El precio de un pentest en Ucrania no depende del tamaño de la empresa, sino del alcance de la prueba: cuántos sistemas y roles de usuario hay que revisar, cuánto trabaja el especialista a mano y cuántos días laborables lleva todo, incluidos el informe y el retest. Por eso las cifras públicas del mercado se diferencian decenas de veces, y un precio cerrado y honesto solo se puede dar tras una llamada corta sobre tus sistemas.

Abajo tienes tres ejemplos típicos de alcance con su duración en días laborables, una tabla de qué influye en el precio, una lista de preparación y consejos para elegir proveedor de pentest.

El error más caro al contratar un pentest no es pagar de más. Es pagar por un escaneo automático y creer que se han revisado los accesos, los roles y la lógica de negocio. El escáner no ve eso, y un atacante comprueba justamente eso. Un escenario típico: un comprador cambia el número de pedido en la dirección de la página y ve las direcciones y teléfonos de otras personas. El inicio de sesión funciona, el pago funciona y el escáner no encontró nada.

En resumen

• Un pentest es una prueba acordada y controlada de sistemas concretos. No equivale a un escaneo automático ni significa «probar todo».
• El precio depende ante todo de un alcance claro: qué sistemas y roles se prueban, con qué profundidad, cuántos días trabaja el especialista y qué incluyen el informe y la revisión posterior (retest).
• Duraciones orientativas: una web con área de cliente suele llevar de 5 a 10 días laborables, una web con la API de una app móvil de 8 a 15, y una empresa de 30 personas (perímetro, oficina en la nube, simulación de phishing) de 8 a 14.
• Los precios publicados en Ucrania cuentan cosas distintas, así que de ellos no sale un promedio. El precio cerrado llega tras una llamada sobre tus sistemas.
• Antes de firmar, acuerda la autorización por escrito, los límites y exclusiones, las reglas de prueba segura, el contenido del informe, la corrección y el retest.

Cuánto cuesta en Ucrania

Sin un alcance idéntico, las cifras no son comparables. En los materiales públicos ucranianos aparecen de $300 a $500 por una aplicación web pequeña o una API en un proveedor y de $5.000 a $30.000 por un proyecto corporativo en otro. ^{[7] [8]} Son volúmenes de trabajo distintos, por lo que no pueden compararse como si fueran el mismo servicio.

De qué depende el precio

El precio se compone de los días de trabajo del especialista. Cada fila de abajo suma o resta días, y la última columna muestra cómo ahorrar sin perjudicar el resultado.

Ejemplos de ofertas públicas

Ejemplos de ofertas públicas, no una mediana del mercado.

Un mínimo de unos pocos cientos de dólares suele indicar un alcance limitado, así que pregunta qué incluye exactamente.

De estas publicaciones no puede deducirse que «un pentest normal cuesta tanto». Muestran otra cosa: difieren los sistemas, la profundidad, el número de roles, las horas manuales, el tipo de informe y el retest. Al pedir un presupuesto, solicita que indiquen la moneda, los impuestos, los días por persona, la composición del equipo, el trabajo automatizado y el manual, las exclusiones, el plazo y el precio de un retest adicional. Así dos ofertas pueden compararse con las mismas reglas.

Si tu negocio acepta pagos con tarjeta, aclara por separado si entras en el ámbito de PCI DSS y en qué papel. PCI SSC describe la aplicación del estándar a las organizaciones que almacenan, procesan o transmiten datos de tarjetas de pago o pueden afectar a su entorno; los requisitos de cada organización deben confirmarse con el adquirente o con un evaluador cualificado. Eso no significa que todo sitio necesite el mismo conjunto de trabajos. ^[5] Para procedimientos PCI concretos, usa la versión vigente del estándar y no el antiguo suplemento de recomendaciones de 2017. ^[6]

Tres ejemplos de alcance: una web, una web con API, una empresa de 30 personas

Aquí no doy importes a propósito: dependen de tus sistemas concretos. La duración en días laborables da una idea más honesta del alcance. Los días de abajo incluyen el trabajo del especialista con el informe, pero no el retest. El precio cerrado y el plazo los doy tras una llamada corta, cuando veo tu lista de sistemas y roles.

Ejemplo 1. Web de empresa con área de cliente

Qué se prueba. El inicio de sesión, el registro y la recuperación de contraseña. Si cada cliente ve solo sus pedidos, documentos y facturas. Los roles del personal y el panel de administración, los formularios y la subida de archivos, la configuración del servidor donde funciona la web. Un hallazgo típico: cambiar el número de pedido abre datos ajenos, como en el ejemplo del principio del artículo.

Duración. Normalmente de 5 a 10 días laborables con el informe incluido.

Qué incluye el informe. Un resumen breve para la dirección; cada hallazgo con evidencia y pasos de reproducción; la valoración del riesgo; una corrección concreta para el desarrollador; la lista de lo probado y lo excluido.

Qué cambia el alcance. Más días: varios roles de personal, pagos, integraciones con un CRM o un sistema contable, probar solo en producción en ventanas nocturnas. Menos días: un rol de cliente y uno de administrador, un entorno de pruebas, cuentas de prueba listas y una nota de quién debe ver qué.

Ejemplo 2. Web y API de una app móvil

Qué se prueba. Todo lo del primer ejemplo más la API (la interfaz con la que la app intercambia datos con el servidor). Si se pueden obtener datos ajenos cambiando un identificador; si se comprueban los permisos en cada petición; si el servidor devuelve campos de más; si los intentos de inicio de sesión están limitados. OWASP recoge por separado los riesgos de las API, y el primero de su lista es justamente el acceso a objetos de otros usuarios. ^[9] Si la propia app entra en el alcance, también se revisa qué guarda en el teléfono: tokens de sesión, claves, datos almacenados.

Duración. Normalmente de 8 a 15 días laborables. La web y la app suelen usar la misma API, así que los días de las dos partes no se suman sin más.

Qué incluye el informe. Lo mismo que en el primer ejemplo, más la lista de métodos de la API probados (las direcciones a las que llama la app) y, por separado, los hallazgos de las apps de Android e iOS si entraban en el alcance.

Qué cambia el alcance. Más días: dos plataformas, muchos métodos de API sin documentación, una protección de la app contra el análisis que hay que sortear. Menos días: documentación de la API (por ejemplo, una colección de Postman o una descripción en Swagger), cuentas de prueba, una versión de prueba de la app, una sola plataforma en la primera fase.

Ejemplo 3. Empresa de 30 personas: perímetro, oficina en la nube y phishing

Qué se prueba. Tres partes. El perímetro externo: qué se ve de tus sistemas desde internet (web, correo, VPN, acceso remoto, subdominios olvidados) y si eso permite entrar. La oficina en la nube, es decir, Microsoft 365 o Google Workspace: el inicio de sesión en dos pasos, los permisos de administrador, el reenvío de correo hacia fuera, el acceso a archivos compartidos y los registros SPF, DKIM y DMARC (protegen tu dominio contra correos falsificados). Para Microsoft 365, su propio Secure Score es un buen punto de partida, pero no sustituye una revisión manual. ^[10] Y una simulación de phishing: un correo de entrenamiento acordado para ver quién abre el enlace, quién introduce datos en una página falsa y quién avisa del correo.

Duración. Normalmente de 8 a 14 días laborables: el perímetro de 3 a 5, la oficina en la nube de 2 a 4, la simulación de phishing de 2 a 4 con la preparación del escenario, más un informe conjunto. En tiempo de calendario son 3 o 4 semanas, porque una campaña de phishing tiene que durar varios días.

Qué incluye el informe. Un único resumen para la dirección sobre las tres partes; los hallazgos técnicos del perímetro; la lista priorizada de ajustes de la oficina en la nube; estadísticas anónimas del phishing (cuántos abrieron, hicieron clic, avisaron); un plan de qué corregir primero.

Qué cambia el alcance. Más días: varios dominios u oficinas, servidores propios además de la nube, varias oleadas o escenarios de phishing. Menos días: un solo dominio, acceso de lectura a la consola de administración en lugar de buscar los ajustes desde fuera, una sola oleada de phishing. El número de personas influye menos de lo que parece: todos reciben el correo a la vez. Una empresa así a menudo no necesita un pentest clásico, sino una combinación de prueba del perímetro, Security Assessment de la oficina en la nube y simulación de phishing. Un buen proveedor te dirá por dónde empezar en tu caso.

El retest tras las correcciones suele llevar de 1 a 3 días laborables, según el número de hallazgos. Para tener un precio cerrado basta una llamada corta: nos dices tus sistemas y roles, y recibes un alcance por escrito con el número de días.

Qué compra realmente una empresa

Un pentest responde a una pregunta más estrecha que «¿es segura la empresa?»: ¿puede un evaluador, en condiciones acordadas, explotar debilidades de sistemas concretos y qué implicaría? OWASP describe métodos de prueba para aplicaciones y servicios web, entre ellos autenticación, autorización, sesiones y API. Es un mapa útil de pruebas, pero no la promesa de revisar cada sistema posible. ^[2]

Para una tienda online o un SaaS esto puede significar probar el inicio de sesión, la recuperación de contraseña, la cuenta del cliente, los roles del personal, la API, los pagos y el panel de administración. Pero probar un proveedor de pagos, un hosting o una integración de terceros no debe darse por autorizado. La propuesta debe nombrar con claridad a los propietarios de los sistemas, los límites y las acciones acordadas.

En mi trabajo, el fallo típico no siempre parece un «hackeo» espectacular. Más a menudo el sistema deja entrar correctamente al usuario en su cuenta, pero no comprueba lo bastante que los datos que solicita le pertenecen. O un empleado tiene más permisos de los que necesita su rol. Para el dueño del producto puede parecer una petición normal a la API; el especialista comprueba si cambia el resultado al sustituir otro identificador o pasar a otro rol. Sin permiso del propietario y un procedimiento de prueba controlado, estas comprobaciones no pueden hacerse.

Por eso el escáner y el pentest no son intercambiables. El escáner encuentra automáticamente señales técnicas conocidas. El pentester comprueba si un hallazgo puede convertirse en impacto real, si se pueden combinar varias debilidades y dónde se rompe realmente la lógica prevista del producto. NIST describe por separado distintos métodos de prueba, con sus ventajas y límites; PCI SSC también distingue el escaneo de vulnerabilidades de las pruebas de penetración. ^{[4] [6]}

Qué debe incluir el trabajo

Un buen proceso suele empezar no por lanzar herramientas, sino por una conversación sobre objetivos y sistemas. La guía ucraniana de Diia.Business (en ucraniano) describe la planificación y el reconocimiento, el análisis de vulnerabilidades, la simulación de ataques, el informe y la revisión posterior a las correcciones. ^[1] En la práctica, para el cliente eso significa estas etapas:

1. Definir el objetivo. Por ejemplo, comprobar si un usuario normal puede obtener datos de otro cliente o si el perímetro externo está suficientemente protegido.
2. Alcance y reglas de interacción. Lista de dominios, direcciones IP, aplicaciones, API, entornos y roles; qué está permitido y qué se excluye; un contacto para una parada urgente. NIST recomienda planificar las pruebas técnicas, fijar las reglas de su realización y analizar los resultados, y no reducir el trabajo al simple escaneo. ^[4]
3. Pruebas manuales y automatizadas. Las herramientas ayudan a encontrar debilidades típicas, mientras que la revisión manual aporta contexto, confirma los hallazgos y explora escenarios propios del producto.
4. Prueba controlada del impacto. El evaluador demuestra que el problema es real, pero no debe, sin un permiso aparte, modificar ni borrar datos, detener el servicio ni salirse del objetivo acordado.
5. Informe y revisión de resultados. OWASP aconseja que el informe sea claro y reproducible: explicar qué se probó y cómo, describir la causa raíz, el riesgo, el impacto en el negocio y la corrección concreta. ^[3]
6. Retest. Tras las correcciones se comprueba si se han cerrado los hallazgos concretos. Aclara de antemano cuántas revisiones repetidas incluye el precio y cuándo pueden solicitarse. En el mercado son condiciones comerciales distintas, no una garantía automática.

Qué recibe el cliente

Pide que el resultado quede fijado en el contrato o en las especificaciones: un resumen breve para la dirección; una descripción técnica de cada hallazgo con evidencias y pasos de reproducción; la valoración del riesgo y la prioridad; recomendaciones de corrección; la lista de sistemas probados y excluidos; la fecha de la prueba y sus limitaciones; una sesión de preguntas y respuestas; las condiciones del retest. Ese documento ayuda a decidir qué corregir de inmediato y qué planificar. Una simple lista de alertas del escáner no lo sustituye. ^[3]

Lista de preparación para un pentest

Guarda esta lista y repásala antes de la reunión inicial:

• Formula la pregunta de negocio: ¿qué datos, dinero u operaciones es crítico proteger?
• Reúne una lista exacta de dominios, IP, aplicaciones web, API, componentes móviles y entornos en la nube.
• Marca qué es tuyo y qué gestionan el hosting, el servicio de pagos u otro proveedor. Obtén los permisos necesarios.
• Decide si se prueba producción o un entorno aparte. Define las ventanas de trabajo y los momentos en que están prohibidas las pruebas de riesgo.
• Prepara cuentas de prueba de distintos roles y datos de prueba seguros. No entregues las contraseñas habituales de los empleados.
• Acuerda por escrito las acciones prohibidas, los límites de carga, el procedimiento de parada, los contactos de escalado y la recuperación desde copias.
• Avisa a los ingenieros de guardia y al equipo de respuesta, pero no necesariamente a cada empleado, si el escenario no lo requiere.
• Define el formato del informe, un canal seguro de entrega, el plazo de conservación de los materiales y las condiciones de su eliminación.
• Establece qué significa «retest realizado» y cuándo termina.

Descargar la lista de preparación (PDF)PDF · A4

La autorización por escrito y las reglas de interacción no son una formalidad. Impiden que el evaluador pruebe por error un entorno ajeno o continúe una comprobación activa cuando el equipo ve un riesgo para el servicio. NIST considera la planificación y las reglas de interacción parte de unas pruebas organizadas; PCI SSC también dedica secciones propias a ello en su guía complementaria. ^{[4] [6]}

Señales de alerta al elegir proveedor

Un certificado puede ser una señal útil, pero no sustituye una conversación sobre método, límites y resultado. Comprueba la experiencia con el tipo exacto de sistemas que contratas y pide que expliquen cómo llega el equipo de un hallazgo a un plan de corrección comprensible. Más sobre esto en el artículo cómo elegir una empresa de pentest.

Preguntas que conviene hacer al proveedor

1. ¿Qué sistemas, roles y escenarios de negocio entran en el alcance? ¿Qué se excluye?
2. ¿Qué parte de la revisión se hará a mano y qué se automatizará?
3. ¿Qué accesos y materiales de prueba necesitáis de nosotros?
4. ¿Probáis producción? ¿Qué acciones están prohibidas sin un acuerdo aparte?
5. ¿Quién es nuestro contacto durante la prueba, quién puede detener el trabajo y con qué rapidez escaláis un riesgo?
6. ¿Qué contendrá el informe? ¿Podemos ver una muestra anonimizada?
7. ¿Qué plazos, número de especialistas y días laborables incluye el precio?
8. ¿El retest está incluido? ¿Con qué alcance, cuántas rondas y hasta qué fecha?
9. ¿Cómo se protegen las evidencias y los accesos y cuándo se eliminan?
10. ¿Cómo cambiará el precio si mientras se acuerda el alcance cambia la lista de sistemas?

Lo que un pentest NO garantiza

Un pentest no demuestra que un sistema no tenga ninguna vulnerabilidad. Muestra el resultado de probar un alcance concreto, con métodos concretos, en un periodo concreto. Una API no incluida, una versión nueva, otro rol o una vulnerabilidad que no se pudo probar con seguridad quedan fuera de la conclusión. OWASP distingue expresamente su guía de pruebas prácticas del análisis completo del código fuente y de un estándar formal de cumplimiento. ^[2]

Un pentest tampoco sustituye las actualizaciones constantes, la monitorización, el control de accesos, las copias de seguridad y la corrección de lo encontrado. Ni siquiera un buen informe reduce el riesgo si el equipo no ha asignado responsables y plazos a las tareas. Y un certificado o el nombre de una metodología no demuestran por sí solos la profundidad de una prueba concreta.

A lo largo de mi carrera, desde 2019, he realizado más de 170 pentests para más de 80 empresas, también trabajando en bancos y en consultoría: he probado personalmente aplicaciones web, API e infraestructura y he dirigido un equipo de pentesters. Me importa que el cliente entienda qué corregir primero y por qué, así que empiezo por el alcance y las reglas, no por las herramientas. Si una auditoría completa es ahora demasiado grande, se puede empezar por una zona crítica, por ejemplo la autorización en la cuenta del cliente o el perímetro externo. Una revisión así muestra cómo es el trabajo sobre un alcance acordado y no promete encontrarlo todo.

FAQ: respuestas a las preguntas frecuentes

¿Cuánto cuesta un pentest en Ucrania?

Depende del alcance: el número de sistemas y roles, la profundidad de la revisión manual, el informe y el retest. Las referencias públicas van de unos cientos a decenas de miles de dólares porque describen trabajos distintos. Pide un presupuesto con el número de días laborables y la lista de lo que incluye; un precio cerrado y honesto llega tras una llamada corta sobre tus sistemas.

¿Cuántos días dura un pentest?

Para una web con área de cliente, normalmente de 5 a 10 días laborables; para una web con la API de una app móvil, de 8 a 15. El retest tras las correcciones suele llevar de 1 a 3 días.

¿Depende el precio del número de empleados?

En el pentest de una web o una API, casi nada: se valoran los sistemas, los roles y el tiempo. El número de personas influye algo en la simulación de phishing y en la revisión de Microsoft 365 o Google Workspace, pero incluso ahí pesan más los dominios y los escenarios.

¿Cómo bajar el coste sin perder calidad?

Reduce el alcance al sistema más crítico, entrega cuentas de prueba, documentación y un entorno de pruebas, y corrige los hallazgos antes de un único retest conjunto. No recortes la revisión manual: es la que encuentra lo que el escáner no ve.

¿Puede un servicio automático barato sustituir un pentest manual?

La automatización encuentra señales conocidas, pero no comprueba la lógica del producto ni los derechos de acceso. Pregunta quién confirma manualmente los hallazgos y qué habrá en el informe.

Para terminar

Tras una reunión de definición del alcance, un buen resultado suele empezar con una lista corta: esta cuenta de cliente, estos roles, esta API, estas acciones prohibidas y esta persona a quien llamar si algo sale mal. Cuando el equipo ve los mismos límites y el mismo resultado, el pentest deja de ser un gasto desconocido y se convierte en un plan de trabajo manejable. Si quieres definir ese alcance con calma para tu negocio, solicita una llamada gratuita de 30 minutos o empieza por la descripción del servicio de Pentesting.

Referencias

1. Diia.Business: ¿Qué es el pentesting? (en ucraniano) business.diia.gov.ua
2. OWASP Web Security Testing Guide: Introduction wstg.owasp.org
3. OWASP Web Security Testing Guide: Reporting Structure wstg.owasp.org
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. PCI Security Standards Council: PCI DSS pcisecuritystandards.org
6. PCI SSC: Penetration Testing Guidance v1.1 (2017) pcisecuritystandards.org
7. ESKA: cómo se forman los precios de las pruebas de penetración (en ucraniano) eska.global
8. ITFB: pentesting para empresas y su coste (en ucraniano) itfb.com.ua
9. OWASP API Security Top 10 (2023) api-security.owasp.org
10. Microsoft Learn: Microsoft Secure Score learn.microsoft.com