Annex SL (normative) Proposals for management

system standards
SL.1 General
Whenever a proposal is made to prepare a new management system standard
(MSS), including sectoral applications of generic MSS, a justification study (JS) shall
be carried out in accordance with Appendix 1 to this Annex SL.
NOTE No JS is needed for the revision of an existing MSS whose development has already
been approved (unless it was not provided during its first development).

To the extent possible, the proposer shall endeavour to identify the full range of
deliverables which will constitute the new or revised MSS family, and a JS shall be
prepared for each of the deliverables.

SL.2 Obligation to submit a JS

All MSS proposals and their JS must be identified by the relevant TC/SC/PC
leadership and must be sent to the ISO/TMB (or its MSS task force) for evaluation
before the NWI ballot takes place. It is the responsibility of the relevant TC/SC/PC
secretariat to identify all MSS proposals, without exception, so that there will be no
MSS proposals which fail (with knowledge or without knowledge) to carry out the JS
or which fail to be sent to the ISO/TMB for evaluation.
NOTE No JS is required for a Type B MSS providing guidance on a specific Type A MSS for
which a JS has already been submitted and approved. For example, ISO/IEC 27003:2010
(Information technology Security techniques Information security management system
implementation guidance) does not need to have JS submitted as ISO/IEC 27001:2013
(Information technology Security techniques Information security management
systems Requirements) has already had a JS submitted and approved.

SL.3 Cases where no JS have been submitted

MSS proposals which have not been submitted for ISO/TMB evaluation before the
NWI ballot will be sent to the ISO/TMB for evaluation and no new ballot should take
place before the ISO/TMB decision (project on hold). It is considered good practice
that the TC/SC/PC members endorse the JS prior it is sent to the ISO/TMB.
NOTE Already published MSS which did not have a JS submitted will be treated as new MSS
at the time of revision, i.e. a JS is to be presented and approved before any work can begin.

SL.4 Applicability of Annex SL

The above procedures apply to all ISO deliverables including IWAs.

SL.5 Terms and definitions

For the purposes of this Annex SL, the following terms and definitions apply.
SL.5.1
management system

See definition contained in Appendix 2 (clause 3.04) of this Annex SL.

SL.5.2
Management System Standard
MSS
Standard for management systems (SL.5.1).
Note to entry: For the purposes of this document, this definition also applies to other ISO
deliverables (e.g. TS, PAS).

SL.5.3
Type A MSS
MSS providing requirements
EXAMPLES
Management system requirements standards (specifications).
Management system sector-specific requirements standards.

SL.5.4
Type B MSS
MSS providing guidelines
EXAMPLES
Guidance on the use of management system requirements standards.
Guidance on the establishment of a management system.
Guidance on the improvement/enhancement of a management system.

SL.5.5
High Level Structure
HLS
outcome of the work of the ISO/TMB/JTCG Joint technical Coordination Group on
MSS which refers to high level structure (HLS), identical subclause titles, identical
text and common terms and core definitions. See Appendix 2 to this Annex SL.

SL.6 General principles

All projects for new MSS (or for MSS which are already published but for which no JS
was completed) must undergo a JS (see SL.1 and Note to SL.3). The following
general principles provide guidance to assess the market relevance of proposed
MSS and for the preparation of a JS. The justification criteria questions in Appendix 1
to this Annex SL are based on these principles. The answers to the questions will
form part of the JS. An MSS should be initiated, developed and maintained only
when all of the following principles are observed.
1) Market
relevance

Any MSS should meet the needs of, and add value for, the
primary users and other affected parties.

2) Compatibility

Compatibility between various MSS and within an MSS

family should be maintained.

3) Topic coverage An MSS should have sufficient application coverage to

eliminate or minimize the need for sector-specific variances.
4) Flexibility

An MSS should be applicable to organizations in all relevant

sectors and cultures and of every size. An MSS should not
prevent organizations from competitively adding to or
differentiating from others, or enhancing their management
systems beyond the standard.

5) Free trade

An MSS should permit the free trade of goods and services

