Set security control testing priorities by looking first at controls whose failure could leave people or essential services exposed. Focus on controls you rely on heavily but have little current evidence for. The easiest control to inspect is not necessarily the one that most needs attention.
This is a way to prioritise a limited assurance programme. It does not replace mandatory inspections, contractual checks or maintenance requirements. Start by identifying those commitments so that a new risk-based testing plan does not quietly displace them.
Begin with a consequential event
Choose an event from your current assessment, such as unauthorised access to a restricted work area or loss of a service needed during an incident. Be specific enough to identify what would have to work to prevent the event or limit the resulting harm.
Avoid starting with a long inventory of devices. A list of cameras, locks and radios tells you what you own. It does not explain which failure would materially change the outcome of a scenario.
For each important scenario, identify the controls you rely on. Include actions by people and arrangements delivered by a landlord or supplier. If a control is only planned, keep it out of the list of measures currently protecting the operation.
Trace the sequence through the controls
A simple bow-tie can help separate controls that act before a loss-of-control event from those that manage consequences afterwards. The UK Civil Aviation Authority's introduction to bow-tie analysis explains this relationship between threats, barriers, the top event and consequences.
Use the diagram to ask a practical question: if this control failed, what would still stand between the event and serious harm? You may find a control has little backup, or that several apparently separate protections rely on the same person, power supply or communication channel.
Keep the analysis proportionate. A short sequence written in ordinary language can be enough. You do not need an elaborate diagram to recognise that an alert and its follow-up call both depend on an unavailable contact.
Consider four reasons to bring a test forward
First, consider the consequence of relying on a failed control. A weakness affecting a critical service deserves attention even if the control has not recently generated complaints.
Second, consider dependence. A control may be important because it supports several others. A current contact list, for example, can be a dependency of multiple response arrangements.
Third, consider change. New staff, altered operating hours, a software update or a different provider can invalidate older evidence. Record what changed and why it matters rather than automatically discarding every previous test.
Fourth, consider uncertainty or adverse evidence. Repeated exceptions, an incomplete test or inconsistent records can justify checking a control earlier. A clean-looking dashboard is less persuasive if nobody can explain how its results were obtained.
These are decision factors, not a universal scoring formula. If you use a score, retain the reasons behind it. A numerical total should not hide a known failure with potentially serious consequences.
Work through an example
The following fictional office has a small security team and time for two additional assurance activities this month. Required maintenance continues separately. The table illustrates a prioritisation discussion, not a prescribed ranking for other sites.
| Control and current evidence | Reason for attention | Decision |
|---|---|---|
| After-hours incident notification has not been exercised since the provider changed. | Several response actions depend on the notification reaching the authorised duty manager. | Test the notification and escalation chain first, with the provider's agreement. |
| Access revocation records include unresolved entries for completed contractor work. | Current evidence suggests permissions may exceed approved need. | Review and verify those exceptions now; sample the wider process according to the findings. |
| A cabinet inspection was completed recently and no relevant conditions have changed. | The evidence remains relevant to the limited claim tested. | Keep the planned review date; reconsider if the use or custody arrangement changes. |
| A new reception sign has not been checked against the brand guide. | Presentation needs attention, but it does not resolve the immediate uncertainty about response and access. | Assign a routine correction without consuming one of the two assurance activities. |
The team is not declaring the remaining controls unimportant. It is explaining why two questions deserve earlier evidence. That explanation makes the decision reviewable when someone asks why their preferred check was deferred.
Look for a shared point of failure
Separate lines on a diagram can create an impression of independence that does not exist. An alarm, camera and access-control server may all need the same supporting service. Two escalation routes may terminate with the same person.
Ask each owner what their control needs to operate. Record dependencies only at the detail needed for the assessment and protect the resulting information. Public reports should not expose real configurations or weak points.
Where several controls depend on one service, assess that dependency and the fallback arrangements. Do not assume that successfully testing each device during normal operation establishes resilience when its supporting service is unavailable.
Any exercise involving loss of power, communications or an operational service needs a suitable plan and approval from the responsible technical and safety owners. A desk-based examination may be the appropriate first step.
Turn priority into a defined test
“Test the alarm” is not yet a useful work instruction. State the claim, conditions, expected result, responsible people and limits. For the fictional office, the claim could be that an agreed test notification reaches the authorised duty manager and that an unanswered first contact triggers the approved escalation route.
Record the evidence needed to decide whether that happened. Agree the exercise boundaries and stop conditions. The purpose is to obtain reliable evidence without creating a real emergency or disrupting another protective function.
Also record what you will do with a failure. A test that reveals a serious gap needs an interim protection decision and an owner, not simply a red mark in a spreadsheet.
Keep deferred work visible
Maintain a short list of tests you have deferred, with the reason, owner and reconsideration trigger. A reasonable deferral can become unreasonable when conditions change. “We did not get to it” is a different explanation from a conscious decision supported by current evidence.
Review the priority list after incidents, significant change or failed tests. Do not restart the entire programme whenever a new concern arrives; assess whether the new evidence changes the order or scope of the work.
For your next assurance meeting, bring one serious scenario and the controls on which it depends. Identify the most consequential unanswered performance question, then assign a safe test that can answer it.
A bow-tie analysis can show where each control acts; an accountable treatment schedule can carry the resulting priorities into delivery.
The free SRMBOK Bow-Tie Field Kit includes a review checklist and guidance for connecting a bow-tie with a risk register and controls library. Use it to check the barriers you are relying on, then record your own evidence and assurance priorities. The diagram supports the decision; it does not establish that a barrier works.