CLC/TC 79

Date: 2025-08

prEN 50726‑3

Secretariat: BSI

Emergency and danger systems — Part 3: Emergency and danger response systems (EDRS) — Risk management file and examples for applications

Notfall- und Gefahren-Systeme — Teil 3: Notfall- und Gefahren-Reaktions-Systeme (NGRS) — Risikomanagementakte und Anwendungsbeispiele

Systèmes d’urgence et de danger — Partie 3: Systèmes d’urgence et d’intervention de danger (SUID) — Dossier de gestion de risques et exemples d’application

CCMC will prepare and attach the official title page.

Contents Page

European foreword 4

Introduction 5

1 Scope 6

2 Normative references 6

3 Terms, definitions and abbreviations 6

3.1 Terms and definitions 6

3.2 Abbreviations 8

4 Risk management processes 8

4.1 General 8

4.2 Phases of the technical risk management process 9

4.3 Structure and Outline 9

5 Technical risk management file 9

5.1 Phase 1 – Object-related context, risk assessment, risk treatment 9

5.1.1 TRMF point 1: Object description 9

5.1.2 TRMF point 2: Task 10

5.1.3 TRMF point 3: Identify people and describe responsibilities 10

5.1.4 TRMF point 4: Demand and document organizational risk management 11

5.1.5 TRMF point 5: Inventory to create an overall security concept 11

5.1.6 TRMF point 6: Risk assessment according to EN IEC 31010 11

5.2 Phase 2 – Selecting the scope of an EDRS up to determining the residual risk 12

5.2.1 TRMF point 7: Determinations in organizational risk management by top management 12

5.2.2 TRMF point 8: Specifications in technical risk management in coordination with top management 12

5.2.3 TRMF point 9: Classification of the EDRS in the overall security concept 14

5.2.4 TRMF point 10: Specifications for the intervention 14

5.2.5 TRMF point 11: Definition of residual risk 15

5.3 Phase 3 – Planning and construction of the EDRS 17

5.3.1 TRMF point 12: Requirements for planning the EDRS 17

5.3.2 TRMF point 13: Requirements for the establishment of the EDRS 18

5.4 Phase 4 – Operation and maintenance of the EDRS 18

5.4.1 TRMF point 14: Commissioning of the EDRS 18

5.4.2 TRMF point 15: Acceptance and handover of the EDRS 19

5.4.3 TRMF Point 16: Requirements for the maintenance (inspection and maintenance) of the EDRS 19

5.4.4 TRMF Point 17: Change Management 19

6 General information about the application 20

7 Miscellaneous 21

7.1 Deviations 21

7.2 Interfaces 21

8 Application examples 22

8.1 Airport 22

8.2 Educational institutions (e.g. schools, universities) 22

8.3 Courts, offices and administrations 23

8.3.1 Courts 23

8.3.2 Offices and administrations 24

8.4 Shopping mall 24

8.5 Central emergency room of a hospital 24

8.6 Bank foyers 24

8.7 Kindergarten / Day care centre 24

8.8 Others 25

Annex A (informative) Additional questions when creating the technical risk management file 26

A.1 Regarding TRMF point 1: Object description (Organization, building, location,…) 26

A.2 Regarding TRMF point 2: Task (scope of the organization) 26

A.3 Regarding TRMF point 4: Demand and document organizational risk management 26

A.4 Regarding TRMF point 5: Inventory of the overall security concept 26

A.5 Regarding TRMF point 6: Risk assessment according to EN IEC 31010 27

A.6 Regarding TRMF point 7: Specifications in organizational risk management 27

A.7 Regarding TRMF point 9: Classification of the EDRS in the overall security concept 28

A.8 Regarding TRMF point 10: Specifications for the intervention 28

A.9 Regarding TRMF point 14: Commissioning of the EDRS 28

A.10 Regarding TRMF point 16: Specifications for the maintenance (inspection and maintenance) of the EDRS 29

Annex B (informative) Example of an EDRIS according to EN 50726-1 and EN IEC 62820-3-2 30

Annex C (informative) Examples of application areas whenever several emergency and danger reports need to be verified to initiate the correct assistance measures. 32

Annex D (informative) Examples of typical, integrated EDRIS applications in buildings based on EN IEC 62820-3-2 Advanced Security Building Intercom-Systems (ASBIS) 33

Annex E (informative) Example of a controlling matrixTable 36

Annex F (informative) Example of process documentation 38

Annex G (informative) Example overview and floor plan 44

Bibliography 48

European foreword

This document (prEN 50726-3:2026) has been prepared by CLC/TC 79 “Alarm systems”.

This document is currently submitted to the Enquiry.

The following dates are proposed:

Introduction

This document, intended as part-3 of the EN 50726 series of standards, provides information on the structure and content of a risk management file as part of technical risk management according to EN 50726-1 as well as examples for application.

Organizational risk management (ORM) is absolutely necessary as the basis for the conception of an EDRS and for technical risk management (TRM), as technical risk management and organizational risk management need to be coordinated with one another. An ORM need to be set up at the latest with the start of the TRM, as there are dependencies here that make it impossible to view it in isolation.

In many cases, rules of conduct for dangerous, emergency and/or crisis situations already exist within a property. The delivery of this information from organizational risk management to technical risk management should be based on the existing rules of conduct.

This document is aimed in particular at the police, insurance providers, planners, architects, manufacturers and expert companies dealing with safety/security systems, as well as builders, owners, organization in charges, users and occupants of properties at risk (in particular public buildings such as education facilities, agencies, nursery schools and similar facilities).

The original document contains images in colour, which are reproduced in grayscale in the paper version. Electronic versions of this document contain the images in their original colour representation.

The importance of Technical Risk Management and an EDRS is also underlined by requirements of various national law, partially based on EU directives 2022/2555 (NIS2) and 2022/2557 (“CER”).

This document specifies the structure, construction, content and sequence of a technical risk management process and the technical risk management file in accordance with EN 50726-1. It also describes application examples for technical risk management according to EN 50726-1.