in line with the principles included in the WTO Agreement on
Technical Barriers to Trade.

6) Applicability
of conformity
assessment

The market need for first-, second- or third-party conformity

assessment, or any combination thereof, should be
assessed. The resulting MSS should clearly address the
suitability of use for conformity assessment in its scope. An
MSS should facilitate joint audits.

7) Exclusions

An MSS should not include directly related product

(including services) specifications, test methods,
performance levels (i.e. setting of limits) or other forms of
standardization for products produced by the implementing
organization.

8) Ease of use

It should be ensured that the user can easily implement one

or more MSS. An MSS should be easily understood,
unambiguous, free from cultural bias, easily translatable,
and applicable to businesses in general.

SL.7 Justification study process and criteria

SL.7.1 General
This clause describes the justification study (JS) process for justifying and evaluating
the market relevance of proposals for an MSS. Appendix 1 to this Annex SL provides
a set of questions to be addressed in the justification study.

SL.7.2 Justification study process

The JS process applies to any MSS project and consists of the following:
a) the development of the JS by (or on behalf of) the proposer of an MSS project;
b) an approval of the JS by the ISO/TMB (or ISO/TMB MSS task force).
The JS process is followed by the normal ISO balloting procedure for new work item
approval as appropriate.

SL.7.3 ustification study criteria

Based on Annex C of the ISO/IEC Directives, Part 1, 2012, and the general principles
stated above, a set of questions (see Appendix 1 to this Annex SL) must be used as
criteria for justifying and assessing a proposed MSS project and must be answered

by the proposer. This list of questions is not exhaustive and any additional
information that is relevant to the case should be provided. The JS should
demonstrate that all questions have been considered. If it is decided that they are
not relevant or appropriate to a particular situation, then the reasons for this
decision should be clearly stated. The unique aspect of a particular MSS may require
consideration of additional questions in order to assess objectively its market
relevance.

SL.8 Guidance on the development process and structure of an

MSS
SL.8.1 General
The development of an MSS will have effects in relation to
the far-reaching impact of these standards on business practice,
the importance of worldwide support for the standards,
the practical possibility for involvement by many, if not all, ISO Member Bodies,
and
the market need for compatible and aligned MSS.
This clause provides guidance in addition to the procedures laid down in the
ISO/IEC Directives, in order to take these effects into account.
All MSS (whether they are Type A or Type B MSS) shall, in principle, use consistent
structure, common text and terminology so that they are easy to use and
compatible with each other. The guidance and structure given in Appendix 2 to this
Annex SL shall, in principle, also be followed (based on ISO/TMB
Resolution 18/2012).
A Type B MSS which provides guidance on another MSS of the same MSS family
should follow the same structure (i.e. clauses numbering). Where MSS providing
guidance (Type B MSS) are involved, it is important that their functions be clearly
defined together with their relationship with the MSS providing requirements
(Type A MSS), for example:
guidance on the use of the requirements standard;
guidance on the establishment/implementation of the management system;
guidance on improvement/enhancement of the management system.
Where the proposed MSS is sector specific:
it should be compatible and aligned with the generic MSS;
the relevant committee responsible for the generic MSS may have additional
requirements to be met or procedures to be followed;
other committees may need to be consulted, as well as CASCO on conformity
assessment issues.

In the case of sector specific documents, their function and relationship with the
generic MSS should be clearly defined (e.g. additional sector-specific requirements;
elucidation; or both as appropriate).
Sector-specific documents should always show clearly (e.g. by using different
typographical styles) the kind of sector-specific information being provided.
NOTE 1 The ISO/TMB/JTCG Joint Technical Coordination Group on MSS has produced a set of
rules for the addition of discipline specific text to the identical text.
NOTE 2 Where the identical text or any of the requirements cannot be applied in a specific
MSS, due to special circumstances, this should be reported to the ISO/TMB through the TMB
Secretary at tmb@iso.org (see SL.9.3).

SL.8.2 MSS development process

