StrikePoint · Companion to the Architecture Guide

Acceptance & Surrender Levels

A methodology says how we test. It does not, by itself, say what counts as a win — and without that, "the test succeeded" is whatever the report claims. This module defines the missing half: a pre-agreed, contractual threshold of customer surrender that authenticates a methodology actually worked.

The agreed surrender level is two things at once: the success bar (how far we must get to prove a control failed) and the stop line (how far we are authorized to go). Acceptance criteria and rules of engagement are the same dial.

01The concept

Every engagement, per attack surface, carries an agreed Surrender Level — the depth of compromise at which the client's defense is deemed to have surrendered. It is written into the Statement of Work as an option the client selects, and it resolves the two hardest questions in offensive testing at the same time:

Did we succeed? The test authenticates as successful when StrikePoint reaches the agreed level. Below it, the control held; at or beyond it, the control failed. Objective, not editorial.
How far may we go? The same level is the authorization ceiling. Higher surrender = more invasive = correspondingly stronger written consent and tighter blast-radius controls. The client dials their own risk.

For a socially engineered attack, "success" could mean the target would have surrendered a secret, actually surrendered it, or that we could then act on it. Those are three different bars — and the client, not the tester, should choose which one authenticates the test. That choice is the surrender level.

02The universal surrender ladder

Five rungs, escalating from "the door is reachable" to "we walked out with the crown jewel." Every attack surface maps onto these same rungs, so acceptance is defined in one consistent language across the whole engagement.

S0Reachable

Exposure surface confirmed

The vector exists and is reachable from the tester's position. No interaction, no exploitation — pure attack-surface confirmation. The lowest-risk finding: "this door faces the street."

S1Susceptible

Would-surrender proven, not taken

A weakness is demonstrably exploitable, or a human demonstrably engages (clicks the link, answers the pretext) — proving compromise would occur, without actually taking the secret or firing the exploit. Non-destructive proof of susceptibility.

S2Surrendered

Disclosure & access obtained

The secret or the access is actually in StrikePoint's hands — credential captured, OTP disclosed, foothold established, data readable. The surrender happened; we hold what we obtained but have not yet used it.

S3Actioned

Controlled impact safely nefarious

StrikePoint uses the obtained access to perform a pre-authorized, safe, reversible proof-action: authenticate with the credential, redeem the OTP, move one hop laterally, or drop a benign marker / harmless proof payload. Demonstrates real — not theoretical — impact, inside a defined blast radius.

S4Objective

Crown jewel flag captured

StrikePoint reaches the pre-defined target asset — the agreed "flag": a specific record, system, or crown-jewel data set — demonstrating full chained business impact. The deepest authorized surrender, and the strongest consent requirement.

Consent scales with the rung. S0–S1 are non-invasive and low-risk. S2 obtains real secrets (handling & destruction obligations attach). S3–S4 execute actions on live systems and require a named client approver, explicit written authorization for the specific action, and defined stop conditions. The ladder is why "how far did you go?" always has a signed answer.

03What each rung means, per surface

The same five rungs, translated into concrete meaning for each attack surface in the methodology. This is the table referenced when a Statement of Work sets the level for each in-scope vector.

Attack surface	S0 Reachable	S1 Susceptible	S2 Surrendered	S3 Actioned	S4 Objective
Social engineering (phish / vish / pretext)	Target reachable & profiled	Target clicks / answers / engages	Target discloses credential or OTP	SP authenticates with it / redeems OTP / sends benign proof from account	SP reaches the data the lure targeted
External network & web app	Service exposed to internet	Vuln safely validated, not fired	Exploit lands; session / foothold gained	Controlled command exec / read a proof file	Reach target database or record
Wireless	Rogue AP / weak SSID in range	Association or handshake capture possible	Network access obtained	Pivot to an internal resource	Reach segmented crown-jewel system
Telecom / VoIP	PBX / SIP endpoint exposed	Misconfig present (default creds, open relay)	Unauthorized call path obtained	Place a controlled proof call / benign action	Reach target voice system or toll route
Physical	Entry point identified	Tailgating opportunity demonstrated	Actual entry achieved	Reach defined internal point / connect benign device	Reach server room / exec office / asset
Denial of service	Amplifiable / exhaustible vector found	Controlled, throttled degradation demonstrated	Capped — staging/isolated only	Out of scope by default	Out of scope by default

Denial of service is the framework proving its worth: because actual outage is destructive, DoS acceptance normally caps at S1 (controlled, measurable degradation) and never authorizes S3–S4 against production. The ladder makes that ceiling explicit and contractual instead of a verbal understanding.

04Worked example — the social-engineering case

The client picks where the test authenticates as successful, and where StrikePoint must stop.

Spear-phish + OTP capture against a finance-team target

S1The target clicks the lure and lands on the harvest page.Susceptibility proven. Many clients accept S1 as the pass bar for awareness testing — "our people would have surrendered" is enough to mandate training, and nothing sensitive was taken.
S2The target types their credential and approves the OTP prompt.The secret is actually surrendered and now held by StrikePoint. This is the "did they really give it up" bar — a materially stronger finding than a click.
S3StrikePoint uses the credential + OTP to authenticate, then sends one benign, pre-authorized proof email from the account (or drops a harmless marker).The "safely nefarious action" — demonstrating the surrender had real consequence, inside an agreed, reversible blast radius. Requires a named approver and explicit written authorization for this specific action.
S4StrikePoint uses the access to reach the crown-jewel target the campaign was aimed at (e.g., the payroll record set).Full chained impact. The deepest surrender, the strongest consent, and the most persuasive board-level finding.

One methodology, four legitimate definitions of "success." The value StrikePoint sells is not deciding for the client — it is making the client choose the bar in writing, before the test, so the result is never in dispute afterward.

05Contract mechanics — baking it in

Two values, set per in-scope surface in the Statement of Work. They are usually equal, but the client may authorize deeper demonstration than the pass bar requires.

Pass / Acceptance Threshold

The surrender level at which the test authenticates as successful — i.e., the control is deemed failed and a finding is raised. From the client's side, reaching this level = a control that must be remediated.

Authorization Ceiling

The maximum surrender level StrikePoint is permitted to reach. Always ≥ the pass threshold. Reaching it is the mandatory stop line — StrikePoint goes no further, whatever else is possible.

Example clause shape: Social Engineering — Pass Threshold: S2 (disclosure). Authorization Ceiling: S3 (controlled use), named approver: [CISO]. Stop on: any access to customer PII.

Consent scales with the ceiling. An S1 ceiling needs a standard signed scope; an S3–S4 ceiling adds action-specific written authorization, a named approver, secret-handling & destruction terms, and explicit stop conditions.
Every finding is reported with the rung it reached. "Reached S2 on the finance team; authorized to S3, stopped at client instruction" — unambiguous, auditable, and impossible to overstate or understate.
The ceiling is enforced by the platform, not by trust. In the SaaS model the authorization ceiling is a state on the engagement; actions above the agreed rung are simply not permitted to proceed.

Net effect: StrikePoint sells a defined, signed answer to "how do we know it worked, and how far did you go?" — for every methodology, every surface, every engagement. That is what turns a penetration test from a story into a product.