An emergency and danger response system (EDRS) is used to minimize risks to life and limb. Its purpose is to report, verify and manage emergencies and dangers in order to prevent or limit personal injury.

As already mentioned in the scope of application of EN 50726-1, the implementation of the Occupational Safety and Health Act and the subsequent regulations is intended in order to take particular account of the protection objective defined therein (physical integrity). However, this not only includes a risk assessment (e.g. prevention of acts of violence) for employees, but also for everyone in the property.

The requirements of the Occupational Safety and Health Act are therefore intended to be observed when creating a safety concept and as part of the technical risk management process. Consequently, particular attention is drawn to paragraphs 5, 6 and 9 of the Occupational Safety and Health Act.

Risks to life and limb can include emergencies and dangerous situations that can cause psychological or physical harm to people.

As soon as the top management (e.g. operators, entrepreneurs, companies, approving authorities, building authorities, administrations) of a property has identified such risks to life and limb as part of risk management or similar risk assessments and/or independently became aware of them, this falls within the scope of EN 50726-1.

The following documents are referred to in the text in such a way that some parts of them or their entire contents constitute requirements of this document. For dated references, only the edition referred to applies. For undated references, the latest edition of the referenced document (including any changes) applies.

EN 16763, Services for fire safety systems and security systems

EN 50726-1, Emergency and danger systems — Part 1: Emergency and danger response systems (EDRS) — Basic requirements, duties, responsibilities and activities

prEN 50726-2, Emergency and danger systems — Part 2: Emergency and danger response systems (EDRS) — Requirements and examples about connecting and interacting with other safety/security systems

EN IEC 31010, Risk management — Risk assessment techniques (IEC 31010)

EN IEC 62820-2, Building intercom systems — Part 2: Requirements for advanced security building intercom systems (ASBIS)(IEC 62820-2)

EN IEC 62820-3-2, Building intercom systems — Part 3-2: Application guidelines — Advanced security building intercom systems (ASBIS)(IEC 62820-3-2)

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at https://www.iso.org/obp

— IEC Electropedia: available at https://www.electropedia.org/

3.1.1

danger

condition or situation in which there is a possibility of physical and/or psychological harm occurring

Note 1 to entry: The danger arises from a possible spatial and/or temporal coincidence of dangers that do not necessarily occur. In this document the terms “risk” and “danger” are equated.

3.1.2

danger evaluation

systematic process of evaluating the potential risks that can be involved in a projected activity or undertaking e.g. by using EN IEC 31010

Note 1 to entry: In this document the terms “danger evaluation” and “risk assessment” are equated.

3.1.3

overall security concept

sum of existing security concepts

Note 1 to entry: Conflicts can be identified by integrating the EDRS into an overall security concept.

3.1.4

organizational residual risk

residual amount of all risks without technical and organizational-technical residual risk, which results from the specifications and processes of top management for organizational risk management

Note 1 to entry: The organizational residual risk is not determined by technical risk management.

3.1.5

organizational-technical residual risk

residual risk that results from the organizational specifications and processes in the application of the technology

EXAMPLE Incorrect operation, resource failure (e.g. illness), alarm organization, etc.

3.1.6

residual risk

totality of technical residual risk, organizational residual risk and organizational-technical residual risk

Note 1 to entry: The residual technical risk determined and approved by technical risk management results from the technology used and the degree. Examples include short circuits, power failures or malfunctions. The organizational-technical residual risk arises from the organizational specifications and processes in the application of the technology. Examples include: incorrect operation, loss of resources (illness), alarm organization, etc.

3.1.7

school-shooting

armed attack with the intent to kill people (shooting spree) in relation to a school, whereby the act does not have to be limited to a school building; the selection of victims being crucial

Note 1 to entry: The means of crime do not necessarily have to be firearms. The end of the school shooting can result in suicide or the perpetrator being killed by outside influence.

3.1.8

security concept

<for the individual danger case> entirety of the defined organizational, personnel, technical and structural measures to secure and/or ward off risks and dangers for each individual dangerous event.

Note 1 to entry: The measures from the fire protection concept or the fire protection certificate represent part of a security concept for the event of fire, in which the structural and technical as well as the organizational and personnel measures to ensure fire protection are based on the required protection objectives of the security concept (e.g. from the building regulations, occupational safety). The protection goals for fire protection include: defined in VDI 3819 Sheet 2.

Note 2 to entry: The measures derived from the security concepts for other dangers (e.g. burglary, terror/amok, incident, gas release) are components of the overall security concept.

3.1.9

security concept

compilation of protection goals that also result from the risk assessment

Note 1 to entry: The security concept takes into account both the risks and dangers within the property, the company or the event, as well as those from and outside. It varies depending on the size and type of property, company or event and the risks. It compiles the protection goals and also includes hazard prevention management.

Note 2 to entry: The protection objectives specified in the model building regulations represent the safety concept for fire protection of standard buildings.

Note 3 to entry: The protection objectives defined in a fire protection concept represent the safety concept for the fire protection of special buildings.

3.1.10

residual technical risk

residual risk resulting from the technology used and the level of EDRS

Note 1 to entry: Examples include short circuits, power failures or malfunctions.

For the purposes of this document, the following abbreviations apply.

Overall risk management consists, among other risk management considerations, of technical risk management and organizational risk management.

Organizational risk management (ORM) is not part of the standards EN 50726-1 and EN IEC 62820-3-2. Technical risk management (TRM) supports organizational risk management and supplements it with technical solutions. ORM and TRM are constantly interdependent. If there are changes to one of the two risk management systems, the other risk management system shall be informed and adjusted if necessary.

The task of the technical risk manager is to determine those features from the ORM that are necessary for the technical risk assessment (see Figure 3).

In order to maintain the protection goals (personal safety, effectiveness as well as data and system security), a risk determination with subsequent risk analysis and risk assessment through to risk treatment shall be created as part of the risk assessment, taking EN IEC 31010 into account.

