Choose an engagement by the decision it needs to support. These eight disciplines address different kinds of uncertainty, from a specific application boundary to the organisation’s response within an agreed scenario. Start with the question, then define the evidence and scope.
An assessment becomes useful when the people commissioning it agree what they need to learn. “Test our security” leaves too much unspecified: the environment, the starting assumptions, the operational boundaries and the decision that follows may all be different for different owners.
Use the descriptions below to identify the closest question. Then read the full discipline page for preparation, outputs, a worked example and limits. Some engagements can combine elements, but that combination should be deliberate. Adding more labels does not automatically produce better coverage or a clearer result.
Examine how an agreed adversary objective interacts with technical controls, detection, investigation and decision-making. The scope defines starting assumptions, permitted activity and the evidence needed to interpret the result.
Choose this when the question concerns a connected path and the organisation’s response, rather than a catalogue of isolated vulnerabilities.
Read the complete discipline ↗
Investigate a defined application, service or environment with known constraints. Findings should explain the observed condition, its preconditions, the consequence demonstrated and what remains unverified.
Choose this when an engineering owner needs contextual technical evidence to support a release, change or improvement decision.
Read the complete discipline ↗
Look at the relationships between users, roles, tenants, workflows and the data they are intended to access. Prepare representative accounts and test data so the assessment reflects how the application is actually used.
Choose this when the central question concerns application behaviour, business logic or access across web and API boundaries.
Read the complete discipline ↗
Bring account structure, identity, exposure, configuration and logging into the same review. Describe exactly which environment is included and which responsibilities or dependencies sit elsewhere.
Choose this when the organisation needs to understand how its cloud controls fit together under a defined scope.
Read the complete discipline ↗
Examine how people, workloads and administrative roles obtain and use access. The useful output is an understandable relationship between intended privilege, observed conditions and the owners who can change it.
Choose this when access relationships and cross-environment trust are the main source of uncertainty.
Read the complete discipline ↗
Bring assessment and defensive participants together around a selected scenario. Observe expected signals, investigate differences and agree changes while the context is still available to everyone involved.
Choose this when the primary aim is shared learning and a practical feedback loop with the detection or response team.
Read the complete discipline ↗
Follow an agreed event through available telemetry, detection logic and alert context. Record what happened at each stage so a missing outcome is not prematurely blamed on the wrong component.
Choose this when a team needs to verify a specific detection expectation and identify the next improvement to test.
Read the complete discipline ↗
Reconcile organisation-owned assets with what is externally visible. Distinguish association from verified ownership, and distinguish inventory work from permission to perform further technical testing.
Choose this when unclear asset ownership or a fragmented external inventory prevents a well-bounded follow-up assessment.
Read the complete discipline ↗A technical assessment may identify a condition that merits a detection exercise. An identity review may reveal a trust relationship worth examining within a broader scenario. Keep those questions distinct in the plan: each needs its own assumptions, evidence and owner.
Discuss readiness as well as ambition. An organisation with uncertain asset ownership or unavailable test accounts may benefit from preparation before an adversary-led exercise. A detection team seeking immediate collaborative improvement may prefer purple teaming to a less transparent scenario. The right starting point depends on the decision and the operating context, not a hierarchy of impressive-sounding services.
Record what the selected engagement will leave unanswered. That list helps the next team understand the result and prevents a bounded assessment from becoming an accidental claim about the whole organisation. The assessment-selection guide walks through these choices in more detail.
Read the assessment-selection guide ↗Start with the decision, the environment and the constraints. Create a scope brief you can download, review with your team and refine before any engagement is considered.
