Start with the objective
An organization can own many security products yet struggle to say which unwanted action a specific business process must prevent. Answering that question improves the engagement before tools are selected.
Ross Anderson’s Security Engineering connects policy, mechanisms, assurance and incentives. This perspective treats protection as a system rather than a single product. [1]
Our own worked example
Fictional case: an accounts team wants to prevent one person from changing a supplier’s bank details and immediately authorizing a payment. Strong sign-in alone does not answer that question.
Define the two actions, roles and expected separation, then examine whether the agreed boundary holds in the tested workflow. This is an illustrative example, not a customer story.
A five-field decision brief
Our suggested template translates the perspective into a practical assessment request.
- Objective: which action must be prevented?
- Conditions: which roles and systems are covered?
- Control: what should limit the action?
- Evidence: which result would demonstrate that?
- Responsibility: who evaluates and addresses deviations?
Keep the conclusion bounded
When a test covers one workflow, the report should name that workflow. Other roles, interfaces and later changes remain separate questions. A bounded result is more useful than an unsupported universal verdict.
A retest returns to the original objective. Installing an update is a change; establishing the intended effect is the next assessment question.
Use literature for the right purpose
The chapter is a methodological source, not a current threat statistic. The fictional example and five-field brief are our own application of that perspective. Actual systems, sources and versions must be supplied for each engagement.
Related reading
Sources & further reading
Primary sources checked on 26.09.2026.
Sources and limitations are identified in the article.