A security level described in EN 50726-1 is then selected with regard to the technology to be used.

An example of process documentation can be found in Annex F.

The technical risk management file (TRMF) shall always correspond to the phases and points according to Chapter 5. On the one hand, important points shall not be forgotten, and on the other hand, the aim is to create uniformity. It shall be written in a manner that is understandable and comprehensible for top management. It documents a technical risk management process in accordance with EN 50726-1 as a prerequisite for planning, setting up, operating and maintaining an EDRS and follows its project timeline in different phases. These are:

— phase 1: Object-related context, risk assessment, risk treatment;

— phase 2: Selection of the scope of an EDRS up to the determination of the technical residual risk;

— phase 3: Planning and construction of the EDRS;

— phase 4: Operation and maintenance of the EDRS.

The technical risk management process is carried out using the following structure for the technical risk management file. The included information supports the implementation.

If the process determines that there are changes to TRMF points that have already been dealt with, the corresponding points shall be adjusted, e.g. B. Adjustment of the TRMF point 2 task (5.1.2) because further risks were identified under TRMF point 6 risk assessment (5.1.6).

Additional questions on the individual TRMF points can be found in Annex A.

This point contains a description of the object given by top management.

a) designation;

b) address;

c) information about the operator and owner;

d) type, description and photos:

— the building;

— the usage units;

— open and green spaces;

— the access routes;

— the rescue and escape routes;

— the structural and technical facilities (e.g. transformer station, combined heat and power plant, silo, smoking pavilion, etc.);

— the environmental and local characteristics (nature/landscape protection area, residential area, industrial area, mixed use, etc.);

e) purpose;

f) types of use;

g) floor plans (name of the rooms, function of the rooms, locations with names of any existing security systems and detectors, positions of other security-relevant information (gas connection, defibrillator location, etc.);

h) information on existing possible colour and guidance systems;

i) names and availability of responsible persons (top management, technical risk manager, organizational risk manager, crisis team, key holders, etc.);

j) other information (e.g. site plan, code of possible key depots).

This point contains the task to be determined by top management at the beginning of planning (see support in EN 50726-1:2024, Annex B, Table B.3).

a) Establish context in accordance with EN IEC 31010 (basic parameters and influencing factors for risk management)

— definition of protection goals taking into account the factors of time, quality and space;

— determining principles of action and procedures;

— establish responsibilities and responsibilities;

— define risk assessment methods;

— establish criteria for when a risk should be treated or accepted.

Basic goals shall be determined and agreed upon. The responsible organization establishes the context as part of the overall risk management process.

This point contains the relevant people specified by top management in accordance with the specifications of EN 50726-1 and their responsibilities:

a) operator (responsible organization);

b) top management (appointed by the operator, shall approve the residual risk);

c) risk management:

— technical risk manager (appointed by top management, responsible for creating and maintaining the technical risk management file);

— technical risk management team (if necessary);

— organizational risk manager (if necessary);

— overall risk manager (if necessary).

This point contains the documentation of organizational risk management as requested by technical risk management.

The application of EN 50726-1 requires both organizational and technical risk management. Both are subordinate to overall risk management.

The specifications and specifications from both areas have an influence on the residual risk for which top management is responsible. The type and scope of a technical solution requires organizational adjustment; on the other hand, organizational specifications require an adapted technical component selection.

This point contains the existing security concepts to be required by technical risk management or the recording of the technical and organizational inventory relevant in connection with the EDRS.

a) Technical inventory (existing surveillance and security technology, e.g. EMA, ÜMA, BMA, perimeter protection, access control systems/access controls, video surveillance, ELA, intercom, fault alarm systems);

b) organizational inventory (e.g. crisis team, emergency folder, reason for evacuation, alarm plan, security personnel, disruption management);

c) structural inventory (e.g. number of buildings, building structure, surrounding plan).

The TRM shall decide whether all relevant documents for its risk assessment are available and request any missing documents.

Risk determination

Risk identification is the process of searching, identifying and recording risks.

The purpose is to determine what could happen or what situations could exist that could affect the achievement of the protection goal.

The process of risk identification involves identifying and recognizing the causes and sources of the risk, dangers, events, situations or circumstances that could have an impact on the protection objective.

Risk analysis

The aim of risk analysis is to develop an understanding of the risk. The risk analysis represents an input for risk assessment. It forms the basis for decisions as to whether risks need to be handled and provides information about the most suitable handling strategy(s) and procedures.

During a risk analysis, the consequences and the associated probabilities are determined and recognized risk events are determined. This takes into account whether countermeasures are in place and how effective they may be. The consequences and their probabilities are then combined to determine the level of risk.

The risk analysis includes looking at the causes and sources of risk, their consequences and the probability that these consequences can occur.

Risk evaluation

Risk assessment uses the understanding of risk gained during the risk analysis to decide how to proceed. Ethical, legal, financial and other considerations, including risk perception, shall also be taken into account when making this decision.

Decisions may include:

a) whether a risk needs to be addressed;

b) what priorities apply to handlings;

c) whether an activity is to be started.

Determination of the security level

Depending on the risk assessment and taking into account the protection objectives defined under 4.1, selection and justification of a resulting level of security by technical risk management in accordance with EN 50726-1 and creation of proposals for suitable technical concepts (basic structure) in accordance with level of security.

This point contains determinations by top management or a representative appointed by top management (e.g. organizational risk manager); it defines the intersection of TRM and ORM. In particular, the following determinations shall be made by top management in coordination with the TRM:

a) monitoring/reporting areas;

b) alarm areas (warning/signalling area, internal alarm);

c) types of alarm (warning/signalling types), if necessary taking into account the multi-sensory principle (e.g. voice announcement, acoustic signal generator, optical signal generator, flashing light, pager, smartphone);

d) alarm signals (according to danger types) and/or announcement texts;

e) alarm processes (internal alarm, remote alarm, duration, type, recipient);

