Turning protection goals into security requirements

Protection goals are the starting point of any security planning. On their own, however, they are not enough to select suitable measures: only once it is clear which function has to be performed, under which conditions, and how this will be demonstrated does a verifiable security requirement emerge. This article shows how to plan the path from the protective task to the evidence.

A protection goal is not yet a requirement

Phrases such as “inform visitors in an emergency” or “public address available” appear in many planning documents. They express the right intention. For planning and procurement, though, they leave open what exactly has to be delivered: which areas are meant? Under what circumstances must the message get through? And how will anyone know that the service has been provided?

If these questions remain open, each party answers them in its own way. The client has the whole site in mind, the service provider the stage, the specialist planner the emergency sound system under the relevant standards. All of them can say “done” in good faith – and mean different things.

Read more: Measuring security quality: why functions matter more than equipment.

From protective task to evidence

A derivation in four steps helps. It is an editorial structure, not a standard, and can be applied to different protection goals:

Step	Guiding question	Example: informing visitors
Protection goal	What is to be achieved or prevented?	Visitors are informed in good time in an emergency
Function	What has to be delivered for this?	Announcements reach the affected areas and are intelligible
Conditions	Under what circumstances must the function work?	Specified areas, noise levels during the event, loss of power or network
Evidence	How will fulfilment be established?	Suitable measurement, test announcement in each area, trial run of the procedure

Clarify the function

The function describes what a measure is meant to achieve – regardless of which device or which organisation delivers it. This leaves room for different solutions, and comparison is based on performance rather than equipment.

Define the operating conditions

Whether a function works depends on the circumstances in which it is needed. The UK Health and Safety Executive (HSE) advises assessing the suitability of the venue or site, drawing up an audience profile and taking account of people who need additional support when assessing risks [1]. For the requirement, this means that areas, visitor groups and possible disruptions are named explicitly rather than tacitly assumed.

Read more: Procuring security technology: function first, then devices.

Plan the evidence from the outset

A verifiable requirement describes not only the performance expected but also how fulfilment is to be established. Depending on the function, this may involve calculations, measurements, documented inspections or a trial run of the procedure. For means of communication, the HSE recommends practical tests before the event begins [2].

In this way, “public address available” becomes a concrete planning task: reaching defined areas under specified conditions, informing people intelligibly and demonstrating the intended function in a traceable way.

This added precision makes it easier to select suitable technical and organisational measures. It also gives clients, specialist planners and service providers a common basis: everyone involved can see what performance is expected and how its fulfilment will be measured.

The specific criteria – for intelligibility or response times, for instance – have to be set by qualified specialists before they are applied to a particular deployment. Blanket values are no substitute for that decision. Evidence planned in this way also supplements any mandatory inspections and acceptance tests; it does not replace them.

Read more: Emergency PA at events: intelligible, multilingual and resilient.

A fictitious example

For a town festival, the client sets the protection goal that visitors are to be informed of any hazard. The first draft of the documents simply says: “Public address available”.

The revised version names the areas that announcements must reach, including entrances and waiting areas. It states that announcements must remain intelligible while the programme is running and must still be possible if the power supply is disrupted. Finally, it sets out how this will be demonstrated: an intelligibility check defined by specialists, a test announcement in each area before opening, and a run-through of the procedure from first report to announcement.

Only this version makes it possible to compare tenders and to establish on the day whether the agreed service has been delivered.

What precision brings to those involved

• Clients can see what they are commissioning and check it at acceptance.
• Specialist planners gain a clear basis for selecting and justifying technical and organisational measures.
• Service providers know how their performance will be judged and can shape their offer accordingly.

Roles and procedures can be described in the same way. The HSE lists emergency procedures and clearly assigned roles and responsibilities as part of planning [2]. A requirement can therefore also set out who decides on an announcement and who triggers it.

How MOVETOS OPS helps

MOVETOS OPS is the platform that connects cameras, loudspeakers and the team during an event. For verifiable requirements, these features are particularly useful:

• Reaching visitors: announcements are possible in five languages, even offline.
• Communication despite disruption: team coordination works without mobile networks, over the local network on site.
• Alert and announcement in one workflow: warnings appear with a snapshot from the location, together with a prepared announcement. The system suggests, a person approves.
• Evidence during operation: the deployment is fully documented – a basis for recording test announcements and procedures in a traceable way.

Which requirements apply and how they are to be demonstrated is decided by the client and the specialist planners; MOVETOS OPS supports implementation and evidence.

Checklist: is the requirement verifiable?

• The protection goal is named and worded separately from the measure.
• The function describes a performance, not a specific device.
• Areas, visitor groups and possible disruptions are stated explicitly.
• Suitable evidence is defined for each function: calculation, measurement, documented inspection or trial run.
• The criteria for the evidence have been set by specialists for this deployment.
• Timing and responsibility for the evidence are agreed.

Conclusion

A security requirement becomes verifiable when, alongside the protection goal, it names the function, the operating conditions and the evidence. Planning the evidence from the start makes it easier to choose measures and gives everyone involved the same yardstick.

The HSE guidance supports risk-based planning and testing; UK legal requirements are not presented as German obligations. The chain of protection goal, function, conditions and evidence is an editorial structure, and the example is fictitious.