What the conversation should produce.
- A scope document that lists in-scope systems, out-of-scope systems, and the rationale for each boundary decision.
- A claims matrix that maps each tested security claim to the methods used and the evidence that would confirm it.
- A verification plan that specifies which findings will be retested, what evidence counts as sufficient, and who performs the verification.
The idea behind adversary assurance
Adversary assurance treats security testing as a structured way to test assumptions rather than a performance review of a team. The approach starts by identifying which claims about the system actually matter to the organisation, then designing evidence that speaks directly to those claims. This means moving away from broad checklists and toward focused questions that reflect real operational risk, which changes how findings are framed and what actions follow.
The term describes an emphasis on evidence, not a promise that every attack path or consequential claim has been examined. Each engagement still needs a specific objective, appropriate methods and clear limits. Some questions may be addressed through configuration review or collaborative observation rather than an adversary-style scenario. What connects them is an explicit basis for the conclusion: the agreed conditions, the observations and the areas that remain uncertain. That record gives decision-makers a way to assess confidence rather than merely receive reassurance.
Scope as an essential design decision
Scope is not an administrative formality but the central design decision that determines what the assessment can and cannot answer. A well-defined scope specifies which systems, which threat models, and which claims are in play, and it explicitly lists what falls outside the engagement. This prevents the common failure where findings are later misinterpreted as covering territory the assessment never intended to examine, which creates a false sense of completeness.
The scope document should be written before testing begins and signed by the people who own the systems and the people who will act on the results. It must describe the authority under which testing occurs, the methods that will be used, and the boundaries that protect production systems. When scope is treated as a design document rather than paperwork, the resulting evidence is defensible and the engagement stays focused on the questions that actually matter.
Making uncertainty visible in evidence
Every assessment produces a mix of observed facts, reasonable hypotheses, and areas that could not be tested. Good reporting separates these categories explicitly, so readers can see which findings are confirmed and which are inferred from available evidence. This transparency prevents findings from being treated as proof of something they were never designed to prove, and it gives decision-makers a clearer picture of where additional investigation would be valuable.
Uncertainty should be stated in the language of the report itself, not buried in footnotes or omitted entirely. When a finding is based on a hypothesis rather than direct observation, the report should explain what evidence supports the hypothesis and what would be needed to confirm it. This practice builds trust because it shows that the assessment is reporting what it actually found rather than presenting conclusions that exceed the evidence.
Collaboration around system owners
The people who own and operate the systems are the ones who must interpret findings and decide on remediation, so collaboration should be structured around them rather than around the assessment team. This means regular briefings, shared access to evidence, and a process for discussing findings before they are finalised. When system owners are involved throughout, the resulting recommendations are more practical and the organisation retains control over how findings are communicated externally.
Collaboration also means recognising that system owners may have legitimate reasons for certain configurations or constraints that an outside reviewer would not know about. A useful engagement treats these constraints as information to be incorporated into the analysis rather than obstacles to be overcome. This approach produces findings that reflect the real operating environment and avoids recommendations that are technically sound but operationally impractical.
Connecting improvement and verification
Verification should not be treated as a separate phase that happens after remediation is complete, but as a design feature built into the improvement process from the start. The assessment should specify which findings will be verified, what evidence will count as sufficient, and how the verification will be conducted. This prevents the common pattern where remediation is claimed but never independently confirmed, leaving the organisation with unresolved risk that appears resolved on paper.
The connection between improvement and verification also means that the original scope and the verification criteria should reference the same claims and the same systems. When verification is aligned with the initial assessment, the organisation can trace each verified finding back to the question it was meant to answer, which makes it possible to assess whether the overall engagement achieved its stated purpose rather than simply completing a list of tasks.
Start a focused security conversation
RIFT helps organisations turn security concerns into clear, authorised assessment objectives. Start with the business decision, the systems involved and the evidence your team needs. Red teaming, penetration testing, cloud and identity review, and defensive validation answer different questions; choosing the right approach is part of the work, not an afterthought.
Email [email protected] to discuss your requirements. We can use the scope brief as a starting point to identify the technical owners, agree boundaries and define the next step. Keep the initial message high-level: sensitive architecture, credentials and customer data belong in an agreed secure exchange, not an introductory email. The objective is a practical engagement with clear authority, useful evidence and an actionable handover.
Illustrative scenario: assessing a new customer portal
A mid-sized organisation has launched a customer portal that processes personal data and payment information. The engineering team believes the portal is secure because it was built with modern frameworks and reviewed internally, but the risk committee wants independent assurance before the product is marketed publicly. The assessment is scoped to the portal and its immediate integration points, with explicit exclusion of the legacy billing system it connects to. This scenario is illustrative and describes an illustrative situation, not a real engagement.
- Decide which claims about the portal matter most to the risk committee and write those claims into the scope document so the assessment tests the right questions rather than every possible vulnerability.
- Determine whether the assessment will include the legacy billing integration or exclude it, and document the exclusion with a clear explanation of why that boundary was chosen and what it means for the findings.
- Agree with the engineering team that they will review draft findings before the final report is issued to its agreed recipients and that any hypothesis-based findings will be clearly labeled so the final report does not overstate what was directly observed.
This scenario establishes that scoping decisions, collaboration practices, and the treatment of uncertainty are concrete choices made at the start of an engagement, not after testing is complete. It does not establish that any particular portal is secure, that the illustrative decisions are the only correct ones, or that the described approach would produce the same results in a different organisation.
Useful decision table for scoping choices
| Question | What to establish | Useful output |
|---|---|---|
| Which systems are in scope | The specific systems, interfaces, and data flows the assessment will examine, and the explicit exclusions | A signed scope document listing in-scope and out-of-scope assets with rationale for each exclusion |
| What claims are being tested | The concrete security claims the organisation wants evidence for, written as testable statements | A claims matrix that maps each claim to the methods that will test it and the evidence that would confirm it |
| How findings will be verified | Which findings require verification, what counts as sufficient remediation evidence, and who performs the verification | A verification plan that references the original claims and specifies the evidence format for each verified finding |
Scroll the table horizontally on smaller screens.
Useful questions.
Does this approach replace a traditional penetration test?
No. Adversary assurance frames evidence and improvement, not a replacement for a particular assessment discipline. A well-scoped penetration test can follow the same principles, as can a collaborative defensive exercise or another bounded review. The useful question is whether the chosen work addresses the organisation’s objective and reports its limits clearly.
How do I know if an assessment provider is following these principles?
Look for a scope document that is written before testing begins and signed by system owners, a report that separates observed facts from hypotheses, and a verification plan that references the original claims. If a provider cannot show you these artefacts or describes their work in terms of completed tasks rather than tested claims, the engagement may not align with the principle of adversary assurance.
Further reading: NIST SP 800-115: testing and assessment guidance. This independent resource provides background; no affiliation, certification or endorsement is implied.