f) control options and interaction (e.g. internal/external: selection of voice area, video technology, targeted call point selection, locking devices, interaction with other devices and systems);

g) opportunities for objections (e.g. secretariat, external ARC / AOST);

h) determining whether a confirmation of receipt shall be issued at the trigger location (visible, audible, tactile) in order to prevent perpetrator reactions;

i) verification measures for each type of danger (preliminary alarm check);

j) intervention measures for each type of danger (who is alerted, when and what measures are taken);

k) measures in the event of false alarms;

l) marking of doors and buildings for the reliable guidance of intervention forces (e.g. clearly legible numbering, colour coding system);

m) remaining operating time of the object after loss of energy supply until operation ceases (see 5.3.1.1);

n) measures in the event of disruptions to an EDRS.

Coordination with top management

Technical risk management shall determine the following requirements in coordination with top management:

a) required performance characteristics of a higher level in a lower level in order to minimize the residual risk;

b) contents and results of coordination with the responsible authorities (e.g. fire brigade, police);

c) external selection options for EDRIS call stations even in non-alarm status;

d) display location of error messages and operating states;

e) measures in the event of a disruption;

f) troubleshooting measures;

g) accuracy of localization, particularly for portable EDRS detectors;

h) display of the detector trigger location at the recipient in the property (e.g. secretariat, first point of contact for the intervention forces) and, if necessary, with differentiated alarm transmission to ARC/AOST in accordance with EN 50136;

i) required additional technology.

As a rule, the technical risk manager explains the content of regulations and the associated technical possibilities. This stimulates a targeted discussion about organizational adjustments. External consultants (e.g. police) should be called in for support.

The technical risk manager documents the results in the technical risk management file (What happens when and by whom?).

Additional coordination with the AOST (Authorities and organizations with security tasks)

Depending on the degree and scope of the EDRS and with regard to targeted verification and alarm tracking when EDRS detectors are triggered, the following points shall be discussed with the relevant AOST at an early stage. Particularly in the case of EDRS with a connection to the police (ABAS), these shall be coordinated at an early stage with the police officer responsible for ABAS:

a) integration of the EDRS into the overall security concept;

b) types of EDRS applications including scope and degree of applications, whereby the degree shall be selected that best corresponds to the identified risk, with residual risk accepted;

c) installation and functionality (triggered by anyone or only certain people) of the EDRIS detectors;

d) use of security measures as part of an overall security concept (e.g. structural and mechanical security) and electronic measures (electronic, optical and other devices);

e) additional measures to support the police's assessment of the situation (e.g. voice connections, image transmissions);

f) targeted interaction of all technical facilities (security and monitoring measures) with clear organizational and administrative measures (e.g., rules of conduct, voice communication) or instructions;

NOTE Attention is drawn to access regulations that can apply.

g) determining, together with the AOST involved, which alarms have priority in the event of parallel triggering of other danger messages (e.g. fire alarm) or which measures should then be taken (e.g. switching off the fire alarm so that the EDRS alarm is activated). The voice announcement corresponding to the alarm can still be understood);

h) triggering of internal alarm (automatic/non-automatic) and type of alarm (e.g. voice announcement, alarm tones);

i) type of alarm (amok alarm or emergency call, depending on the definition with or without automatic internal alarm) and the identification of the trigger/intercom station for forwarding to the police;

j) options for targeted dial-in to triggering EDRIS intercom stations and type of communication connection setup (call setup from the police after an alarm has been received by the police or automatic call setup to a police telephone number to be coordinated);

k) control/switching options for the voice connection (“listen only” (half duplex) or “speaking connection” (full duplex));

l) determination of a contact point for the police at the property and the necessary control trigger options (e.g. control, reporting and communication points for the police) and documents to be kept (e.g. property plans);

m) control/triggering options by the police (e.g. triggering internal alarms/voice announcements in the relevant areas) at the property or remotely;

n) supporting measures for the intervention (including, for example, running cards, interruption of electricity/gas, whereby, depending on the intended intervention service (AOST or private intervention services), the corresponding organizational and tactical measures are taken into account when designing the technology shall be viewed;

o) Displaying triggered messages or alarms in a floor plan and retrieving a corresponding, generated website);

p) which technically controllable systems/equipment/components in the property should be controlled in which case (e.g. control of blinds);

q) type of remote triggering of an EDRS if the police receive information about a crime in the relevant property via another channel (e.g. by telephone);

r) plans for the intervention.

This point contains the classification of the EDRS in the overall security concept based on the specifications from top management.

The technical risk manager presents the various technical options with reference to possible different residual risks for implementing the required level. The selection of a technical concept to fulfill the specified level is carried out by the top management.

The technical risk manager presents options for integrating the previously selected technology into the organizational processes. The aim is to use technical support to improve the overall security concept as part of the overall risk management process.

Determinations with the intervention forces

The following specifications shall be determined by top management in conjunction with the intervention forces:

a) coordination and documentation of the intervention measures;

b) creation of appropriate plans (e.g. site plans, floor plans, diagrams, access routes, colour coding system) for the intervention as part of overall risk management (see Annex G);

c) coordination and documentation of an intervention team/crisis team for your own interventions on site;

d) location detection when triggering EDRS detectors and detector identifiers.

In the case of EDRS connected to the police (ABAS), the measures and cooperation in the event of a police intervention and the creation of appropriate plans shall be coordinated with them.

Verification of alarms

Before alarms are passed on to official bodies (AOST), the body providing assistance (on site or the emergency call and service control centre) shall always carry out a qualified technical and/or personnel preliminary check (verification) (except for EDRS (EDRIS) with connection to the police (ABAS), since the police themselves carry out the verification). The authorities should only be informed by telephone (e.g. 110 or 112) if there are reasonable grounds for suspicion (see Figure 1).

NOTE 1 Attention is drawn to the local regulations according to Alarm-Verification that can apply.

In the case of alarm messages triggered by EDRS detectors, it is at the verifier's discretion whether the qualified technical and/or personnel preliminary inspection can be omitted or shortened.