SL.8.2.1 General
In addition to the JS, the development of an MSS should follow the same
requirements as other ISO deliverables (ISO/IEC Directives, Part 1, Clause 2).
SL.8.2.2 Design specification
To ensure that the intention of the standard, as demonstrated by the justification
study, will be maintained, a design specification may be developed before a working
draft is prepared.
The responsible committee will decide whether the design specification is needed
and in case it is felt necessary, it will decide upon its format and content that is
appropriate for the MSS and should set up the necessary organization to carry out
the task.
The design specification should typically address the following.
User
needs

The identification of the users of the standard and their associated

needs, together with the costs and benefits for these users.

Scope

The scope and purpose of the standard, the title and the field of
application.

Compatibil How compatibility within this and with other MSS families will be
ity
achieved, including identification of the common elements with similar
standards, and how these will be included in the recommended
structure (see Appendix 2 to this Annex SL).
Consistenc Consistency with other documents (to be) developed within the MSS
y
family.
NOTE Most, if not all of the information on user needs and scope will be available from the
justification study.

The design specification should ensure that

a) the outputs of the justification study are translated correctly into requirements
for the MSS,
b) the issues of compatibility and alignment with other MSS are identified and
addressed,

c) a basis for verification of the final MSS exists at appropriate stages during the
development process,
d) the approval of the design specification provides a basis for ownership
throughout the project by the members of the TC/SC(s),
e) account is taken of comments received through the NWI ballot phase, and
f) any constraints are taken into account.
The Committee developing the MSS should monitor the development of the MSS
against the design specification in order to ensure that no deviations happen in the
course of the project.
SL.8.2.3 Producing the deliverables
SL.8.2.3.1 Monitoring output
In the drafting process, the output should be monitored for compatibility and ease of
use with other MSS, by covering issues such as
the high level structure (HLS), identical subclause titles, identical text and
common terms and core definitions the need for clarity (both in language and
presentation), and
avoiding overlap and contradiction.
SL.8.2.4 Transparency of the MSS development process
MSS have a broader scope than most other types of standard. They cover a large
field of human endeavour and have an impact on a wide range of user interests.
Committees preparing MSS should accordingly adopt a highly transparent approach
to the development of the standards, ensuring that
possibilities for participation in the process of developing standards are clearly
identified, and
the development processes being used are understood by all parties.
Committees should provide information on progress throughout the life cycle of the
project, including
the status of the project to date (including items under discussion),
contact points for further information,
communiqus and press releases on plenary meetings, and
regular listings of frequently asked questions and answers.
In doing this, account needs to be taken of the distribution facilities available in the
participating countries.
Where it may be expected that users of a Type A MSS are likely to demonstrate
conformity to it, the MSS shall be so written that conformity can be assessed by a
manufacturer or supplier (first party, or self-declaration), a user or purchaser
(second party) or an independent body (third party, also known as certification or
registration).

Maximum use should be made of the resources of the ISO Central Secretariat to
facilitate the transparency of the project and the committee should, in addition,
consider the establishment of a dedicated open-access website.
Committees should involve the national member bodies to build up a national
awareness of the MSS project, providing drafts as appropriate for different
interested and affected parties, including accreditation bodies, certification bodies,
enterprises and the user community, together with additional specific information
as needed.
The committee should ensure that technical information on the content of the MSS
under development is readily available to participating members, especially those in
developing countries.
SL.8.2.5 Process for interpretation of a standard
The committee may establish a process to handle interpretation questions related
to their standards from the users, and may make the resulting interpretations
available to others in an expedient manner. Such a mechanism can effectively
address possible misconceptions at an early stage and identify issues that may
require improved wording of the standard during the next revision cycle. Such
processes are considered to be committee specific procedures [see Foreword f)].

SL.9 High level structure, identical core text and common

terms and core definitions for use in Management Systems
Standards
SL.9.1 Introduction
The aim of this document is to enhance the consistency and alignment of ISO MSS
by providing a unifying and agreed upon high level structure, identical core text and
common terms and core definitions. The aim being that all ISO Type A MSS (and B
where appropriate) are aligned and the compatibility of these standards is
enhanced. It is envisaged that individual MSS will add additional discipline-specific
requirements as required.
NOTE In Annex SL 9.1 and Annex SL 2 and 3 discipline-specific is used to indicate specific
subject(s) to which a management system standard refers, e.g. energy, quality, records,
environment etc.

