Sin evidencia. Sin pago.

Un modelo vinculado al éxito necesita una definición conjunta del resultado. Puede tratarse, por ejemplo, de la evidencia, descrita de forma concreta, de que un límite de permisos acordado no se respeta bajo las condiciones establecidas. Qué repercusión, qué gravedad y qué reproducibilidad son suficientes se decide antes de empezar. Los hallazgos ya conocidos y los riesgos ya aceptados también se clasifican. Así, ambas partes saben si una evidencia posterior forma parte del objetivo acordado o si es simplemente una observación adicional.

El importe fijo se refiere a este resultado definido por escrito y al alcance de prueba acordado. Si la evidencia necesaria no se aporta dentro de este marco, no se devenga la retribución del pentest vinculada al éxito. Un hallazgo fuera del alcance no genera automáticamente un derecho de pago. Los análisis adicionales, la corrección o las repruebas solo se encargan mediante un acuerdo propio y expreso. El modelo debe crear una base económica clara, y no una expectativa indefinida de que cualquier anomalía técnica ya constituya un éxito.

Antes de empezar se fijan los sistemas objetivo, los puntos de partida permitidos, las cuentas de prueba y el plazo. Los derechos sobre sistemas o plataformas de terceros deben estar aclarados. Asimismo, se acuerdan los interlocutores, las vías de notificación y las condiciones para una interrupción. El incentivo de demostrar un resultado no cambia estas reglas. Una prueba no debe ampliarse por iniciativa propia a otros sistemas ni continuarse con procedimientos no autorizados solo para alcanzar el objetivo definido.

Las evidencias se limitan a lo necesario para la evaluación. Cuando un conjunto de pruebas preparado puede mostrar una repercusión, no es necesario utilizar para ello datos de clientes ajenos. Los resultados sensibles se comparten por vías acordadas con interlocutores autorizados. Para las cuestiones controvertidas sobre la evaluación se acuerda de antemano un procedimiento de revisión conjunto. Así, la decisión sobre el resultado puede tomarse a partir de criterios y documentación, en lugar de tener que conciliar al final ideas distintas sobre el significado de un hallazgo.

Result as a Service es adecuado para objetivos que puedan delimitarse y demostrarse con claridad. Esto puede incluir cuestiones definidas en SaaS, API, software heredado o infraestructura bajo responsabilidad del cliente. En las aplicaciones de IA, la variabilidad de las respuestas y la presencia de varios componentes implicados exigen criterios de evidencia especialmente precisos. Por eso, antes de comprometerse se comprueba si el modelo se ajusta a su proyecto. Un inventario general, una cobertura de auditoría completa y un único objetivo de prueba vinculado al éxito son servicios distintos.

Una prueba sin la evidencia acordada no significa que el sistema esté, en general, libre de vulnerabilidades. La conclusión se limita al alcance, al estado y al plazo analizados. Y cuando la evidencia se aporta, es ante todo el punto de partida para la corrección. La documentación técnica debe permitir a su equipo comprender la causa y la repercusión, y planificar la corrección. Una reprueba posterior puede comprobar de forma específica si la vulnerabilidad concreta se ha corregido en la nueva versión; su alcance se define por separado.