The verification measures shall be coordinated with the respective AOST and the body providing assistance before the EDRS is put into operation and documented in the TRMF.

NOTE 2 If, despite verification, it is a false alarm, you can expect to pay fees from the authorities for unnecessary operations.

All measures agreed with an external assistance provider (emergency call and service control centre) (which alarm has which verification and intervention measures?) shall be documented in an alarm service and intervention agreement and attached to the TRMF.

In the case of EDRS with a connection to the police (ABAS), the intervention measures, the cooperation in the event of a police intervention and the creation of appropriate plans shall be coordinated with the police.

Figure 1 — Example of an EDRIS with EDRS detector connected to the police and two additional buttons

This point contains the definition of residual risk.

An emergency or dangerous situation cannot be prevented by an EDRS. The EDRS is tasked with supporting the response to an emergency or dangerous situation and reducing the impact (see Figure 2).

Figure 2 — Relationships between risk, processes and residual risk

A residual risk related to the object and to be defined results from each of the technical security levels as well as from the organizational processes set up and thus from the overall security concept.

The following technical residual risks shall be defined:

a) The technical residual risk is determined by the TRM. It refers to the technical solution used, which results from the requirements of the level determined based on the risk assessment and the protection objectives defined under 4.1.

b) The technical and organizational residual risk is determined by the TRM and ORM. It results from the organizational specifications and processes in the application of the technology (see Figure 3).

The remaining risk is released by top management.

If it is possible to achieve effective risk reduction with the EDRS of different levels, it is recommended that the residual risks of these levels be identified to facilitate decision-making by top management.

Figure 3 — Connection between technical and organizational residual risk

This point contains the specifications for planning the EDRS to be created by technical risk management together with a specialist planner.

Technical risk management shall specify the requirements for planning the EDRS to a specialist planner.

The specialist planner shall provide evidence of qualifications in accordance with EN 50726-1 (e.g. proof of systems that have already been implemented, proof of training from various manufacturers of EDRS or necessary parts thereof, knowledge of EN 50726-1, prEN 50726-2 and this document).

The task of the specialist planner is to take risk management requirements into account and develop various possible solutions. The specialist planner shall take this into account

the specifications of EN 50726-1 and, if necessary, prEN 50726-2 and this document to work in particular with the specifications developed under TRMF points 7 and 8 as specifications for planning.

The release of the specifications required in EN 50726-1, only refers to the specifications and requirements created by the TRM to achieve the defined protection goal. After the planner has created the list of services, the specifications for the EDRS submitted by the TRM are approved by the TRM.

This point contains the deviations to be documented by technical risk management for the establishment of the EDRS.

During the establishment of the EDRS, problems may arise with regard to the implementation of the requirements listed under the previous points. If this is the case, these shall be evaluated by the TRM, a decision made and documented. For this purpose, the following planning components shall be included in the TRMF:

a) decisions during the planning phase with comments from the TRM, if necessary;

b) implementation planning;

c) tender, list of services, functional description;

d) decisions during the execution phase with comments from the TRM, if necessary.

This point contains the points to be requested and documented by technical risk management before commissioning. These are in particular:

a) facility description of the entire EDRS;

b) handover of documents for handling;

c) plans (schematics, floor plans, overview/floor plans (see Annex G):

— function and designation of the rooms;

— location and designation of detectors with telephone numbers at EDRIS;

— accuracy of location detection when triggering portable EDRS detectors;

— position of key depot with central opening means (e.g. transponder for AOST or master key);

— position of intervention point for intervention forces (AOST);

— locations of other safety-relevant information (e.g. gas connection, defibrillator location);

— location of the control devices for technical systems/equipment/components (e.g. control of blinds);

— information on the colour and guidance system;

d) functional circuit diagrams (principle circuit diagrams);

e) names and availability of responsible persons (top management, technical risk manager, organizational risk manager, crisis team, key holders, etc.);

f) handing over documents for the intervention to the body providing assistance and the AOST (including plans, names and contact details, if necessary running maps, etc.);

g) list of reporter IDs and telephone numbers at EDRIS;

h) operating instructions;

i) installation and maintenance documents;

j) operations book;

k) requests for changes, their assessment and measures derived from them;

l) instruction of users/staff;

m) test reports;

n) service descriptions for the interfaces and their explanations of other services.

As part of their qualification for setting up the EDRS, the specialist company shall have knowledge of the functionality in accordance with EN 50726-1 and, if applicable, prEN 50726-2 and this document, and also meet the requirements of EN 16763. For EDRIS, additional knowledge of EN IEC 62820-2 and EN IEC 62820-3-2 shall be demonstrated.

NOTE A corresponding certification according to EN 16763 is still suspended when this document is published, as a corresponding qualification for the area of EDRS is not yet possible.

This point contains the acceptance and handover of the EDRS to be carried out by top management with the participation of the TRM.

Before acceptance, a full inspection shall be carried out by the installer in conjunction with the planner. It shall be checked whether the EDRS meets the requirements for planning, project planning, assembly and commissioning. This includes in particular whether the designations and the local location correspond to the plans. In addition, the intended interaction with other systems and facilities shall also be checked taking the TRMF into account (see also VDI 6010, sheet 3). Depending on the scope of the systems and facilities involved, a clear control matrix shall be defined (see Annex E). The results of the full sample test shall be documented.

The acceptance shall be carried out on a random basis by the top management or a representative appointed by the top management with the participation of the TRM. In particular, the alarm processes and data to be transmitted shall be checked for correctness.

Instruction shall be carried out in accordance with the TRM specifications by the specialist company (installer of the EDRS) in conjunction with the ORM. In particular, note:

a) which user groups need to be trained and how;

b) at what interval or when there are changes (e.g. changes in personnel) the briefing is repeated.

This point contains the specifications to be created by technical risk management for the maintenance of the EDRS as part of the technical risk management process.