The intended audience for this document is ISO Technical Committees (TC),
Subcommittees (SC) and Project Committees (PC) and others that are involved in
the development of MSS.
This common approach to new MSS and future revisions of existing standards will
increase the value of such standards to users. It will be particularly useful for those
organizations that choose to operate a single (sometimes called integrated)
management system that can meet the requirements of two or more MSS
simultaneously.
Appendix 2 to this Annex SL sets out the high level structure, identical core text and
common terms and core definitions that form the nucleus of future and revised ISO
Type A MSS and Type B MSS when possible.

Appendix 3 to this Annex SL sets out guidance to the use of Appendix 2 to this
Annex SL.

SL.9.2 Use
ISO MSS include the high level structure and identical core text as found in
Appendix 2 to this Annex SL. The common terms and core definitions are either
included or normatively reference an international standard where they are
included.
NOTE The high level structure includes the main clauses (1 to 10) and their titles, in a fixed
sequence. The identical core text includes numbered sub-clauses (and their titles) as well as
text within the sub-clauses.

SL.9.3 Non applicability

If due to exceptional circumstances the high level structure or any of the identical
core text, common terms and core definitions cannot be applied in the management
system standard then the TC/PC/SC needs to notify ISO/TMB through the ISO/TMB
Secretary at tmb@iso.org of the rationale for this and make it available for review
by ISO/TMB.
NOTE TC/PC/SC strive to avoid any non-applicability of the high level structure or any of the
identical core text, common terms and core definitions.

SL.9.4 Using Annex SL Appendix 2

Discipline-specific text additions to Annex SL Appendix 2 are managed as follows.
1. Discipline-specific additions are made by the individual ISO/TC, PC, SC or other
group that is developing the specific ISO management system standard.
2. Discipline-specific text does not affect harmonization or contradict or undermine
the intent of the high level structure, identical core text, common terms and core
definitions.
3. Insert additional sub-clauses, or sub-sub-clauses (etc.) either ahead of an
identical text sub-clause (or sub-sub-clause etc.), or after such a sub-clause (etc.)
and renumbered accordingly.
NOTE 1 Hanging paragraphs are not permitted see ISO/IEC Directives, Part 2, clause 5.2.4.
NOTE 2 Attention is drawn to the need to check cross referencing.

4. Add or insert discipline-specific text within Appendix 2 to this Annex SL. Examples
of additions include:
a) new bullet points
b) discipline-specific explanatory text (e.g. Notes or Examples), in order to clarify
requirements
c) discipline-specific new paragraphs to sub-clauses (etc.) within the identical text
d) adding text that enhances the existing requirements in Appendix 2 to this
Annex SL

5. Avoid repeating requirements between identical core text and discipline-specific

text by adding text to the identical core text taking account of point 4.2 above.
6. Distinguish between discipline-specific text and identical core text from the start
of the drafting process. This aids identification of the different types of text
during the development and balloting stages.
NOTE 1 Distinguishing options include by colour, font, font size, italics, or by being boxed
separately etc.
NOTE 2 Identification of distinguishing text is not necessarily carried into the published
version.

7. Understanding of the concept of risk may be more specific than that given in
the definition under 3.09 of Appendix 2 to this Annex SL. In this case a disciplinespecific definition may be needed. The discipline-specific terms and definitions
are differentiated from the core definition, e.g. (XXX) risk.
NOTE The above can also apply to a number of other definitions.

8. Common terms and core definitions will be integrated into the listing of terms and
definitions in the discipline-specific management system standard consistent
with the concept system of that standard.

SL.9.5 Implementation
Follow the sequence, high level structure, identical core text, common terms and
core definitions for any new management system standard and for any revisions to
existing management system standard.

SL.9.6 Guidance
Find supporting guidance in Appendix 3 to this Annex SL.