®Offensive security / Result as a Service
Result as a Service is our model for suitably scoped penetration tests: together we define a provable test objective and a fixed fee. If we do not deliver the agreed evidence, you do not pay the agreed success-based penetration testing fee. What counts as a result, which systems may be tested and how the evaluation is carried out are set out in writing before the start.
Services in detail
Predefined result · pre-agreed amount
Your brief for OTOKO®
The work packages are derived from your current situation. Your team knows the agreed scope, the required involvement and the results that should be available at handover.
The objective describes a specific, assessable impact in the authorized system. A generic warning or an unconfirmed scanner finding does not automatically become a payment-triggering result. Prerequisites and the required evidence are defined together.
A written definition of the result with accepted evidence criteria.
Before the start, the fixed fee, test scope and time window are agreed. Known findings, excluded systems and required access are documented. Separate services are provided only if they are explicitly ordered in addition.
A clear agreement on services and fees.
Financial success does not extend the permission granted. Test rules, protection of operations, reporting channels and abort criteria apply regardless of the fee model. The examination remains limited to the objectives authorized in writing.
A controlled examination within the agreed framework.
The result is assessed against the criteria agreed in advance. Reproducibility, impact and prerequisites are documented. Remediation and retesting can be agreed as separate services scoped in advance.
A documented result assessment and a specific basis for next steps.
Planning & implementation
A success-based model needs a shared definition of the result. One option, for example, is a clearly described proof that an agreed permission boundary is not maintained under the defined conditions. Which impact, severity and reproducibility are sufficient is decided before the start. Known findings and risks that have already been accepted are also categorized. This way, both sides know whether a later finding belongs to the agreed objective or is merely an additional observation.
The fixed fee relates to this result as defined in writing and the agreed test scope. If the required evidence is not produced within this framework, the success-based penetration testing fee does not apply. A finding outside the scope does not automatically create a claim to payment. Additional analysis, remediation or retesting is ordered only through a separate, explicit agreement. The model is meant to create a clear economic basis, not a vague expectation that every technical anomaly already represents a success.
Before the start, target systems, permitted starting points, test accounts and the time window are recorded. Rights to third-party systems or platforms must be clarified. Points of contact, reporting channels and conditions for an interruption are agreed as well. The incentive of proving a result changes none of these rules. A test must neither be extended to other systems on its own authority nor continued with unauthorized methods just to reach the defined objective.
Evidence is limited to what is necessary for the assessment. Where a prepared test dataset can demonstrate an impact, no other customers’ data needs to be used for it. Sensitive results are shared with authorized points of contact through agreed channels. A shared review procedure is agreed in advance for disputes over the assessment. This way, the decision on the result can be made based on criteria and documentation, rather than having to reconcile different ideas about the meaning of a finding only at the end.
Result as a Service is suitable for objectives that can be clearly scoped and proven. This can include defined questions in SaaS, APIs, legacy software or customer-managed infrastructure. For AI applications, variable outputs and the multiple components involved require especially precise evidence criteria. Whether the model fits your project is therefore checked before any commitment. A general current-state review, full audit coverage and a single success-based test objective are different services.
A test without the agreed evidence does not mean the system is generally free of vulnerabilities. The statement remains limited to the scope, the version examined and the time window. Even a successful proof is first of all the starting point for remediation. The technical documentation is meant to let your team understand the cause and impact and plan the fix. A subsequent retest can specifically check whether the particular vulnerability has been fixed in the new version; its scope is defined separately.
Illustrative project scenario
Before a SaaS test, a specific tenant boundary is set as the test objective using prepared test data. The fixed fee is only due if the evidence agreed in writing is produced under the permitted conditions. A generic scanner warning without this evidence does not fulfill the agreement.
Before you start
For the success-based penetration test agreed in writing, no fee is due without the defined evidence. Additional services are only ordered separately and explicitly. Scope and conditions are fixed before the start.
Not automatically. Which type of finding or impact is sufficient is defined in writing before the start, together with the evidence, prerequisites and evaluation procedure.
No. The absence of evidence is not a general confirmation of security. The result relates to the agreed test scope and the version examined.
The specific scope of services is defined in advance. Remediation and retesting can be agreed separately; they are not included automatically or as a hidden extra.
Related services
Result as a Service with OTOKO®
Name the affected systems and the goal of your request. In the first consultation, we jointly define scope, preconditions and the next steps.
Discuss a results-based agreement