The maintenance specifications depend on the level of technology used and shall be set out in the TRMF. Maintenance shall be carried out at least once a year. The work cards and/or processes for maintenance shall be documented in the TRMF together with the maintenance person. An operating book shall be kept.

The need and scope of recurring full sample tests shall be agreed between the maintenance engineer and the technical risk manager.

The EDRS maintainer shall have the appropriate qualifications according to EN 50726-1. It is also recommended that the maintainer meets the requirements of EN 16763.

This point contains the specifications to be created by technical risk management for change management as part of the technical risk management process.

Change management shall be carried out in particular in the following circumstances:

a) change in risk due to a new risk assessment;

b) identifying new risks based on a new risk assessment;

c) change in general conditions;

d) accumulation of crimes;

e) changing the way crimes are committed;

f) changes to the building structure;

g) system error in EDRS;

h) organizational changes;

i) protection objectives not achieved.

As part of change management, a target/actual comparison shall be carried out at least annually by a TRM, if necessary in coordination with the ORM.

If differences are identified, appropriate measures shall be taken immediately. Top management decides after which time the technical risk management file shall be checked and, if necessary, revised.

The structure of an EDRS is different for each object. It depends on the identified risks and their handling. An EDRS also links newly installed and suitable existing security technology (see Figure 4).

If possible additions are relevant to safety or security, it is the responsibility of the TRM to describe this relevance in the TRMF and to set the resulting safety and security requirements.

Figure 4 — Basic structure of an EDRS

In order to achieve the protection goals, the risk manager may deviate from EN 50726-1 and/or prEN 50726-2 and this document. This shall be justified, approved by top tier management and documented in the system description and thus in the TRMF.

If the use of an EDRS in the property is recommended due to the TRM, the requirements of Grade 1 shall not be exceeded under any circumstances

Interfaces from and to other systems (Figure 4), which enable safe and retrospective -free networking, are to be carried out according to generally recognized rules of technology. A rating on topicality shall be carried out at regulated intervals or on request. If you have any questions about the evaluation of secure interfaces, various certified and accredited areas can provide information and can be integrated into the decision about the selection.

Airports have a complex structure consisting of a large number of buildings with different uses and different areas with differentiated security classifications. A wide range of needs of people with different languages, personal disabilities and poor local knowledge shall be taken into account in an appropriate manner.

NOTE The global events in connection with air traffic have led to a tightening of various laws (e.g. Aviation Security Act), regulations, rules and requirements.

Due to the many different employers at airports, compliance with the obligations under the Occupational Safety and Health Act is particularly important. This means that, under certain circumstances, certain risks at an airport can affect the employees of these companies.

The large number of possible dangers/risks at an airport require a large number of different existing safety and security technologies. A challenge lies in linking these security technologies for greater effectiveness, faster usability and an increase in the level of security. Examples include the following technologies and groups of people: elevator emergency call, parking garage emergency call, automated external defibrillator (AED), first aid emergency call, airport fire department communication, baggage handling, local radio meeting, ground handler handling, state/federal police, doctor Service, disabled toilet emergency call, parking space management.

By dividing it into location-related, networked systems that support all EDRS / EDRIS applications, even less security-relevant applications with a high level of usage ensure availability control of little-used security applications.

Perimeter protection can also be included when creating the security concept.

The specifications for an EDRS / EDRIS help ensure that the security and backup technologies used work together as intended.

Annex B, Table B.1, shows examples of EDRIS applications that can be taken into account when creating a security concept.

Educational institutions are essentially publicly accessible buildings and campuses. Teachers and learners generally have good local knowledge.

There are generally no identity checks at public facilities and there is no security service on site.

The extracurricular use of certain areas shall be taken into account when drawing up the security concept. So is e.g. For example, the availability of local assistance agencies outside of school hours is often unavailable.

Depending on the type of educational institution, the threat and danger potential depends on the age structure and the personal impairments of the learners and users in non-school activities.

Since the responsibilities of state educational institutions for building safety and personnel lie with different providers, compliance with the Occupational Safety and Health Act is particularly complex. It is therefore the task of the risk management process, especially technical risk management, to bring these responsibilities and interests together.

Special emergencies and dangers in which e.g. B. the inclusion of people and/or information to bodies providing assistance (e.g. school shooting) is not covered in the model school construction guidelines.

Existing emergency documentation shall be observed. As a rule, however, these do not include support through technical solutions.

As part of the technical risk management process for an EDRS, the risks posed by the threat of amok, school shootings, acts of violence and accidents shall be taken into account.

As a rule, there is no permanently staffed on-site assistance position at educational institutions, so a referral to an external assistance agency shall be provided.

One goal of the EDRS is to optimally support the crisis team or other organizational groups (e.g. first responders, school social work, pastors, school medical service) in terms of information acquisition, distribution and accessibility.

Most federal states have handouts on organizational processes for crisis and dangerous situations (e.g. emergency plan), which should be taken into account when planning an EDRS, especially when coordinating between ORM and TRM.

Through regular exercises, safe behaviour in an emergency can be achieved. The scope of the exercises shall be agreed between those responsible and, if necessary, the intervention forces. If no exercises are carried out, in the event of an emergency or danger, voice announcements with instructions on how to behave shall be made (see EN 50726-1:2024, Annex A.).

An EDRIS according to EN IEC 62820-3-2 (ASBIS) can take over other everyday functions (e.g. signalling breaks, announcements) as long as these do not have a negative impact on the function in the event of danger.

Connecting an EDRS to a networked locking system can be particularly useful in educational institutions.

Courts (district courts, regional courts, labour courts, administrative courts, etc.) are public buildings that can only be entered without access control in individual cases.

In many courts there is a permanently staffed assistance position and appropriately trained staff to help and verify emergency calls.

In principle, such a building is subject to an increased risk of amok, threats, hostage-taking and escape of the accused and resistance to state authority.

Risk areas are:

— admission control;

— detention cells;

— halls and consultation rooms;

