Describir el producto con operaciones
El alcance se comprende mejor cuando la descripción incluye qué hacen los usuarios. “Portal con diez pantallas” dice poco sobre permisos, integraciones o datos. “Portal que permite invitar usuarios, aprobar documentos y exportarlos por organización” identifica recorridos que necesitan examinarse.
No hace falta preparar una especificación completa para iniciar la conversación. Sí conviene separar lo conocido de lo que falta definir: activos, módulos, roles, entornos y cambios previstos.
Explicar quién utiliza el sistema
Anotá los roles y las diferencias relevantes. Un operador, un administrador de una organización y un administrador de toda la plataforma plantean límites distintos. Si existe acceso de integraciones, aclarar cómo se identifica cada una ayuda a dimensionar la revisión.
La disponibilidad de cuentas de prueba influye en la cobertura. Una evaluación desde el exterior observa una superficie distinta de una evaluación autenticada. La modalidad debe quedar reflejada en la propuesta.
Contar por qué necesitás la evaluación
Un lanzamiento puede concentrar la revisión en funciones nuevas. Un cliente puede exigir un informe con determinados activos y destinatarios. Una revisión de arquitectura puede requerir código o documentación adicional.
Comunicá las fechas deseadas y las dependencias que pueden afectar el calendario. Si el entorno todavía no está listo, indicá cuándo se espera que pueda utilizarse. La propuesta necesita una secuencia viable de preparación, pruebas y entrega.
Preparar la conversación sobre condiciones
Los sistemas propios y los de proveedores tienen autorizaciones diferentes. Identificá integraciones, restricciones operativas y acciones que produzcan efectos persistentes. La disponibilidad de documentación y de una persona de contacto también influye en cómo se organiza el trabajo.
La cotización debería definir inclusiones, exclusiones, entregables y condiciones para incorporar cambios. Si se necesita revalidación, conviene acordar sus hallazgos, accesos y ventana. La continuidad requiere además una cadencia y una capacidad de revisión.
Ejemplo ficticio para adaptar
Tenemos una aplicación web y una API compartidas por varias organizaciones. Cada organización tiene operadores y un administrador. Queremos revisar permisos y exportaciones antes de una nueva versión. Hay un entorno de prueba disponible. Necesitamos un informe técnico y una síntesis para un cliente.
Esta descripción permite preguntar por flujos, cuentas y restricciones sin compartir secretos. Agregá solo la información que conozcas y aclaraciones sobre la fecha deseada.
Material de preparación
La lista descargable organiza objetivos, superficie y condiciones. La página de propuestas explica qué se define al cotizar y la muestra de informe permite discutir el resultado esperado.
Como referencia metodológica, la OWASP Web Security Testing Guide describe áreas que pueden integrar una evaluación. La selección concreta depende del producto y de su alcance autorizado.
Otras lecturas.
- Cómo preparar el alcance de un pentest web
- Qué revisar en un informe de pentesting
- Evaluación puntual y seguimiento periódico