ISO 31101:2023
(Main)Robotics — Application services provided by service robots — Safety management systems requirements
Robotics — Application services provided by service robots — Safety management systems requirements
This document specifies the requirements of safety management systems for application services provided by service robots [application service safety management system (hereafter ASSMS)] that an application service provider can use for the safety of its users and its third parties when it provides application service in unstructured human spaces with trained and untrained persons (e.g. giving directions for visitors in airport or shopping mall, carrying goods to patients in hospital, delivering food to customers in restaurant.) This document is applicable to any organization that wishes to: a) improve safety performance of application services provided by service robots, b) establish, implement, maintain and improve safety management systems for application services provided by service robots, c) assure itself of conformity with its stated application service safety policy, and d) demonstrate conformity with this document. The requirements of this document can be conformed to by integrating safety management systems for application services provided by service robots into, or making it compatible with, other management systems or processes within the organization. The requirements of this document can be conformed to by multiple organizations without omission depending on what is done as an organization and safety management. Although intended for application services provided by service robots, this document can also be applied to services using robots other than service robots. This document is not intended to be used as a product safety standard. NOTE There are cases where the safety management systems for application services provided by service robots established in accordance with the requirements of this document cannot apply directly when the service robots to be used, robot systems, contents of service, places of operation, users or so, differ.
Robotique - Services rendus par les robots de service — Exigences relatives aux systèmes de gestion de la sécurité
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 31101
First edition
2023-11
Robotics — Application services
provided by service robots — Safety
management systems requirements
Reference number
© ISO 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Context of the organization .8
4.1 Understanding the organization and its context . 8
4.2 Understanding the needs and expectations of interested parties . 9
4.3 Determining the scope of the application service safety management system . 9
4.4 Application service safety management system . 9
5 Leadership .10
5.1 Leadership and commitment . 10
5.2 Policy . 10
5.3 Roles, responsibilities and authorities . 11
6 Planning .11
6.1 Actions to address risks and opportunities . 11
6.2 Application service safety objectives and planning to achieve them . 11
6.3 Planning of changes .12
6.4 Safety risk assessment . 12
6.4.1 General .12
6.4.2 Preparation of safety risk assessment .12
6.4.3 Safety risk analysis .13
6.4.4 Safety risk evaluation . 14
6.5 Activities for safety risk reduction . 14
6.5.1 General . 14
6.5.2 Determination of safety risk reduction measure . 14
6.5.3 Determination of compliance obligations on the operation .15
6.5.4 Planning implementation of the safety risk reduction measures . 16
7 Support .16
7.1 Resources . 16
7.2 Competence . 16
7.3 Awareness . 17
7.4 Communication . 17
7.4.1 General . 17
7.4.2 Internal communication . 18
7.4.3 Communication with interested parties . 18
7.5 Documented information . 18
7.5.1 General . 18
7.5.2 Creating and updating documented information . 18
7.5.3 Control of documented information . 18
8 Operation .19
8.1 Operational planning and control . 19
8.2 Communication with users . 19
8.3 Consideration for the third party of application service . 20
8.4 Emergency preparedness and response . 20
8.5 Managing hazardous events . 21
9 Performance evaluation .22
9.1 Monitoring, measurement, analysis, and evaluation . 22
9.2 Internal audit .23
9.2.1 General .23
9.2.2 Internal audit programme . 23
iii
9.3 Management review . 24
9.3.1 General . 24
9.3.2 Management review inputs . 24
9.3.3 Management review results . 24
10 Improvement .24
10.1 Continual improvement . 24
10.2 Nonconformity and corrective action . 25
Annex A (informative) Example of interested parties in application service and
relationship to the defined terms .26
Annex B (informative) Classification of the relationship between operation contents
of application service and robot use restriction intended by robot system providers.27
Annex C (informative) Examples of information for use of service robots .29
Annex D (informative) Examples of hazards in operation and their causes .33
Bibliography .41
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use
of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all
such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 299, Robotics.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
When operating service robots that coexist with people, proper management of their residual safety
risks is needed. To achieve this, in the same manner as with general machineries, application service
providers, who intended to start application services provided by service robots, need to consider the
safety in operation as well as the robot system providers need to consider the safety in design. For
application service providers to safely operate service robots with residual safety risks, communication
between the robot system providers and the application service provider is important. For example, the
robot system providers provide appropriate information for use when application service providers
operate robots based on the comprehension of this information for use communicated by the robot
system providers of the service robot. The application service providers then give feedback to the robot
system providers on the safety-related information obtained from actual operation.
For some service robots, the design safety requirements have already been standardized in ISO 13482.
There have been application service providers that operate robots within the scope of these standards.
Although these application service providers have operated their application services safely, based
on a certain level of knowledge and experience, their methodology has not yet been systematized, nor
have the terms been standardized. It is considered that by systemizing and documenting an optimal
methodology to operate application services provided by service robots safely, the criteria to be
satisfied by new application service providers would be clarified which would then promote sound
development of the industry.
The purpose of this document is to provide application service providers using service robots with the
safety management system requirements for application services provided by service robots as a safe
operating framework.
The safety management system for the application services provided by service robots is based on
the concept of Plan-Do-Check-Act (PDCA). The PDCA model provides an iterative process used by
organizations to achieve continual improvement. It can be briefly described as follows:
— Plan: establish safety objectives and processes necessary to deliver results in accordance with the
organization's safety policy
— Do: implement the processes as planned.
— Check: monitor and measure processes against the safety policy, including its commitments, safety
objectives and operating criteria, and report the results.
— Act: take actions to continually improve.
In this document, the following verbal forms are used:
— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission;
— “can” indicates a possibility or a capability.
Information marked as “Note” is intended to assist the understanding or use of the document.
vi
INTERNATIONAL STANDARD ISO 31101:2023(E)
Robotics — Application services provided by service
robots — Safety management systems requirements
1 Scope
This document specifies the requirements of safety management systems for application services
provided by service robots [application service safety management system (hereafter ASSMS)] that an
application service provider can use for the safety of its users and its third parties when it provides
application service in unstructured human spaces with trained and untrained persons (e.g. giving
directions for visitors in airport or shopping mall, carrying goods to patients in hospital, delivering
food to customers in restaurant.)
This document is applicable to any organization that wishes to:
a) improve safety performance of application services provided by service robots,
b) establish, implement, maintain and improve safety management systems for application services
provided by service robots,
c) assure itself of conformity with its stated application service safety policy, and
d) demonstrate conformity with this document.
The requirements of this document can be conformed to by integrating safety management systems for
application services provided by service robots into, or making it compatible with, other management
systems or processes within the organization.
The requirements of this document can be conformed to by multiple organizations without omission
depending on what is done as an organization and safety management.
Although intended for application services provided by service robots, this document can also be
applied to services using robots other than service robots.
This document is not intended to be used as a product safety standard.
NOTE There are cases where the safety management systems for application services provided by service
robots established in accordance with the requirements of this document cannot apply directly when the service
robots to be used, robot systems, contents of service, places of operation, users or so, differ.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 13482:2014, Robots and robotic devices — Safety requirements for personal care robots
ISO 12100:2010, Safety of machinery — General principles for design — Risk assessment and risk reduction
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13482 and the following 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
organization
person or group of people that has its own functions with responsibilities, authorities and relationships
to achieve its objectives (3.6)
Note 1 to entry: The concept of organization includes, but is not limited to, sole-trader, company, corporation,
firm, enterprise, authority, partnership, association, charity or institution, or part or combination thereof,
whether incorporated or not, public or private.
Note 2 to entry: If the organization is part of a larger entity, the term “organization” refers only to the part of the
larger entity that is within the scope of the application service safety management system (3.4).
3.2
interested party
person or organization (3.1) that can affect, be affected by, or perceive itself to be affected by a decision
or activity
Note 1 to entry: A robot system provider is an interested party related to ASSMS.
3.3
top management
person or group of people who directs and controls an organization (3.1) at the highest level
Note 1 to entry: Top management has the power to delegate authority and provide resources within the
organization.
Note 2 to entry: If the scope of the management system (3.4) covers only part of an organization, then top
management refers to those who direct and control that part of the organization.
3.4
management system
set of interrelated or interacting elements of an organization (3.1) to establish policies (3.5) and
objectives (3.6), as well as processes (3.8) to achieve those objectives
Note 1 to entry: A management system can address a single discipline or several disciplines.
Note 2 to entry: The management system elements include the organization’s structure, roles and responsibilities,
planning and operation.
3.5
policy
intentions and direction of an organization (3.1) as formally expressed by its top management (3.3)
3.6
objective
result to be achieved
Note 1 to entry: An objective can be strategic, tactical, or operational.
Note 2 to entry: Objectives can relate to different disciplines (such as finance, health and safety, and environment).
They can be, for example, organization-wide or specific to a project, product or process (3.8).
Note 3 to entry: An objective can be expressed in other ways, e.g. as an intended result, as a purpose, as an
operational criterion, as an application service safety objective or by the use of other words with similar meaning
(e.g. aim, goal, or target).
Note 4 to entry: In the context of application service safety management systems (3.4), application service safety
objectives are set by the organization (3.1), consistent with the application service safety policy (3.5), to achieve
specific results.
3.7
risk
effect of uncertainty
Note 1 to entry: An effect is a deviation from the expected — positive or negative.
Note 2 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or
knowledge of, an event, its consequence, or likelihood.
Note 3 to entry: Risk is often characterized by reference to potential events (as defined in ISO Guide 73) and
consequences (as defined in ISO Guide 73), or a combination of these.
Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including
changes in circumstances) and the associated likelihood (as defined in ISO Guide 73) of occurrence.
Note 5 to entry: In this document, where the term “risks and opportunities” is used this means safety risks (3.39),
safety opportunities (3.40) and other risks and other opportunities for the management system.
Note 6 to entry: This constitutes one of the common terms and core definitions for ISO management system
standards given in Annex SL of the Consolidated ISO Supplement to the ISO/IEC Directives, Part 1. Note 5 to entry
has been added to clarify the term “risks and opportunities” for its use within this document.
3.8
process
set of interrelated or interacting activities that uses or transforms inputs to deliver a result
Note 1 to entry: Whether the result of a process is called an output, a product or a service depends on the context
of the reference.
3.9
competence
ability to apply knowledge and skills to achieve intended results
3.10
documented information
information required to be controlled and maintained by an organization (3.1) and the medium on
which it is contained
Note 1 to entry: Documented information can be in any format and media and from any source.
Note 2 to entry: Documented information can refer to:
— the management system (3.4), including related processes (3.8);
— information created in order for the organization to operate (documentation);
— evidence of results achieved (records).
3.11
performance
measurable result
Note 1 to entry: Performance can relate either to quantitative or qualitative findings.
Note 2 to entry: Performance can relate to managing activities, processes (3.8), products, services, systems or
organizations (3.1).
3.12
continual improvement
recurring activity to enhance performance (3.11)
3.13
effectiveness
extent to which planned activities are realized and planned results are achieved
3.14
requirement
need or expectation that is stated, generally implied or obligatory
Note 1 to entry: “Generally implied” means that it is custom or common practice for the organization (3.1) and
interested parties (3.2) that the need or expectation under consideration is implied.
Note 2 to entry: A specified requirement is one that is stated, e.g. in documented information (3.10).
3.15
conformity
fulfilment of a requirement (3.14)
3.16
nonconformity
non-fulfilment of a requirement (3.14)
3.17
corrective action
action to eliminate the cause(s) of a nonconformity (3.16) and to prevent recurrence
3.18
audit
systematic and independent process (3.8) for obtaining evidence and evaluating it objectively to
determine the extent to which the audit criteria are fulfilled
Note 1 to entry: An audit can be an internal audit (first party) or an external audit (second party or third party),
and it can be a combined audit (combining two or more disciplines).
Note 2 to entry: An internal audit is conducted by the organization (3.1) itself, or by an external party on its
behalf.
Note 3 to entry: “Audit evidence” and “audit criteria” are defined in ISO 19011.
3.19
measurement
process (3.8) to determine a value
3.20
monitoring
determining the status of a system, a process (3.8) or an activity
Note 1 to entry: To determine the status, there can be a need to check, supervise or critically observe.
3.21
application service safety performance
measurable result related to the safety of an application service (3.26)
Note 1 to entry: Examples of metrics to measure performances (3.11) relevant to the safety of an application
service are:
— continuous operation time without an accident (3.43);
— the number of near-hits (generally known as an incident which is a hazardous event (3.41) but does not cause
a harm (3.41) as a result);
— the number of improvement proposals;
— the number of persons with safety-related qualification;
— the number of emergency tests.
3.22
outsource (verb)
make an arrangement where an external organization (3.1) performs part of an organization’s function
or process (3.8)
Note 1 to entry: An external organization is outside the scope of the management system (3.4), although the
outsourced function or process is within the scope.
3.23
robot
programmed actuated mechanism with a degree of autonomy to perform locomotion, manipulation or
positioning
[SOURCE: ISO 8373:2021, 3.1]
3.24
service robot
robot (3.23) in personal use or professional use that performs useful tasks for humans or equipment
[SOURCE: ISO 8373:2021, 3.7]
3.25
robot system
system constructed for an application service (3.26), including service robots (3.24), safeguarding and
complementary protective measures independently installed by an application service provider (3.30),
communication networks, and so on
3.26
application service
action to provide benefit to a user (3.27) by interaction between a service robot (3.24) or a robot system
(3.25) and the user (3.27)
Note 1 to entry: Trials are regarded as an application service.
3.27
user
beneficiary, person who receives the benefit, of the application services (3.26) provided by the service
robot (3.24)
Note 1 to entry: In some applications, a user could be both the operator and the beneficiary.
3.28
user limit
limit or condition to limit to be a user (3.27) by his/her category and/or characteristics
Note 1 to entry: Examples of user limit are body height, body mass, age, skill, disease, clinical history, body
condition or so.
3.29
user’s behaviour limit
limit or condition to limit the behaviour of a user (3.27)
Note 1 to entry: Examples of user’s behaviour limit are acting in accordance with the operation procedure of a
service robot specified by the robot system provider (3.33), putting on a protective equipment or so.
3.30
application service provider
organization (3.1) that initiatively performs planning, implementation and providing application service
(3.26) and has overall responsibility of application service (3.26) including safety. In the case of that
application service provider outsources (3.22) operation task to operator agency (3.31), it provides a
robot system (3.25) to an operator agency (3.31) for a defined use
Note 1 to entry: There are several cases in market to establish robot system for application service. The simplest
case is using general-purpose robot system which robot system provider supply. However, in many cases,
integration of robot system according to each application service are needed. When application service provider
performs system integration by itself, it takes on the role and responsibilities of a robot system provider (3.33)
including to certify that the robot system meets relevant safety standards if necessary. When application service
provider outsourced system integration, outsourcing partner takes on these role and responsibilities depends on
contract.
Note 2 to entry: When application service provider performs planning application service, it can apply
organizational measures, and/or person-based measures to ensure the safety of application service.
3.31
operator agency
organization (3.1) that has the responsibility to manage and operate a service robot (3.24)
Note 1 to entry: Operator agency (3.31) can be a part of application service provider (3.30), otherwise can be a
different organization (3.1) which outsourced by application service provider (3.30).
EXAMPLE 1 The application of a delivery robot for transporting food and food-related items between an
operator agency (3.31) such as a restaurant, and a user (3.27) such as a restaurant customer. The restaurant, the
operator agency (3.31), that manages a person, the operator (3.23), who programs the delivery destination and
initiates the service robot (3.4) to accomplish the delivery task.
EXAMPLE 2 The application of an exoskeleton robot for personal mobility assistance by an operator agency
(3.31) such as a rehabilitation facility, to aid a user (3.27) such as a rehabilitation client. The rehabilitation
facility, operator agency (3.31), that manages a rehabilitation staff member, the operator (3.32), who provides
rehabilitation services to clients, users (3.27).
Note 2 to entry: An operator agency (3.31) is responsible for the safe operation of the service robot (3.24) for the
defined use of the application service provider (3.30). This responsibility can be identified in a contract between
the application service provider (3.30) and the operator agency (3.31), or by safe operating instructions in an
operating manual that is provided by the application service provider (3.30) to the operator agency (3.31).
3.32
operator
person or agency designated to make parameter and program changes, and to start, monitor, and stop
the intended operation of the service robot (3.24)
[SOURCE: ISO 8373:2021, 2.17, modified]
3.33
robot system provider
organization that supplies robotic components, subsystems, or systems for application service provider
(3.30). These include hardware for the physical system of a robot (3.23), and software for operation of
the hardware and control interfaces
Note 1 to entry: A manufacturer can be regarded as a robot system provider.
Note 2 to entry: A system integrator can be regarded as a robot system provider.
Note 3 to entry: A seller can be regarded as a robot system provider.
3.34
information for use
information that has a safety specification of a robot (3.23), a robot use restriction (3.35), a compliance
matter to assure safe and proper operation of machines or a residual safety risk (3.39)
Note 1 to entry: In general, information for use is provided by a robot system provider as a user manual.
3.35
robot use restriction
condition of use intended by a robot system provider (3.33) during designing including an operational
environment of robot (3.23), a user limit (3.28), a user’s behaviour limit (3.29), competence (3.9) required
to use, education and training contents to obtain the competence (3.9), a period for safety-related
performance (3.11) to be maintained, and necessary maintenance and inspection
Note 1 to entry: Robot use restriction is equivalent to “limits of machinery” specified in 5.3 of ISO 12100:2010.
Note 2 to entry: “Machinery” and “machine” is changeable to “robot” in this document.
3.36
life cycle of application service
consecutive and interlinked stages of a management system (3.4) related to an application service (3.26),
from transportation and installation of service robots (3.24) to final disposal
Note 1 to entry: The life cycle of application service stages include transportation of service robots (3.24),
installation, use, change of contents of a service, inspection, maintenance, end-of-life treatment and final disposal.
Note 2 to entry: Adapted from ISO 14001:2015, 3.3.3.
3.37
third party of application service
person who is in the operation space of an application service (3.26) but is not user (3.27) nor in charge
of the application service (3.26) as a member of the application service provider (3.30).
Note 1 to entry: In general, third party of application service do not have prior knowledge and information
relevant to the safety of a specific robot (3.23).
3.38
third party who has special knowledge
person or organization (3.1) that can be regarded to have knowledge of machinery safety
Note 1 to entry: For example, a certifier or a person who has knowledge of machinery safety [e.g. system safety
engineer, safety assessor (part), industrial safety consultant (part)].
Note 2 to entry: A member of an application service provider (3.30) can be a third party who has special knowledge.
3.39
safety risk
combination of the probability of occurrence of harm (3.41) and the severity of that harm (3.41)
3.40
safety opportunity
circumstance or set of circumstances that can lead to improvement of application service safety
performance (3.21)
3.41
harm
injury or damage to the health of people, or damage to property or the environment
[SOURCE: ISO/IEC Guide 51:2014, 3.1]
3.42
hazardous event
event that can cause harm (3.41)
[SOURCE: ISO 12100:2010, 3.9]
3.43
accident
hazardous event (3.42) which result actual harm (3.41)
3.44
inherently safe design
measures taken to eliminate hazards (3.45) and/or to reduce safety risks (3.39) by changing the design
or operating characteristics of the product or system
[SOURCE: ISO/IEC Guide 51:2014, 3.5]
3.45
hazard
potential source of harm (3.41)
[SOURCE: ISO/IEC Guide 51:2014, 3.2]
3.46
ASSMS
application service safety management system
4 Context of the organization
4.1 Understanding the organization and its context
The organization shall determine external and internal issues that are relevant to its purpose and that
affect its ability to achieve the intended result(s) of its ASSMS.
The organization shall monitor and review information about these external and internal issues.
NOTE “Issue” means an important topic or problem for debate or discussion. It can have a positive or
negative impact on the organization.
EXAMPLE 1 External issues are:
— cultural, social, legal, technological, economic and natural surroundings and market competition, whether
international, national, regional, or local;
— situation of competitors;
— relationships with its external interested parties;
— changes in relation to any of the above.
EXAMPLE 2 Internal issues are:
— the organizational activities, the strategies, the culture in the organization, competence (capital, time, human
resources and processes)
— relationships within its internal interested parties;
— changes in relation to any of the above.
The organization shall determine whether climate change is a relevant issue.
4.2 Understanding the needs and expectations of interested parties
The organization shall determine:
— the interested parties that are relevant to the application service safety management system;
— the relevant requirements of these interested parties;
— which of these requirements will be addressed through the application service safety management
system.
NOTE 1 Relevant interested parties can have requirements related to climate change.
When determining the interested parties relevant to the ASSMS, the organization shall consider:
— the owners of the robot;
— the field owners;
— the relevant administrative bodies;
— the relevant organizations to be outsourced such as operator agency;
— the robot system providers;
— the users.
NOTE 2 Generally, instructions which the robot system provider specifies in the information for use are
included in the relevant requirements of the interested parties.
NOTE 3 When the purpose of the application service changes from trial to a commercial use, generally the
interested parties that are relevant to the ASSMS and the relevant requirements of these interested parties
change. The trials are an action to provide benefit to the user while the problems (e.g. the safety and/or the
values) for practical application are verified by using the robots in the real situations.
NOTE 4 The robot system providers, even when they provide the robot for free, are considered to bear the
equivalent responsibilities to the case for a fee. For example, to provide information for use appropriately so on.
NOTE 5 An example of interested parties in application service and relationship to the defined terms in this
document are shown in Annex A.
4.3 Determining the scope of the application service safety management system
The organization shall determine the boundaries and applicability of the ASSMS to establish its scope.
When determining this scope, the organization shall consider:
— the external and internal issues referred to in 4.1;
— the requirements referred to in 4.2.
— the contents of the application service to be operated (see 6.4.3.2).
The scope shall be available as documented information.
4.4 Application service safety management system
The organization shall establish, implement, maintain and continually improve an ASSMS, including
the processes needed and their interactions to assure the application service safety performance, in
accordance with the requirements of this document.
Conformity to this document may only be claimed if the requirements determined as not being
applicable do not affect the organization's ability or responsibility to ensure the conformity of its
services.
5 Leadership
5.1 Leadership and commitment
Top management shall demonstrate leadership and commitment with respect to the ASSMS by:
— ensuring that the application service safety policy and application service safety objectives are
established and are compatible with the strategic direction of the organization;
— ensuring the integration of the ASSMS requirements into the organization’s business processes;
NOTE 1 Reference to “business” in this document can be interpreted broadly to mean those activities that are
core to the purposes of the organization’s existence.
— ensuring that the resources needed for the ASSMS are available;
NOTE 2 Specifically, it is to ensure human resources, facilities and budgets necessary to the safe operation of
the application service and to implement the plan.
— communicating the importance of effective application service safety management and of conforming to the
ASSMS requirements to workers under control of the organization and the interested parties;
NOTE 3 Specifically, it is to announce the importance of the safe operation of the application service as well as
the conformity to this document via meetings, house journals, electrical bulletin boards, e-mails or so.
— ensuring that the ASSMS achieves its intended result(s);
— directing and supporting persons who work under control of the organization and the interested parties to
contribute to the effectiveness of the ASSMS;
— promoting continual improvement;
NOTE 4 Specifically, it is to set an incentive for improvement proposals.
— supporting other relevant managerial roles to demonstrate their leadership as it applies to their areas of
responsibility.
5.2 Policy
Top management shall establish an application service safety policy that:
a) is appropriate to the purpose of the organization;
b) provides a framework for setting application service safety objectives;
NOTE 1 Provision of a framework for setting application service safety objectives is, for example, to
establish a process(es) for the meetings to decide the safety objectives of a term at the beginning of the term.
c) includes a commitment to meet applicable requirements;
d) includes a commitment to continual improvement of the ASSMS.
NOTE 2 The application service safety policy can include:
— reference to the importance of safety ensuring for the users and the third party of the application service;
— compliance with the relevant legislations;
— conformity to the requirements for ASSMS;
— allocation of appropriate resources to application service safety performance improvement;
— thorough preparation to respond to emergency situations;
— continual improvement led to enhance of application service safety performance.
The application service safety policy shall:
— be available as documented information;
— be communicated within the organization;
— be available to interested parties, as appropriate.
5.3 Roles, responsibilities and authorities
Top management shall ensure that the responsibilities and authorities for relevant roles are assigned
and communicated within the organization.
Top management shall assign the r
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...