— waiting areas in front of the hearing rooms;

— seats in front of the building.

Responsibility for the buildings can fall to different bodies. In many cases, organizational risk management already exists.

When implementing an EDRS, existing systems can be integrated. Existing communication systems can, if necessary, meet EN IEC 62820-3-2 after being upgraded.

As part of the TRM, the following sources of danger should be taken into account:

— personnel controls;

— canteen inventory (possible use of weapons);

— possibility of locking doors;

— building condition;

— perimeter protection;

— visitors.

An EDRS can be used in courts to silently alert employees or a permanently occupied position. In the event of an emergency or danger, comprehensive internal alarms and behavioural instructions can also be triggered.

As in court buildings, there may be people in offices and administrations who pose an increased threat and danger potential. In contrast to court buildings, however, there are usually no access controls in offices and administrations in order not to restrict people's proximity.

The threat and danger potential depends on the size and the expected groups of people. The desired customer proximity is supported by open building structures with multiple entrances. There are no identity checks. Often there is no permanently staffed position to provide assistance on site. As a rule, crisis and risk management is not sufficiently in place.

Due to the size and number of people, there is usually an SAA, which can also be used as a public address system and for comprehensive internal alarms and behavioural instructions in the event of an emergency or danger.

In particular, the following points shall be taken into account:

— individually identifiable emergency call points for visitors with connection to a permanently manned location (with identification of the trigger location);

— connection of AED (defibrillators) to an EDRS;

— individually identifiable, bidirectional emergency call points for shops as emergency call systems and alarm verification systems (with detection of the trigger location);

— video technology in the mall area;

— video technology in associated outdoor areas, e.g. access and parking areas;

— access control technology for storage areas and delivery points.

People who come to an emergency room are usually in a tense state. Many patients and relatives expect to receive immediate help and have little understanding of waiting times.

Delirious patients (alcohol, drugs, dementia) can be unpredictable and disoriented and are often prone to increased violence.

Emergency rooms have several entrances without personal controls and generally do not have a permanently manned emergency room with intervention staff.

Call systems, if present, are designed for patients and not for the protection of staff. This means that in the event of danger to the staff, no help can be requested. An EDRS can also increase the safety of staff in hospital wards and warn those affected.

Unoccupied foyers are made available by banks for their customers so that they can also use them outside of bank opening hours, for example. B. being able to withdraw money.

These rooms provide space for “undesirable people” as well as criminals, which can create dangerous situations for bank customers.

An EDRIS according to EN IEC 62820-3-2 in combination with video technology and a connection to a point of assistance can increase the safety of the people to be protected. Targeted addressing with the answer option can achieve a calming and de-escalating effect.

Safety technology to protect children and staff in kindergartens and daycare centers can support daily operations and increase safety. The proper collection of children exclusively by authorized persons can be significantly increased by using an EDRS, for example in combination with an access control or video communication system.

For examples of application areas whenever several emergency and danger reports need to be verified to initiate the correct assistance measures, see Annex C.

For examples of typical, integrated EDRIS applications in buildings based on EN IEC 62820-3-2 Advanced Security Building Intercom Systems (ASBIS) see Annex D.

1. 
   (informative)
   
   Additional questions when creating the technical risk management file
   1. Regarding TRMF point 1: Object description (Organization, building, location,…)

Are there additional colloquial or traditional names for the object (organization, building, location, …)?

Is there a clear location/address reference?

Is additional information necessary for locating and accessing the building?

Alternatively, or additionally, is georeferencing required (e.g. GPS coordinates, what3words)?

Usage concept (planned use) often inadequate:

What are the usage and operating times?

What is the accessibility (e.g. access authorization, access control, public/non-public access, restrictions for areas)?

Are there limiting personal factors (e.g. children and babies in kindergartens, people with limited self-rescue ability in hospitals/retirement homes, people with restricted freedom in prisons)?

What number of people can be expected and when?

Are there uses by third parties and if so, which ones, when, etc.?

Are there any other unplanned uses and if so, which ones, when, etc.?

• 1. Regarding TRMF point 2: Task (scope of the organization)

Is there a specified emergency manual?

Is there a risk assessment according to the Occupational Safety and Health Act?

What is the client’s protection requirement?

• 1. Regarding TRMF point 4: Demand and document organizational risk management

Who develops/maintains the ORM and is the contact person for the TRM?

Who is the TRM contact person at the police/fire department?

Who is the TRM contact person in the school authority/building authority/construction supervision?

Who is the operator?

Who is the client?

Who is/are the user(s)?

Should other people (groups) be included?

• 1. Regarding TRMF point 5: Inventory of the overall security concept

What technical systems are installed in the building?

Which technical systems are actively used and are they functional?

What documentation is there about the technical systems?

When was the last maintenance/inspection carried out and is there documentation (operating log) about it?

Were there any requirements or requirements for the installation of the technical systems and if so, which ones?

How are the requirements for the protection of life and limb from the Occupational Safety and Health Act implemented?

Are there alarm concepts? (Current status? Responsibility? Practical experience?)

Is there an eviction plan? (Current status? Responsibility? Practical experience?)

Is there a fire protection concept? (Current status? Responsibility? Practical experience?)

Are there requirements and requirements regarding behavioural measures in an emergency?

Is there a crisis team? (Current status? Responsibility? Practical experience? Substitution arrangements?)

Is there an emergency folder? (Current status? Responsibility? Practical experience?)

What reasons for evacuation have been established?

Are there security guards? (Current status? Responsibility? Practical experience? Substitution arrangements?)

How are vacation/replacement/illness handled?

Are there current building plans?

Are there current and complete room numbers and names?

Is there a locking system and how does it work?

What access options are there to the property/property?

What is the view of the property from the outside?

What neighbourhood influences are to be expected and how should they be assessed?

What environmental influences are to be expected and how should they be assessed?

• 1. Regarding TRMF point 6: Risk assessment according to EN IEC 31010

