prEN 50726-3:2026

SLOVENSKI STANDARD
01-marec-2026
Sistemi za izredne razmere in nevarnosti – 3. del: Sistemi za odzivanje na izredne
razmere in nevarnosti (EDRS) – Dokumentacija za obvladovanje tveganj in primeri
uporabe
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 prévention des dangers - Partie 3: Systèmes d’urgence et
d’intervention en cas de danger (EDRS) - Dossier de management des risques et
exemples d’application
Ta slovenski standard je istoveten z: prEN 50726-3:2026
ICS:
13.320 Alarmni in opozorilni sistemi Alarm and warning systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD DRAFT
prEN 50726-3
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2026
ICS 13.320 -
English Version
Emergency and danger systems - Part 3: Emergency and
danger response systems (EDRS) - Risk management file and
examples for applications
Systèmes d'urgence et de danger - Partie 3: Systèmes Notfall- und Gefahren-Systeme - Teil 3: Notfall- und
d'urgence et d'intervention de danger (SUID) - Dossier de Gefahren-Reaktions-Systeme (NGRS) -
gestion de risques et exemples d'application Risikomanagementakte und Anwendungsbeispiele
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2026-04-17.

It has been drawn up by CLC/TC 79.

If this draft becomes a European Standard, CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CENELEC in three official versions (English, French, German).
A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to
the CEN-CENELEC Management Centre has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 81472 Ref. No. prEN 50726-3:2026 E

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
Others . 25
8.8
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:
• latest date by which the existence of this (doa) dav + 6 months
document has to be announced at national
level
• latest date by which this document has to be (dop) dav + 12 months
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) dav + 36 months
conflicting with this document have to be (to be confirmed or
withdrawn modified when voting)
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”).
1 Scope
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.
2 Normative references
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)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
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
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.
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
AOST Authorities and organizations with security tasks
PAS Public Address System (Electroacoustic system)
EDRS Emergency and Danger Response System
EDRIS Emergency and Danger Response Intercom System, based on EN IEC 62820-3–2 (ASBIS)
ARC Alarm Receiving Center
ORM organizational Risk Management
VAS Voice Alarm System
TRM Technical Risk Management
TRMF Technical Risk Management File
ABAS Attack/Burglary Alarm Systems or other systems for emergencies/dangers with a connection to
the police
ATD Alarm transmission device
4 Risk management processes
4.1 General
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.
4.2 Phases of the technical risk management process
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.
4.3 Structure and Outline
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.
5 Technical risk management file
5.1 Phase 1 – Object-related context, risk assessment, risk treatment
5.1.1 TRMF point 1: Object description
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).
5.1.2 TRMF point 2: Task
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.
5.1.3 TRMF point 3: Identify people and describe responsibilities
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).
5.1.4 TRMF point 4: Demand and document organizational risk management
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.
5.1.5 TRMF point 5: Inventory to create an overall security concept
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.
5.1.6 TRMF point 6: Risk assessment according to EN IEC 31010
5.1.6.1 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.
5.1.6.2 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.
5.1.6.3 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.
5.1.6.4 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.
5.2 Phase 2 – Selecting the scope of an EDRS up to determining the residual risk
5.2.1 TRMF point 7: Determinations in organizational risk management by top management
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.
5.2.2 TRMF point 8: Specifications in technical risk management in coordination with top
management
5.2.2.1 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?).
5.2.2.2 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.
5.2.3 TRMF point 9: Classification of the EDRS in the overall security concept
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.
5.2.4 TRMF point 10: Specifications for the intervention
5.2.4.1 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.
5.2.4.2 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
5.2.5 TRMF point 11: Definition of residual risk
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 — Connec
...