Cómo evaluar la seguridad de un sitio antes de contratar protección: checklist ejecutivo

Está en la reunión de aprobación presupuestaria; el CISO abrió la discusión y la junta pregunta: “¿qué exactamente vamos a comprar y cómo lo vamos a demostrar?” Esa pregunta marca el momento en que las promesas de marketing deben convertirse en obligaciones auditables. La tesis práctica: exigir evidencia técnica y compromisos contractuales reduce el ruido, facilita la aprobación y protege el gasto frente a afirmaciones no verificadas.

A continuación presento un checklist ejecutivo de evidencia mínima, una matriz para comparar propuestas con criterios repetibles y un RFP light con campos obligatorios. Luego detallo cláusulas recomendadas (retest, tuning continuo, acceso a evidencia), límites y compensaciones, y un camino operativo para ejecutar un piloto técnico.

¿Qué evidencia solicitar para aprobar un contrato?

Pida solo elementos auditables. Evite aceptar frases como “tuning continuo” sin comprobación. Cada elemento debe tener formato de entrega (archivo, credencial, política o cronograma) y un responsable del proveedor.

• Logs y retención de telemetría: muestras de logs (anonimizados) que muestren eventos bloqueados y permitidos, con timestamps y contexto (URI, cabecera, regla aplicada). Exija formato y nivel de detalle para auditoría.
• Runbooks y playbooks: procedimientos escritos para tuning, gestión de falsos positivos, rollbacks y despliegues. No acepte “tenemos procesos” — pida el documento.
• Retest tras corrección: cláusula contractual que garantice un retest determinístico después de una corrección, con informe y alcance definidos.
• SLAs medibles: SLA de disponibilidad de la protección (si aplica), SLA de tiempo de respuesta a incidentes y SLA de tiempo para acciones correctivas; solicite definición de métricas y método de medición.
• Auditoría y evidencia de tuning: registros de cambios (change log) con justificación técnica y aprobaciones; versiones de reglas aplicadas y frecuencia de tuning.
• Prueba de integridad operativa: evidencia de pruebas de integración (por ejemplo, simulación en staging), quién las ejecutó y resultados observados.
• Acceso a datos para cumplimiento: cómo el proveedor entrega logs y reportes para auditoría y solicitudes de GRC/LGPD.
• Inventario de cobertura: lista de endpoints, dominios y subdominios cubiertos y exclusiones explícitas.
• Formación y transferencia de conocimiento: registros de sesiones de formación y materiales entregados al equipo interno.

Convertir la evidencia en una matriz de decisión comparable

Compare propuestas sobre cuatro ejes objetivos: impacto operativo, rigidez operativa, gobernanza y precio. Use métricas binarias o escalas simples para reducir ambigüedad.

Impacto operativo

• Cobertura funcional (WAF, reglas OWASP, mitigación de bots, inspección TLS)
• Visibilidad (logs en tiempo real vs informes diarios)
• Complejidad de integración (reverse proxy, DNS, host‑based)

Rigidez operativa

• Existencia de runbooks y change logs exigibles
• Nivel de automatización vs necesidad de intervención manual
• Política de rollback y ventanas de mantenimiento

Gobernanza

• Acceso a logs para auditoría
• Cláusula formal de retest
• Soporte para requisitos de GRC/privacidad

Precio (valor percibido)

• Precio por unidad de cobertura (dominio/endpoint)
• Costes de onboarding y tuning inicial
• Costes de operación continua (horas de soporte, tuning mensual)

Monte una hoja de cálculo donde cada criterio obtenga una nota 0–3 y un peso definido por la junta; eso convierte preferencias en una decisión auditable.

Checklist ejecutivo: entregables mínimos que debe entregar el proveedor

1. Muestra de logs anonimizados con leyenda y esquema.
2. Runbook de tuning y respuesta a incidentes (PDF o enlace protegido).
3. Compromiso contractual de retest con alcance y muestra de informe.
4. Plantilla de SLA con métricas definidas y método de medición.
5. Registro de cambios reciente (últimos 90 días o periodo negociado).
6. Inventario de cobertura y exclusiones técnicas.
7. Plan de formación y agenda de transferencia de conocimiento.

RFP light: campos obligatorios

Use este RFP light como lista de verificación; exija respuesta directa a cada campo.

• Resumen ejecutivo: alcance de protección solicitado (dominios, subdominios, APIs).
• Entregables técnicos: logs (esquema), runbooks, informes de tuning, change logs.
• SLAs: definir métricas y método de medición para disponibilidad y respuesta.
• Retest: cuándo y cómo se realizarán los retests tras correcciones.
• Integración: requisitos de infraestructura (proxy, DNS, certificados) y responsabilidades.
• Gobernanza: acceso para auditoría, soporte a GRC/privacidad y transferencia de conocimiento.
• Onboarding y piloto: propuesta de piloto técnico, criterios de éxito y entregables.
• Precios: detalle de componentes (licencia, managed services, horas de tuning).

Cláusulas contractuales recomendadas

Negocie cláusulas que conviertan la evidencia en obligaciones:

• Retest formal: el proveedor se compromete a ejecutar retest en el entorno acordado y entregar informe.
• Tuning continuo con change log: periodicidad mínima de tuning documentada y registro de cambios con justificación técnica.
• Acceso a logs para auditoría: formato y periodicidad de entrega; derecho a auditoría por tercero bajo condiciones acordadas.
• Planes de rollback: obligación de plan de rollback documentado y comunicaciones previas a mantenimientos.
• Criterios de aceptación del piloto: métricas y entregables que definen el éxito antes del compromiso a largo plazo.

Límites y compensaciones

Exigir evidencia de calidad alarga la evaluación y puede incrementar el coste inicial por trabajo de auditoría. Aceptar promesas reduce el tiempo de compra pero aumenta el riesgo. Decisiones habituales:

• Cobertura amplia vs alcance reducido con garantías más fuertes (coste vs gobernanza).
• Realizar un piloto con alcance limitado para validar métricas antes de ampliar (tiempo vs riesgo).
• Acceso total a logs vs logs agregados por privacidad; negocie formatos que cumplan con la normativa.

¿Cómo verificar que el proveedor realmente realiza tuning continuo?

Pida tres artefactos correlacionables: change log, informes periódicos de tuning con justificación, y muestras de versiones de reglas aplicadas. Cruzar logs con change log demuestra si los cambios tuvieron efecto operativo. Si el proveedor no entrega estos artefactos, trate la promesa como no verificada.

¿Es razonable exigir un retest post‑corrección y cómo formalizarlo?

Sí. Formalícelo en el contrato: defina criterios técnicos del retest (alcance, técnicas permitidas), plazo de ejecución y formato del informe. Vincule la aceptación de la corrección a la entrega del informe; sin esto, la corrección queda como una declaración no verificada.

Modelo operativo sugerido para el piloto

Ejecute un piloto técnico con alcance claro: 1–3 dominios en staging o con tráfico limitado; duración fijada; criterios de éxito (logs entregados, retest satisfactorio, tuning demostrado). Exija entregables periódicos y revisiones semanales con el proveedor para ajustar parámetros y recopilar evidencia.

Si deciden avanzar, MVX Shield puede ser socio para el piloto técnico: soliciten un piloto de evaluación técnico conforme al RFP light y validen los artefactos en un entorno controlado. Para información sobre servicios gestionados de seguridad web, consulte Website Security Gerenciado.

Siguiente paso

Descargue el template de RFP y solicite un piloto técnico de evaluación. El template convierte estas secciones en campos exigibles y facilita las conversaciones con legal y la junta. Exija que el piloto entregue los artefactos listados: es la forma más rápida de demostrar entrega y reducir el riesgo de compra basada en marketing.

CTA: Descargue el template de RFP y solicite un piloto de evaluación.