Once the safety level has been determined for a grade 1 system, how is the option of specifying a manual check to ensure functionality organizationally (even in the event of illness / Vacation / replacement)?

• 1. Regarding TRMF point 7: Specifications in organizational risk management

Which areas should be covered with detectors?

Where should detectors be installed?

Which areas should be covered with signalling devices for the internal arms?

Where should signalling devices for the internal arms be installed?

In which cases should warnings or signals be given?

Which alarm message has which priority (e.g. fire alarm versus EDRS alarm)?

Are announcements or the playing of (multilingual) announcement texts required?

Are different types of alerts required for individual types of danger?

Who are the recipients of the alarm message?

How is the alarm message forwarded to the recipients?

Who needs to be additionally informed about the alarm message?

What does the recipient do with the alarm message?

What happens if the recipient doesn't respond?

Do intervention forces have to be called in?

Do people at risk or other nearby facilities need to be warned?

How are people warned when an emergency situation occours?

When an Emergency situation occours, for how long are people warned?

How and by whom is the internal alarm stopped?

How and by whom is the alarm message reset?

Are there technical processes that need to be triggered in the building?

Are there organizational processes that need to be triggered in the building?

Who is allowed to make announcements in the property?

From where and how are announcements in the property triggered?

Should an acknowledgement of receipt be displayed at the release location?

What intervention measures are available?

By whom and how should which alarm messages be verified?

Should activations of EDRS detectors be transmitted directly to an external alarm receiving centre (ARC) or other response organisations?

Does protection against misuse make sense?

Does it make sense for everyone to trigger it and, if so, on which detectors?

Does qualified triggering make sense and if so, on which detectors and by which group of people should this be done?

How should an alarm pre-test be carried out to prevent false alarms?

Should an alarm message be able to be withdrawn?

Is there a (colour) marking and/or guidance system?

How long is the remaining operating time of the object until operation stops after loss of energy supply?

What should happen if an EDRS is disrupted?

How long can the object (organization, building, location,…) operate in the event of a malfunction?

• 1. Regarding TRMF point 9: Classification of the EDRS in the overall security concept

What are the guidelines from top management?

• 1. Regarding TRMF point 10: Specifications for the intervention

How should the intervention measures be coordinated?

How and by whom are the intervention measures to be documented?

Which plans (e.g. site plans, floor plans, diagrams, directions, colour coding system, telephone numbers) are required?

Does top tier management need intervention teams/crisis teams for its own interventions on site and if so, which group of people does this include?

Is location detection required when triggering EDRS detectors and detector identifiers?

Which type of alarm (see threat types A, B, C according to EN 50726-1, Table (Figure 3 — Table of assignments of grades) results in which verification and intervention measures?

The fire alarm type should also be taken into account?

• 1. Regarding TRMF point 14: Commissioning of the EDRS

Which handling documents should be handed over to whom?

In what form should the operation of the EDRS be taught?

How should user training be carried out?

Are the technical test protocols relevant to the ORM?

• 1. Regarding TRMF point 16: Specifications for the maintenance (inspection and maintenance) of the EDRS

Have new risks been identified?

What organizational changes have been made?

1. 
   (informative)
   
   Example of an EDRIS according to EN 50726-1 and EN IEC 62820-3-2

EDRIS applications at an international airport. All applications are technically and functionally networked via location-based central units.

Table B.1 — EDRIS example of an international commercial airport

1. 
   (informative)
   
   Examples of application areas whenever several emergency and danger reports need to be verified to initiate the correct assistance measures.

Table C.1 — Making the right safety/security product decisions to be functional covered by an EDRS

1. 
   (informative)
   
   Examples of typical, integrated EDRIS applications in buildings based on EN IEC 62820-3-2 Advanced Security Building Intercom-Systems (ASBIS)

Table D.1 — Typical applications of EDI in different buildings

1. 
   (informative)
   Example of a controlling matrixTable

Table E.1 — Example of controlling an EDRIS

1. 
   (informative)
   Example of process documentation

Table F.1 — Example process documentation for risk management and the creation of the TRMF

1. 
   (informative)
   
   Example overview and floor plan

Overview plan content:

— Location of the buildings, use of the building, name of the building, adjacent and neighbouring streets with street names;

— number of floors;

— representation of the neighbourhood;

— all entrances to the building;

— driveways as well as roads and paths on the property;

— non-motorable areas;

— north arrow;

— fire department symbols (hydrants, transformers, fire walls, BMZ, etc.);

— legend.

Floor plan content:

A plan with the following content should be prepared for each building and all floors:

— legend for explanation;

— plan stamp and an object overview;;

— designation of the projectiles;

— north arrow;

— designation of the room number and room usage;

— fire walls and room-enclosing walls;

— doors and gates and all types of openings;

— entrances and exits to the building;

— staircases, stairs and their direction of travel;

— vertical and horizontal escape routes;

— elevators and conveyor systems;

— non-accessible areas;

— control points (EDRS, BMZ, RWA, etc.);

— stationary extinguishing systems;

— warnings about dangerous substances and areas as well as their locations, quantities and location;

— building services systems, e.g. E.g. heating, server, etc.;

— shut-off devices, e.g. B. for gas, water etc.;

— location of EDRS elements;

— internal and external call number of the respective intercom station;

— ATD identification number (for EDRS with connection to the police).

Miscellaneous:

Furthermore, individual specifications for colour coding systems etc. should be incorporated into the plans.

Figure G.1 — Example of an overview plan

Figure G.2 — Example of a floor plan

Bibliography

CEN/WS ERP, Date: 2023-02, PrCWA ERP:2023, Structuring an emergency response plan for crisis management Stakeholders, Secretariat: ASRO

Council Directive 89/391/EEC of 12 June 1989 on the introduction of measures to encourage improvements in the safety and health of workers at work

CER Directive, Directive (EU) 2022/2557 of the European Parliament and of the Council of 14 December 2022 on the resilience of critical entities and repealing Council Directive 2008/114/EC

Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive)