Geschäftsmann hält ein Tablet mit virtuellen Daten-Diagrammen und Sicherheits-Dashboards vor nächtlicher Skyline

Physical Security Consulting: When It Pays Off, How It Works and What to Look For

15.09.2026 | 6 min read

Physical security consulting is usually called in once a specific solution is already on the table: Which access control system do we need? How should the perimeter be protected? Do we need to add cameras?

That means the conversation often starts one question too late.

Before anyone decides on individual controls, three things have to be clear: what is being protected, which threats and dependencies are relevant, and what a security incident would actually do to operations. Only then can you establish what level of protection is appropriate.

The value of security consulting does not lie in producing as many recommendations as possible. It lies in translating protection objectives and risks into decisions the organisation can follow and defend.

For companies, that distinction matters. Good security consulting does not simply hand over a package of measures. It shows why a control is needed, what the alternatives are, which dependencies have to be accounted for and what residual risk remains.

What security consulting actually means

Security consulting is the structured analysis of protection requirements, risks, existing controls and operational conditions, carried out to prepare sound decisions about physical security.

The scope varies widely with the question being asked. Security consulting services may assess an existing security architecture, examine risks systematically, develop an overarching security plan, or prepare the decisions that feed into later detailed design.

What matters is therefore not the label on the service, but the specific brief.

Before work starts, the following should be settled:

  • Which question is the engagement meant to answer?
  • Which sites, processes or assets are in scope?
  • How deep does the review need to go?
  • Which results are expected?
  • Which services are explicitly excluded?
  • Which other disciplines need to be involved?

This demarcation matters because “security consulting” covers very different services in the market — from a compact site review to multi-year support for complex security programmes.

When security consulting pays off

Not every security question calls for a full consulting project. At the same time, it is usually too late to start thinking about the security plan once specific systems have already been selected.

Demand for a security consultant typically arises in four situations.

When the existing level of protection can no longer be explained

Security programmes tend to grow over years. Buildings are extended, cameras added, access zones redrawn, new service providers brought in and processes adjusted.

Each individual change may have been sound. That does not mean the system as a whole still matches today’s protection requirements.

The questions that surface at this point are:

  • Which areas and processes are genuinely critical?
  • Which threats were considered when the current architecture was built?
  • Why were these particular protective measures chosen?
  • How do structural, technical, organisational and personnel controls work together?
  • What dependencies exist between individual systems?
  • Which residual risks are being accepted deliberately?

If the immediate goal is simply to establish where the weak points and the areas needing closer review are, a Resilience Health Check — a structured security analysis within an agreed scope — is often the better starting point. A full consulting project is not automatically step one.

When buildings, processes or the organisation change

New builds and major refurbishments are obvious triggers. Organisational change affects existing protection arrangements just as much.

Examples include:

  • site expansions or consolidations,
  • changed production and logistics processes,
  • new operating hours,
  • greater use of external service providers,
  • new user groups,
  • revised access and visitor processes,
  • or the networking of security systems that were previously separate.

Bringing in a security consultant early makes it possible to build requirements into planning and operations before technical or structural decisions become hard to reverse.

Early advice is not automatically cheaper. Its value depends on complexity, protection requirements and the size of the investment. On security-critical projects, though, it helps avoid later redesign work and isolated point solutions.

When incidents point to structural weaknesses

Break-ins, theft and sabotage are obvious triggers. Recurring irregularities are reason enough on their own:

  • access rights are not revoked in time,
  • doors are left open unintentionally,
  • false alarms occur regularly,
  • intervention processes are ambiguous,
  • standing instructions contradict one another,
  • or security events are detected but never properly evaluated.

After an incident, the visible weak point is rarely the whole story. The decisive question is whether a systemic problem sits behind it.

When regulatory or normative requirements need to be put in context

Depending on the business context, security measures may also be tied to regulatory, normative, insurance or contractual requirements.

These requirements must not be conflated.

ISO/IEC 27001 sets out the requirements for an information security management system and is built on a risk-based approach. Requirements under the German BSIG and NIS2 address cybersecurity and organisational risk management in particular. The German KRITIS Umbrella Act (KRITIS-Dachgesetz), by contrast, deals with the physical resilience of critical installations and — depending on how an operator is affected — calls for risk analyses and proportionate resilience measures.

