The first question is nearly always the same: do you have a template? We do, and we are reluctant to hand it over. There is nothing secretive about that. A table of contents simply fails to answer the one question on which security concepts founder, namely how each chapter follows from the one before.
The structure is straightforward in principle. Three steps that build on each other: you establish what is at risk. You define what is to be protected. You describe how. Each step presupposes the one before it. Anyone who starts with the measures produces a shopping list rather than a concept. It still happens frequently, because that is where the tangible items sit and where something can be shown fastest.
This article sets out the three steps in detail and, because experience says it is the hardest question, how you get from one to the next.
Step 1: The risk analysis
What is actually surveyed
A risk analysis is produced on site. You would think that goes without saying. Of the concepts submitted to us for review, a substantial share was written without any site inspection.
The survey runs in four directions. Structural: construction, access points, storeys, condition, the places where the fabric of the building offers a way in. Surroundings: location, sightlines, neighbourhood, transport links, anything conspicuous in the area. Visitors: which groups use the area, how many, what they come for, and what triggers conflict on a recurring basis. History: what has actually happened in recent years. Assaults, break-ins, criminal damage, near misses.
Depending on the building, further directions are added, and they are forgotten more often than the four above: operating processes and critical time windows, access by suppliers and contractors, key and authorisation management, technical dependencies, and the question of which rooms hold sensitive information.
The fourth point is skipped most often and frequently yields the most useful findings. Not because the past repeats itself, but because documented incidents show where the weak points actually are, as distinct from where people assume they are.
Why the building determines which questions get asked
A municipal works depot and an immigration office both have visitors. They do not have the same visitors, and it would make no sense to ask the same things about both.
In SCVeridit, our survey tool, the building profile therefore determines which question set is applied at all. Building type and special circumstances such as social services, judicial functions, cash handling, permanent night operation or a statutory guarding requirement govern which questions appear and how heavily an identical answer then weighs. A checklist puts the same questions to everyone and treats every answer alike. A survey model takes account of the fact that heavy visitor pressure in an immigration office means something different from heavy visitor pressure at a works depot.
There is a second layer that is frequently missing. A building is not a single space. The citizens' service centre on the ground floor, the reception desk, the plant room, the social services department on the second floor: these are areas with different operating hours, different access and different risks. We record them individually as usage units, each with its own supplementary questions by type. The questions put about a server room are not the questions put about a waiting area, and what stays invisible at building level becomes visible here.
Four terms that need to be kept apart
Without this distinction it is impossible to trace later what a figure in the report actually represents.
The protected asset is what is to be protected: people, physical assets, operating processes, sensitive information. The threat is the event that may occur. The vulnerability is the property of the building that makes it easier for the event to occur or increases its impact, an unobserved side entrance for instance. The risk is the combination of the two, taking into account what protection already exists.
Mix these levels and you get an assessment that describes the threat picture in one place and the state of the building in another, with no way of telling which is meant at any given point.
The assessment itself
Every threat factor is rated on a scale from 0 to 4, from "not relevant" to "critical". Three rules make the difference between a defensible assessment and an arbitrary one.
Every level is described. Each level carries a sentence stating what it means for that particular factor, rather than a bare figure from 0 to 4. The differences between two assessors do not disappear, but they become markedly smaller, and the rating remains checkable afterwards.
Every value is justified. The justification appears in the report next to the figure. Anyone reading the concept sees not only the rating but the reasoning behind it. And can disagree with it.
Not assessed is not the same as assessed as zero. A skipped factor drops out of the calculation rather than passing as "unproblematic". Where zeros appear everywhere because nobody looked, the result comes out systematically too favourable.
The perspective a consultant does not have
A consultant spends a day in the building. The staff are there every day. They know which door sticks, which day of the week gets difficult, and which entrance stands open after hours when it should not.
We capture that perspective through a structured survey: a link without login, valid for a limited period, sent to the client's contacts, to those responsible for individual areas, and via an open collective link to staff in areas not yet covered at all. That last channel regularly brings to light areas nobody thought of during the site survey.
One point matters to us: not every answer is translated into a figure. Scale questions feed into the assessment. Yes/no answers and free text are considered on their merits and not calculated in, because forcing a yes/no answer into a score would be false precision.
Free text needs separate handling. Staff write down what they have experienced, complete with names, allegations and occasionally details of their own health. That does not belong unaltered in a report that will circulate in the organisation. We evaluate it on its merits, reproduce it in summary form without personal details, and quote verbatim only where the exact wording matters and nobody becomes identifiable. Purpose, voluntary participation, access and retention period are settled in advance, and depending on the arrangement the data protection officer and the staff council are to be involved.
And questions have a direction. "How safe do you feel?" and "How high do you rate the risk?" point in opposite directions at the same numerical answer. That is built into the system rather than left to chance in the wording.
Step 2: The protection objectives
This is where it is decided whether the analysis becomes a concept.
A protection objective answers the question: what exactly is to be achieved? "More security" does not answer it. What is meant is a state that can be described and verified later. The test is simple: can you establish in a year's time whether the objective was met? If not, what you have is a statement of intent.
Where the analysis is good, the protection objectives follow from it almost by themselves. A high rating for conflict potential in the citizens' service centre leads to an objective involving response time and support. A high rating for burglary risk outside core hours leads to an objective involving detection and intervention. Where the protection objectives cannot be derived from the analysis, the analysis was too vague.
The reverse also holds: protection objectives with no assessed threat behind them do not belong in the concept. They are usually left over from a template.
Step 3: The measures
Only now does it come to technology, organisation and personnel, and in that order, subordinate to the objectives rather than ahead of them.
Technology is assessed by effectiveness, not by presence. We record fourteen categories, among them internal and external video, intruder alarms, electronic and mechanical access control, emergency and panic alarm systems, lighting, perimeter protection and alarm transmission, each on a four-point scale: not present, present but not effective, partially effective, effective.
We deliberately treat the first two levels alike, and the benchmark is always the protection objective. A camera without a monitored connection produces recordings. For subsequent investigation that is worth something; for intervention while the incident is under way it is worth nothing, because at that moment nobody is watching. Where it appears in the concept under prevention of danger, it is booked in the wrong column. The same applies to an alarm system that goes unarmed out of convenience. Installations that exist only on paper do not belong in a security concept, at least not on the credit side.
Each category also records which area it covers and when it was last tested. An intruder alarm last inspected six years ago is a different statement from a freshly commissioned one, even though the form says "present" in both cases.
Organisation and personnel close the gap that technology leaves open. Our assessment model reflects this explicitly: even a technically excellent building can reduce its risk through technology only up to a point. Beyond that it becomes a question of presence, responsibility and capacity to respond. Technology relieves personnel; it cannot replace them.
From the protection objectives and the remaining gap, the specific personnel positions then follow: by area, with task, required qualification and actual hours on duty. From those in turn a cost framework can be derived, based on the pay rates in force at the assessment date rather than on an estimate.
Who reads the concept later
A security concept rarely has a single audience, and the audiences expect different things. Three occur particularly often.
The licensing authority checks whether the measures match the threats described and whether responsibilities are settled. It reads the connections, not the detail.
The insurer is interested in the technical provision and its condition. A documented inspection date counts for more here than a lengthy description.
The oversight body, whether that is the council, a supervisory board or the audit office, checks the reasoning. Why this measure, why this cost, why not less. This is where it is decided whether the derivation was documented in a way that can be followed, or whether all that remains at the end is a result.
Depending on the building, others join them: the occupational safety specialist, data protection, the staff council, facilities management, the contracted service provider.
For the third audience, two rules have proved themselves in our work. The first: where technical provision pulls a high risk sharply downwards, we require a written justification. Large reductions are the points at which an auditor asks questions, and without a justification we do not close a survey. The second: a thin data base is disclosed. Where only a few factors could be assessed, the limited significance appears in the report rather than disappearing behind a tidy figure.
Finally: the report as a document
When the survey is closed, a complete data snapshot, the rendered report and a checksum over it are produced in a single operation. From then on the survey is read-only. Changes create a new version, linked to the previous one.
The practical benefit shows up years later. Anyone opening the report in 2031 can verify that it is unchanged. Later alterations to master data do not reach back into it. And if a threat factor is eventually removed from the catalogue, it does not vanish from the reports that assessed it.
What comes after the document
A completed report is not yet an altered security situation. Between the two lies the part that most often stays open in concepts.
The measures need an order, because it is rare that everything can be implemented at once, and that order follows from the level of assessed risk rather than from the level of cost. Every measure needs a named responsible person and a deadline. Whatever is not implemented remains as residual risk, and that residual risk should be stated explicitly and signed off by management rather than running along unspoken. And effectiveness needs to be verified: reporting routes through an exercise, technical installations through an activation with a record.
The trigger for an update is rarely the calendar. Building works, changes of use, altered opening hours, a new access system, an incident or even a near miss all weigh more heavily than the passing of three years.
The benchmark for all of this is simple. A security concept is a document that in the worst case ends up in a post-incident review: after an event, in an inspection, before a court. In that situation it matters less whether it looks good. What matters is whether it remains possible to trace who decided what, when, and on what basis.