Contenido del artículo
- En resumen
- Qué preparar: una tabla para el cliente
- Alcance: sistemas, entornos, roles
- Autorización escrita y reglas de enfrentamiento
- Nube y hosting: ¿hay que avisar a alguien?
- Copias de seguridad, preproducción o producción
- Qué decir al equipo
- Cómo leer el informe y qué hacer con él
- El retest
- Checklist de preparación
- Preguntas frecuentes
- Referencias
El cliente tiene tres tareas: describir por escrito qué se va a probar exactamente, firmar una autorización con las reglas del trabajo y preparar con antelación accesos, personas y copias de seguridad. Si todo esto está listo antes de empezar, el pentest se dedica a encontrar problemas reales y no a esperar contraseñas, y tu sistema en producción no se lleva sorpresas.
Abajo tienes una tabla de qué preparar, para qué y quién lo hace, notas sobre cada punto y una checklist que puedes reenviar a tu equipo. Cómo elegir proveedor lo explico en 10 preguntas a una empresa de pentesting, y de qué depende el precio en qué incluye un pentest y cuánto cuesta.
En resumen
- El alcance (qué se prueba exactamente) debe estar por escrito: sistemas, direcciones, entornos, roles de usuario y lo que queda fuera.
- La autorización y las reglas del trabajo las firma alguien que puede decidir por la empresa. Sin ese documento no empieza ninguna prueba activa.
- A octubre de 2026, AWS, Microsoft Azure y Google Cloud no exigen aprobación previa para un pentest normal de tus propios recursos, pero cada uno tiene sus prohibiciones. El hosting tradicional tiene sus propias reglas.
- Antes de empezar, haz una copia de seguridad reciente y comprueba que se restaura.
- El informe solo sirve si cada hallazgo tiene responsable y plazo. El retest (una segunda comprobación tras las correcciones) muestra qué está cerrado de verdad.
Qué preparar: una tabla para el cliente
| Qué preparar | Para qué | Quién |
|---|---|---|
| Lista de sistemas: webs, APIs, direcciones IP, apps móviles | Que se pruebe lo importante y nada ajeno | Responsable de IT |
| Decidir dónde se prueba: preproducción o producción | Saber el riesgo para los clientes y qué mostrará el resultado | CTO |
| Roles de usuario y cuentas de prueba, dos por rol | Comprobar si un cliente puede ver los datos de otro | Desarrolladores |
| Autorización escrita y reglas de enfrentamiento | Base legal de la prueba y límites de lo permitido | Dueño o director general |
| Contactos, horario de pruebas, canal para avisos urgentes | Parar la prueba rápido o corregir algo crítico | Responsable de IT |
| Revisar las reglas del hosting o la nube | Que la prueba no incumpla las condiciones del proveedor | Administrador |
| Copia de seguridad reciente con restauración probada | Poder deshacer cualquier fallo | Administrador |
| Aviso a soporte y monitorización | Que no confundan la prueba con un ataque real, o al revés | Responsable de IT |
| Responsable del informe y de las correcciones | Que los hallazgos no se queden en un PDF | Dueño o CTO |
Alcance: sistemas, entornos, roles
Empieza por la lista de lo que tienes: dominios, direcciones de API, IPs de servidores, apps móviles, paneles de administración. Junto a cada punto, escribe por qué importa al negocio y qué datos contiene. Así el proveedor entiende dónde importa la profundidad y dónde basta una revisión más ligera.
Describe aparte los roles de usuario: cliente, gestor, administrador, socio. Crea al menos dos cuentas de prueba por rol. Así se comprueba el problema más común de las aplicaciones web: si un cliente puede ver los pedidos o documentos de otro.
Nombra también lo que queda fuera. Un proveedor de pagos, un CRM en la nube o un servicio de email pertenecen a otras empresas y no se pueden probar sin permiso de su dueño. El NCSC recomienda que en la definición del alcance participen los dueños del riesgo, el personal técnico y alguien del equipo de pruebas. [5]
Autorización escrita y reglas de enfrentamiento
La autorización protege a ambas partes: a ti de daños y al proveedor de una acusación de acceso no autorizado. Las reglas de enfrentamiento (cómo se comportan los testers durante la prueba) suelen incluir:
- qué sistemas se pueden probar y desde qué IPs de los testers;
- las fechas y horas en que se permiten pruebas activas;
- qué está prohibido: ataques de carga, borrar datos, emails a clientes reales;
- a quién llamar si la web se ralentiza y cómo parar la prueba;
- qué hace el proveedor si encuentra algo crítico: avisa en el momento, sin esperar al informe.
NIST describe la planificación y las reglas de las pruebas de seguridad en su guía. [4] Firma el documento alguien que de verdad tenga derecho a dar acceso a los sistemas de la empresa.
Nube y hosting: ¿hay que avisar a alguien?
Las reglas de las grandes nubes a octubre de 2026:
- AWS. No hace falta aprobación previa para los servicios de la lista permitida. Están prohibidos los ataques de denegación de servicio (DoS, saturar un servicio con peticiones) y algunas otras acciones. Las simulaciones de ataque encubiertas y los servidores de mando y control (C2) requieren una solicitud aparte con al menos dos semanas de antelación. [1]
- Microsoft Azure. No hace falta avisar a Microsoft, pero se aplican sus reglas para pentest en la nube: probar solo tus recursos, nada de DoS. [2]
- Google Cloud. No hace falta avisar a Google. Las pruebas deben afectar solo a tus proyectos y cumplir las normas de uso de Google Cloud. [3]
El hosting tradicional y los VPS tienen sus propias condiciones. En un hosting compartido hay otros clientes a tu lado, así que solo se prueba tu web. Lee el contrato o escribe a soporte con antelación. Si la web está detrás de un WAF (un filtro de peticiones web) o una CDN, decide si añadir las IPs de los testers como excepción: si no, la protección puede bloquear la prueba y el resultado hablará del filtro, no de la web.
Las reglas de los proveedores cambian. Antes de empezar, abre la página actual de tu proveedor en lugar de fiarte de un artículo, incluido este.
Copias de seguridad, preproducción o producción
Un entorno de preproducción (staging, una copia del sistema para pruebas) es más seguro: allí se pueden probar escenarios más agresivos. Pero debe parecerse a producción: la misma versión del código y los mismos permisos. Algunos problemas solo existen en producción, como errores de configuración del servidor o servicios abiertos innecesarios. A menudo se prueba a fondo staging y el perímetro de producción se revisa con cuidado en horas acordadas.
Antes de empezar, haz una copia reciente e intenta restaurarla. Una copia que nunca se ha restaurado es una esperanza, no un plan. No guardes datos personales reales de clientes en staging: los registros inventados funcionan igual.
Qué decir al equipo
Del pentest deben saber la dirección, los administradores, soporte y quien vigile los registros. Si no, soporte recibirá peticiones raras de cuentas de prueba y un administrador bloqueará al tester a mitad del trabajo.
A veces la empresa no avisa a propósito a quienes vigilan la seguridad, para ver si detectan el ataque. Está bien, pero entonces al menos una persona de confianza conoce la prueba y puede frenar una escalada. No planifiques grandes lanzamientos durante la prueba o avisa de ellos al proveedor.
Cómo leer el informe y qué hacer con él
Un buen informe tiene un resumen breve para la dirección y detalles técnicos para el equipo. Cómo valorar su calidad lo cuento en el artículo sobre cómo elegir proveedor. Cuando llegue el informe:
- Lee el resumen y asegúrate de entender cómo amenaza al negocio cada hallazgo crítico.
- Asigna a cada hallazgo un responsable y un plazo. Lo crítico se cierra primero.
- Corrige la causa, no un solo campo del formulario: un error parecido suele estar en sitios vecinos.
- Si decides no corregir algo, regístralo como riesgo aceptado con firma.
El NCSC recuerda que las decisiones sobre riesgos y correcciones son del cliente, no de los testers. [5]
El retest
El retest comprueba los mismos hallazgos tras tus correcciones. Acuerda antes de empezar si está incluido en el precio y en qué plazos. Pide confirmación por escrito de qué problemas están cerrados y cuáles no. El retest no busca cosas nuevas: si has cambiado mucho el sistema, necesitas un pentest nuevo, no una repetición.
Checklist de preparación
Descargar la lista de preparación (PDF)PDF · A4
Preguntas frecuentes
¿Cuánto tiempo lleva la preparación?
Si los sistemas están descritos y una sola persona da los accesos, suelen bastar unos pocos días laborables. Lo que más se espera es la firma de la autorización y las cuentas de prueba, así que empieza por ahí.
¿Se puede probar solo producción, sin staging?
Sí, si las reglas lo tienen en cuenta: pruebas más prudentes, horas acordadas, copia reciente y alguien de guardia. Los escenarios agresivos mejor en staging.
¿Hay que dar a los pentesters contraseñas de administrador?
Depende del objetivo. Una prueba «desde fuera» no necesita accesos. Para probar permisos hacen falta cuentas de prueba con distintos roles. Nunca entregues contraseñas reales de empleados.
¿Hay que avisar a AWS, Azure o Google Cloud?
A octubre de 2026, un pentest normal de tus propios recursos no necesita aprobación previa, pero hay que cumplir las reglas de cada proveedor. AWS pide además una solicitud para simulaciones de ataque encubiertas. Revisa la página actual de tu proveedor antes de empezar.
¿Qué pasa si durante la prueba aparece algo crítico?
El proveedor debe avisarte en el momento, sin esperar al informe. Acordad antes quién recibe ese aviso y quién decide si corregir ya o seguir con la prueba.
Referencias
- AWS: Penetration Testing aws.amazon.com
- Microsoft Cloud Penetration Testing Rules of Engagement microsoft.com
- Google Cloud Security FAQ support.google.com
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
- NCSC: Penetration testing ncsc.gov.uk