For critical infrastructure operators this separation is especially important: there is no single “KRITIS certificate”. Which rules apply, and what they require, has to be assessed against the specific entity, installation and legal basis.

Security consulting helps translate technical requirements into a security and operating context. It does not replace legal advice, nor a formal regulatory or certification audit.

What security consulting services can include

Security consulting is not a standardised package. Different services are required depending on the decision at hand.

Site and security analysis

A security analysis examines the current state and identifies weak points, risks and dependencies within an agreed scope.

It works either as a compact position assessment or as the starting point for a deeper engagement.

Risk and threat analysis

Here, relevant hazards, threat scenarios, vulnerabilities and potential impacts are examined systematically.

The goal is not to list every conceivable scenario. It is to identify and evaluate the risks that are genuinely relevant to the assets and processes in scope — which is what makes a security risk assessment useful rather than exhaustive.

Developing the security plan

Protection objectives and the risk assessment together define a target state.

A security plan describes, for example:

  • security objectives,
  • security zones,
  • the protective functions required,
  • organisational responsibilities,
  • alarm and response processes,
  • and how structural, technical and personnel controls work together.

At this stage it answers the question of what protective effect is needed — not which specific product should be installed.

How these elements come together for a specific site is covered in the article on building security.

Detailed design

Detailed design turns conceptual requirements into a solution that can actually be built.

Depending on the project, that can include functional specifications, system architectures, interfaces, drawings, quantities, scopes of work or acceptance criteria.

Consulting and detailed design are closely linked but serve different purposes: the security plan defines the protective effect required. Detailed design specifies how it is delivered.

The exact scope of design work has to be agreed project by project.

Technical support for tendering and procurement

A security consultant can also support the technical description of the services required and the technical evaluation of the bids that come in.

One boundary matters here: technical support during a tender or bid evaluation does not replace procurement law advice. Public-sector clients in particular must address legal procurement requirements separately.

Implementation support and quality assurance

Depending on the project, security consulting can extend into implementation.

That can include:

  • reviewing design stages,
  • coordinating security-relevant interfaces,
  • assessing changes and deviations,
  • attending functional testing,
  • checking documentation,
  • or supporting handover and acceptance.

This kind of support earns its place on complex projects. It is not, however, a defining feature of professional security consulting.

Depending on governance, investment volume and protection requirements, a deliberate separation between consulting, design, installation and independent review can be the better arrangement.

How a security consulting project typically runs

There is no universal phase model. Method and depth have to match the question being asked.

A sound consulting process does, however, follow a traceable decision logic.

1. Define the question and the scope

The starting point is not the site walk-through. It is clarifying the brief.

Which decision is the engagement meant to support?

For example:

  • Is the existing security plan still appropriate?
  • What risks exist at a new site?
  • Which protective functions need to be improved?
  • How do we develop a consistent security standard across several sites?
  • Which requirements need to feed into a later design phase?

The next step is to define which sites, buildings, processes, systems and interfaces form part of the investigation.

This scope definition prevents large volumes of information being gathered without a decision to support.

2. Determine protection objectives and critical functions

The next question: what actually needs protecting?

Protected interests may include:

  • people,
  • buildings and physical assets,
  • technical installations,
  • sensitive information,
  • production and supply processes,
  • and the availability of critical services.

Not every asset needs the same level of protection.

For operators of critical installations, this functional view is becoming more important: what counts is not only the installation itself, but the service or process whose failure would cause significant impact.

3. Capture the current state

The baseline review draws on different sources of information depending on the project.

These can include:

  • existing security and emergency plans,
  • building and site drawings,
  • access and zoning arrangements,
  • technical documentation,
  • alarm and escalation plans,
  • authorisation processes,
  • incident data,
  • standing instructions,
  • interviews,
  • and site walk-throughs.

The decisive comparison is between documented and lived security.

A formally clean process counts for little if it is not followed day to day. Conversely, informal arrangements that work in practice create risk when responsibilities and decision paths are undocumented.

4. Assess risks and dependencies

Sound risk management involves more than rating events by likelihood and severity.

ISO 31000 describes risk management as a systematic process covering the identification, analysis, evaluation, treatment, monitoring and communication of risk, and expects that process to be adapted to the organisation and its context.

For physical security, the following are typically relevant, depending on the threat picture:

  • threat scenarios,
  • potential attackers and their capabilities,
  • exposure,
  • structural, technical or organisational vulnerabilities,
  • protective measures already in place,
  • potential impacts,
  • dependencies between systems and processes,
  • cascade effects,
  • and uncertainties in the assessment itself.

Where deliberate attack is concerned, risk cannot always be reduced to a statistical probability. Attackers choose their target, method and timing. The assessment method therefore has to fit the threat picture and the decision it serves.

For critical infrastructure, dependencies deserve particular attention. Both the European CER Directive (EU) 2022/2557 and the German KRITIS Umbrella Act follow a risk-based resilience logic that takes relevant natural and human-made risks — and dependencies — into account.

5. Develop the target state and the options

A risk analysis does not produce a technical solution on its own.

The first question is which protective function needs to improve.

Possible options include:

  • restructuring security zones,
  • changing routing and access processes,
  • managing authorisations more rigorously,
  • improving detection,
  • reorganising alarm assessment,
  • adjusting the capacity to respond with personnel,
  • increasing structural resistance,
  • building in redundancy,
  • or improving documentation and training.

Security planning is systemic by nature.

ISO 22340 describes protective security accordingly, as the interplay of governance, personnel, information, cyber and physical security. ISO 22342 sets the development of security plans in the context of organisational risk management.

Which controls are suitable depends on the protection requirements and the operating context.

6. Prioritise controls and document decisions

Not every weak point carries the same weight, and not every improvement has to be made immediately.

A sound action plan should therefore distinguish clearly between:

  • short-term action,
  • organisational improvements,
  • areas needing deeper review,
  • planned investment,
  • and residual risks accepted deliberately.

For every relevant control, the objective, priority, ownership and any outstanding decision should be visible.

Larger investments warrant a comparison of options. That comparison should not stop at capital cost. It should also cover:

  • protective effect,
  • operability,
  • maintenance and follow-on costs,
  • interfaces,
  • feasibility,
  • impact on users and processes,
  • and remaining risk.

What a good consulting result looks like

The value of a security consulting engagement is not measured in the page count of the final report.

What counts is whether the client can make better decisions afterwards.

Depending on the brief, suitable results include:

  • a management summary,
  • documented starting position and scope,
  • protected assets and protection objectives,
  • assumptions and assessment basis,
  • prioritised weak points,
  • risk and threat assessment,
  • target state or security plan,
  • options for delivering it,
  • decision criteria,
  • prioritised action,
  • responsibilities,
  • open technical questions,
  • residual risks accepted or still to be treated,
  • and requirements for any subsequent design phase.

Results also have to be usable at different decision levels.

The board needs a defensible basis for setting priorities and releasing investment. Technical owners need requirements concrete enough to act on.

How to recognise a physical security consultant worth hiring

Consulting quality cannot be read off a brand name or a single certification.

Several criteria matter.

The engagement starts with the problem, not the product

The first conversation should establish which question is to be investigated.

Specific product recommendations made before protection requirements, site and risks are understood need explaining.

The method is transparent

Companies should be able to understand:

  • which information is needed,
  • how observations are evaluated,
  • how risks are classified,
  • which criteria drive prioritisation,
  • and how assumptions and uncertainties are documented.

A method does not have to be maximally complex. It has to fit the decision at hand and be applied consistently.

Recommendations come with reasoning

A recommendation should make clear:

  • which problem it addresses,
  • which protective function it improves,
  • what the alternatives are,
  • which dependencies apply,
  • and what risk remains afterwards.

Terms like “best practice” or “state of the art” are not a substitute for that reasoning.

The experience fits the project

References are worth something when they are genuinely comparable to your own project.

Relevant factors include:

  • sector,
  • type of installation,
  • protection requirements,
  • project size,
  • regulatory environment,
  • and the consulting team’s actual role.

Formal qualifications and certificates are useful indicators of competence. They do not replace checking whether the experience and method fit the task.

Limits are stated openly

Professional consulting should name:

  • which topics were examined,
  • which topics were outside the brief,
  • which information is missing,
  • which assumptions were made,
  • where uncertainties remain,
  • and when additional expertise is needed.

At the interfaces with data protection, fire safety, occupational safety, IT/OT security, building law or specialist regulatory questions, an interdisciplinary approach is often necessary.

Video surveillance, biometric access control and personal access data, for instance, bring data protection requirements of their own. Physical security consulting does not replace an independent data protection assessment.

Vendor independence: what counts is transparency about interests

Vendor independence is frequently cited as a mark of quality in security consulting. The label alone is not enough.

A company can advise independently of particular products or manufacturers and still have a commercial interest in taking on the design, integration or operation later.

That is not a problem in itself. It does have to be transparent.

Clients should therefore check:

  • Are commercial interests disclosed?
  • Are requirements written as product-neutrally as possible?
  • Are viable alternatives considered?
  • Are the consulting, design, sales and delivery roles clearly separated?
  • Are decisions and deviations documented?
  • Do the key data and decision records stay with the client?
  • Can an independent review be brought in where needed?

An integrated delivery model has real advantages: fewer interfaces and end-to-end technical accountability. Where investment is large or protection requirements are especially critical, an additional independent review is worth the effort.

The question is not whether everything comes from one supplier. It is whether roles, interests and decisions are governed transparently.

Telling consulting, design, guarding and audit apart

These services should be clearly separated at the point of contracting.

Security consulting analyses protection requirements, risks and options, and prepares decisions.

Detailed design specifies requirements far enough that technical or structural measures can be built.

Installers and integrators deliver the planned systems and make them work technically.

Security services handle operational tasks such as reception, patrols, alarm follow-up, intervention and guarding.

Audit and testing assesses, within a defined scope, whether stated requirements are met or particular controls have been implemented effectively.

These roles can sit with different companies or within an integrated delivery model. What matters is not the organisational form, but a clear definition of scope, responsibility and interfaces.

What to settle before you appoint a security consultant

Most later misunderstandings arise not during the analysis, but from a poorly defined brief.

Before appointing a consultant, settle at least the following:

  • Objective: which decision should the engagement enable?
  • Scope: which sites, installations, processes and systems are covered?
  • Depth: orientation, detailed risk analysis or concrete design?
  • Method: against which criteria is the assessment made?
  • Deliverables: which results and documents are expected?
  • Interfaces: which disciplines are involved?
  • Exclusions: what is explicitly outside the scope?
  • Roles: who advises, who designs, who decides and who delivers?
  • Data basis: which information does the client provide?
  • Handling change: how are new findings or scope changes dealt with?
  • Quality assurance: how are results reviewed and signed off?

That turns security consulting itself into a controllable process.

These are exactly the points we work through with you: objective, scope, depth of review and expected results are agreed together, before any conversation about services or controls. Get in touch — the initial conversation is without obligation.

When a Resilience Health Check is enough — and when you need deeper consulting

Not every organisation needs a full risk analysis or a new security plan straight away.

Where the immediate question is how robust the existing security architecture is, the Resilience Health Check is a suitable entry point.

Within an agreed scope, it examines physical and organisational security, identifies weak points, makes an initial risk classification and derives prioritised recommendations.

Deeper security consulting is typically required when:

  • threats and risks have to be analysed in detail,
  • protection objectives are not yet defined robustly,
  • a new security plan is to be developed,
  • different options have to be evaluated against one another,
  • several sites need to be harmonised,
  • a detailed design phase has to be prepared,
  • or regulatory and specialist questions need in-depth investigation.

The Health Check and security consulting are not competing services. They work at different depths and build on one another.

Security consulting from e-shelter security

e-shelter security supports organisations in analysing and developing their physical security structures.

Depending on the starting position and the question, the entry point is either the Resilience Health Check or a deeper consulting engagement. The aim in both cases is to translate protection requirements, risks and operational conditions into requirements and decision records the organisation can act on.

What follows from that — developing the security plan, detailed design or implementation support — depends on the project and is scoped accordingly. Explore our solutions for the full service picture.

Conclusion: good security consulting creates the ability to decide

The central question in a security consulting engagement is not: which security technology should we buy?

It is: which risks do we have to control, what level of protection does that require, and which controls are appropriate under our operating conditions?

Only on that basis can technical, structural, organisational and personnel measures be evaluated sensibly.

Sound security consulting therefore does more than make recommendations. It sets out the assumptions behind them, the alternatives available, the interests involved and the residual risks that remain.

Its real value lies in the organisation’s ability to decide.

Good security consulting does not simply supply a solution. It makes clear why a particular decision fits the protection requirements at hand.

e-shelter security designs, integrates and operates physical security independently of any manufacturer — from risk analysis through technical design to certified operation. If it is still open how deep the review needs to go, the Resilience Health Check is the fastest way in. If the question is already defined, talk to our experts directly.

— More interesting articles