ISO 21886:2026

International
Standard
ISO 21886
Second edition
Space systems — Configuration
2026-09
management
Systèmes spatiaux — Gestion de la configuration
Reference number
© ISO 2026
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 General . 2
5 Configuration management planning . 3
5.1 General .3
5.2 Configuration management plan .3
5.3 Configuration management interfaces .3
6 Configuration identification . 4
6.1 General .4
6.2 Main activities of configuration identification .4
6.3 Product tree .4
6.4 Configuration item .4
6.5 Selection of configuration items .5
6.6 Configuration documents list . .5
6.7 Identification marking .6
6.7.1 General .6
6.7.2 Configuration item identifier .6
6.7.3 Configuration document identifier .6
6.8 Configuration document .7
6.9 Configuration baseline .8
6.10 Configuration change documentation .9
6.11 Publication and maintenance of the configuration documentation .9
7 Configuration control . 9
7.1 General .9
7.2 Configuration control requirements.9
7.3 Change .9
7.4 Deviation or waiver . 12
7.4.1 Deviation or waiver requirements . 12
7.4.2 Deviation or waiver classification . 12
7.4.3 Deviation or waiver application . 12
7.4.4 Deviation and waiver control procedure. 13
7.5 Interface control . .14
8 Configuration status accounting .15
8.1 General . 15
8.2 Configuration status accounting requirements. 15
8.3 Configuration status accounting process .16
8.3.1 General .16
8.3.2 Configuration documents accumulation.16
8.3.3 Configuration documents handover .16
8.3.4 Data collection .16
8.3.5 Record of the configuration status .16
8.3.6 Report of the configuration status .17
8.3.7 Configuration status accounting system analysis.17
9 Configuration verification . 17
9.1 General .17
9.2 Verification of the product configuration definition .17
9.3 Verification of the product configuration .17
10 Configuration audit .18

iii
10.1 General .18
10.2 Configuration audit requirements .18
10.3 Configuration audit team .18
10.4 Responsibilities of the supplier and the customer .18
10.5 Meeting minutes.19
10.6 Functional configuration audit .19
10.7 Physical configuration audit . 20
10.8 Others . 20
11 Configuration control board .20
Annex A (informative) Structure and content of a configuration management plan .22
Annex B (informative) Configuration management .24
Annex C (informative) Configuration status accounting reports .25
Bibliography .28

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 20, Aircraft and space vehicles, Subcommittee
SC 14, Space systems and operations.
This second edition cancels and replaces the first edition (ISO 21886:2019), which has been technically
revised.
The main change is as follows:
— revision of the descriptions of class 2 in 7.3.1.3 to ensure consistency.
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
The space system is a complex system that requires configuration management to ensure its success.
Configuration management establishes and maintains a consistent record of a product's functional and
physical characteristics in relation to its design and operational requirements. This process enables
personnel to be aware, at any time, of the technical description of a product through approved documentation,
as well as the operational capabilities and limitations of each product.

vi
International Standard ISO 21886:2026(en)
Space systems — Configuration management
1 Scope
This document defines the contents, methods and requirements of configuration management for space
projects, and the responsibilities and authorities of related parties. It is intended to be used in conjunction
with ISO 14300-1:2023, Clause 10.
This document is applicable to the configuration management of space projects from the mission analysis
phase to the disposal phase.
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 14300-1, Space systems — Programme management — Part 1: Structuring of a project
ISO 10007, Quality management — Guidelines for configuration management
ISO 10795, Space systems — Programme management and quality — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14300-1, ISO 10007, ISO 10795 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
configuration
interrelated functional characteristics (3.1.1) and physical characteristics (3.1.2) of a product or service
defined in configuration document (3.4)
3.1.1
functional characteristic
performance parameter and design constraint to be realized or required, including operational and logistic
parameters and their respective tolerances
Note 1 to entry: Functional characteristics include all performance parameters such as range, speed, lethality,
reliability, maintainability and safety.
3.1.2
physical characteristic
quantitative and qualitative expression of a product and its tolerance
EXAMPLE Mechanical, electrical, chemical or biological characteristic.

3.2
configuration management
activity for establishing and maintaining consistent records of the status of and changes (3.7) to the
performance parameters of a product and its functional and physical attributes compared to the product
design and operational requirements
Note 1 to entry: Configuration management is applied throughout the entire life of the product (i.e. development,
production, deployment, operation and disposal).
3.3
configuration item
aggregation of hardware, software, processed materials, services or any of its discrete portions, that
is designated for configuration management (3.2) and treated as a single entity in the configuration
management process
Note 1 to entry: A configuration item can contain other configuration item(s).
3.4
configuration document
document that defines the requirements for the function, design, build, production and verification for a
configuration item (3.3)
Note 1 to entry: For space systems, configuration documents can include documents relating to the operation and
disposal of the configuration item.
3.5
configuration baseline
approved status of requirements and design of a product at a project key milestone that serves as the
reference for activities throughout the life cycle of the product
3.6
change control
activity for controlling the changes (3.7), deviations or waivers to the product after the formal approval of
its configuration baseline (3.5)
3.7
change
official numerically issued alterations to a document or any portion thereof, usually brought about by
changed conditions or more complete information
4 General
4.1 Configuration management establishes and maintains a consistent record of product functional and
physical characteristics compared to its design and operational requirements. It shall be applied throughout
the product’s life cycle and improved as the project develops.
4.2 Establish the configuration control board (CCB) consisting of representatives of related fields based
on the complexity of the configuration item and its position in the project breakdown structure. The CCB
consists of permanent representatives of all program or project disciplines necessary for reviewing and
evaluating changes. The members of the CCB are with the decision-making authority.
4.3 Each supplier shall develop a configuration management (CM) plan responding to the customer’s
configuration management requirements. The CM plan shall specify the objectives, missions, responsibilities
and requirements of each phase during the entire life cycle and make necessary revisions according to the
specific circumstances as the project develops.
4.4 Configuration management interfaces with engineering, product assurance, manufacturing and
production. It contributes to the programme or project organization and execution schedule by identifying
all constraints related to the business agreement provisions.

5 Configuration management planning
5.1 General
Configuration management planning is aimed at specific configuration items. Effective configuration
management planning coordinates configuration management activities in a specific context over the
product life cycle, which shall be performed during the project’s initial phase.
Configuration management planning shall:
a) ensure the configuration management process can comprehensively and accurately record and control
the evolution of product configuration;
b) ensure the participating personnel know the correct configuration documents of a product at any time;
c) ensure the configuration documents used are complete, correct, controlled and approved;
d) ensure the traceability of the configuration evolution;
e) ensure the consistency of internal and external interfaces of a product;
f) ensure the consistency of the configuration of the inspected product and requirements of the technical
documents.
5.2 Configuration management plan
5.2.1 The configuration management plan is a document that outlines the organization’s responsibilities,
procedures, resources and methods for implementing configuration management. The result of this planning
process is the configuration management plan itself. The configuration management plan prepared by the
supplier shall be submitted to the customer for approval in response to a requirement from customer.
5.2.2 For a configuration item, the configuration management plan shall:
a) meet the requirements of the contract;
b) establish the overall objective and phase objectives for the implementation of configuration
management;
c) specify the responsibilities and authorities for the implementation of configuration management;
d) establish the procedure and means to implement configuration management;
e) conform to the configuration requirements defined by the customer;
f) clarify the interface control requirements;
g) ensure that the process of the configuration management is under control.
5.2.3 Annex A provides the structure and basic contents of the configuration management plan.
5.3 Configuration management interfaces
Configuration management is an integral part of project management. Configuration management processes
shall interface with engineering management, product assurance, product manufacturing and information
or documentation management. The contractual provision and schedule shall also be considered when
defining and phasing of configuration management activities.

6 Configuration identification
6.1 General
Configuration identification incrementally establishes and releases controlled documentation to identify a
product’s configuration characteristics until they are fully defined concerning its intended functional and
physical characteristics. Configuration identification establishes and maintains a documentation basis for
configuration control, status accounting, verification and audit, and it is the basis for the configuration
management implementation. The management of the configuration documents shall be incorporated into
the information or documentation management process; and the relationship is detailed in Annex B.
6.2 Main activities of configuration identification
Main activities of configuration identification are:
a) selecting configuration items based on the project breakdown structure and product tree; processes
and requirements of project breakdown structures are performed according to ISO 27026;
b) determining configuration documents produced at different phases (including internal and external
interface documents) and form the preliminary configuration documents list;
c) specifying identifiers for configuration items and configuration documents;
d) producing configuration documents based on the approved configuration documents list;
e) establishing the configuration baseline;
f) documenting the configuration change information and provide its identifier.
6.3 Product tree
6.3.1 The supplier shall break down the task of the project, starting from the functional requirements
and following certain logic and requirements defined by level 1 customer. Based on the project breakdown
structure, the supplier shall determine the project structure levels and the corresponding work and
complete the respective product trees in accordance with each product’s functional requirements.
6.3.2 The product tree, based on the approved final function, breaks down the system into successive
levels and defines the top-down architecture framework of a product, such as system level, subsystem level,
unit level.
6.3.3 The supplier shall ensure that the product tree can comprehensively describe the product’s
successive breakdown, compositions and positions and the necessary configuration items to deliver the
product function.
6.3.4 The product tree is established based on historical information or knowledge gained through the
project and shall be updated under configuration control.
6.4 Configuration item
6.4.1 Configuration items are selected based on the project breakdown structure and product tree.
Configuration items correspond to the structure of product tree and are identified at various levels of the
product tree.
6.4.2 Configuration items fall into two categories: developed configuration item and non-developed
configuration item. A developed configuration item is subject to development and fully or partially designed
for the programme or project. In contrast, a non-developed configuration item is a standardized or off-

the-shelf product not explicitly developed for the programme or project. Both categories shall be managed
according to configuration management requirements.
6.5 Selection of configuration items
6.5.1 Select configuration items as early as possible. Configuration items of upper levels (system and
subsystem level) shall be selected at the early definition phase; configuration items of lower levels (unit
level) shall be selected at the initial stage of its life cycle.
6.5.2 The number of configuration items selected shall consider the management effect, cost, risks,
including safety and security, and development time, etc., to maximize the organization’s project control
capacity.
6.5.3 The organization shall determine configuration items according to certain selection criteria. The
selected configuration items usually are:
a) items whose functional and physical characteristics can be separately managed;
b) items of system level, subsystem level or developed cross-unit and cross-sector;
c) items that have critical characteristics from a safety, risk and mission success point of view;
d) items that incorporate new design, technology or methods;
e) items interfacing with other items;
f) items designated for separate procurement;
g) items that are critical for use and security.
6.5.4 For configuration items controlled by the customer and their related baseline review, the customer
and supplier shall consult mutually to determine the principles defined in the configuration management
plan.
6.5.5 A list of confirmed configuration items shall be submitted to the customer for approval. The list shall
indicate the structure (system, subsystem and unit), names and identifiers of the configuration items.
6.5.6 Review and update configuration items as the project develops.
6.6 Configuration documents list
6.6.1 Each supplier shall determine the configuration documents related to design, manufacturing,
testing, operation, maintenance, storage, etc. (including internal and external interface documents) to be
prepared during the entire life cycle of the product. The configuration documents list shall be improved and
updated with the progress of configuration identification activities.
6.6.2 The configuration documents list shall include:
a) document title and identifier;
b) type of document;
c) phases during the life cycle;
d) expected release time (determined by the phases and supplier’s schedule);
e) preparation company and document status;
f) classification (open, classified), etc.

6.6.3 The configuration documents list prepared by the supplier shall be submitted to the customer for
approval.
6.7 Identification marking
6.7.1 General
For confirmed configuration items, their identification marking mainly includes configuration item
identifiers and configuration document identifiers.
6.7.2 Configuration item identifier
6.7.2.1 The configuration item identifier is a code to indicate the item (product) designation and type.
It shall be produced by the customer, supplier or related parties according to its sources and breakdown
structure (such as system, subsystem, unit).
6.7.2.2 A configuration item identifier shall be unique. A configuration item identifier shall include:
a) model identifier;
b) serial number;
c) configuration item identifier;
d) manufacturer identifier;
e) product name, etc.
6.7.2.3 Identifiers for standard products and off-the-shelf products shall conform to relevant standards
and requirements.
6.7.3 Configuration document identifier
6.7.3.1 Configuration document identifier is a code to indicate the entity described and the document
type. The supplier usually produces it according to internal regulations.
6.7.3.2 A configuration document identifier shall be unique.
NOTE To prevent using the same identifier for different products (items), it is common practice to prefix the
identifier with an enterprise identifier.
6.7.3.3 A configuration document identifier usually includes the name of the publisher, document
identifier, phase identifier, status identifier, document change or revision identifier, etc., and it shall be
marked at certain positions of technical documents (such as the title bar):
a) name of the publisher: name or name abbreviation of the document publisher;
b) document identifier: document number consists of product identifier, entity code, code and document
category number, where:
1) product (item) identifier is the symbol specified to distinguish different products;
2) entity code is the code specified to distinguish the technical documents for different types of
products, generally including the model product code, design serial number, etc.;
3) code is the code specified by specific rules and based on the hierarchal relation or technical
characteristics of products;
4) document category number is the code specified to distinguish the different types of documents;

5) enterprise code is the code specified by supplier to distinguish different suppliers;
6) documents describing the same configuration item shall be numbered consecutively;
c) phase identifier: to identify the phase where the formed document is located in the product′s entire life
cycle; see ISO 14300-1 for phase division;
d) status identifier: to indicate the status of entity, such as M for model satellite, F for mission satellite;
e) document change implementation identifier: the implementation document change identifier includes
the change to the number of implementation document and the shift in the marks.
6.8 Configuration document
6.8.1 The organization shall prepare a complete set of configuration documents according to the
configuration documents list required by each phase during the life cycle.
6.8.2 During the project’s development, document each configuration item’s functional characteristics,
physical characteristics, interfaces, changes and other information and assign them unique identifiers.
6.8.3 The information of a configuration item is usually described in the following documents:
a) specification: a document defining requirements, including functional specification and technical
specification (such as the system specification, development specification, product specification,
process specification, material specification), functional specification and technical specification are
prepared in accordance with ISO 21351;
b) drawing: a document showing the product structure, composition, shape and other information using
either graphics or the specified symbols, including drawings and diagrams;
c) list: a document describing the composition and quantity of products or documents using tables or lists,
including summary lists, supporting lists and complete-set document list, etc.;
d) procedure and manual: a document specifying the approaches and requirements for carry out an
activity or a procedure, such as the operation procedure, operation and maintenance manual.
6.8.4 The realization of objectives during project development is usually defined by three types of
configuration documents: functional configuration document, development configuration document and
product configuration document.
6.8.4.1 The functional configuration document defines the customer’s mission demand, specifying
the overall functional requirements, mission requirements, interface requirements, design constraints,
acceptance and operation requirements. It is usually expressed as either a functional specification or system
specification, or both.
The functional configuration document usually includes the following:
a) mission definition;
b) performance, risk, requirements and objective;
c) functional and physical characteristics of the main system or sub-system;
d) internal and external interface requirements;
e) design criteria, conditions and operation constraints;
f) test and reliability requirements;
g) organization, cost, schedule, etc.

6.8.4.2 The development configuration document defines functional requirements, mission requirements,
interface requirements, design constraints, acceptance and operation requirements for compositions and
items assigned from an upper-level configuration item. The development configuration document is usually
expressed as a development specification.
The development configuration document usually includes:
a) requirements of functional characteristics of the system, sub-system or unit;
b) major physical characteristics of the system, sub-system or unit;
c) internal and external interface requirements of the system, sub-system or unit;
d) requirements for all tests or reviews necessary to verify the design;
e) design criteria, design constraints, etc.
6.8.4.3 The product configuration document defines functional characteristics, physical characteristics,
inspections and acceptance requirements of a specific item; it includes a complete site of technical documents
describing design, manufacturing, acceptance, operation, support and interfaces of the delivered products.
The product configuration document is usually expressed as product specifications, material specifications,
procedure specifications, drawings, diagrams, lists, etc.
6.8.4.4 Functional, development and product configuration documents are prepared, reviewed and
maintained during each phase of the life cycle. The three types of documents are gradually expanded and
detailed, coordinate and traceable.
6.8.4.5 When conflicts arise among functional, development and product configuration documents, their
order of precedence is the functional, development and product configuration document.
6.9 Configuration baseline
6.9.1 The project is usually divided into several phases in order to achieve the overall objective. Each
phase has its aim and task. For configuration management, the aim of each phase is realized through the
establishing a configuration baseline.
6.9.2 A configuration baseline comprises the documentation that is formally approved at certain
points during the project’s development. The documentation is designated as the baseline for subsequent
development and production activities. The baseline is determined together by the supplier and the customer
and shall be used as the starting point for configuration control.
6.9.3 During the life cycle of the product, configuration baselines are elaborated in the following sequence.
a) From the feasibility phase (phase A), establish the functional baseline at the early definition phase
(phase B). The functional baseline is complete when the documentation of overall requirements on the
function, performance and interface index are approved by the customer.
b) From the early definition phase (i.e. after the establishment of the functional baseline), establish the
development baseline at the late definition phase (phase B). The development baseline is complete
when the documentation of requirements on the function, performance and interface of the lower-level
configuration item is confirmed by the supplier.
c) The product baseline is established in the late production phase (phase D) and after the product
qualification. It includes the documentation and approved changes necessary for product manufacturing,
assembly, testing, acceptance and operation.
6.9.4 New configuration control points can be added for systems, sub-systems and lower levels based on
the item’s complexity and the mission’s progress. For example, the design baseline can be established from

the early development phase (phase C) and after the critical design review. The design baseline includes
technical specifications and design data documents prepared by the supplier and corresponding documents
of configuration items of lower levels.
6.10 Configuration change documentation
6.10.1 When a baseline is established, all changes after it shall be documented and each document shall
have a unique identifier to keep consistency between documents and entities.
6.10.2 The configuration change documentation includes change request, change proposal, application for
deviation and waiver and related implementation documents after approval.
6.10.3 Identifiers for implementation documents shall usually include change implementation document
number, change frequency and change places, etc.
6.11 Publication and maintenance of the configuration documentation
Submit the approved configuration documents by the specified time for publication. The supplier shall keep
and control the original copies of all configuration documents.
7 Configuration control
7.1 General
Configuration control is the process for controlling the evolution of, or deviations or waivers from
agreed baselines. It includes the preparation, justification, evaluation, disposition and implementation of
engineering and contractual changes, deviations and waivers.
7.2 Configuration control requirements
7.2.1 In order to keep consistency between configuration documents and entities, the supplier shall
perform configuration change control for controlling the evolution of, or deviations or waivers from agreed
baselines.
7.2.2 Configuration control starts when the functional baseline is established and is performed during the
project’s entire life cycle. Configuration control generally includes:
a) determining the category of configuration control;
b) determining the procedure of configuration control implementation, responsibilities, methods and
requirements;
c) implementing control over configuration changes;
d) tracking and verifying the implementation of approved changes.
7.2.3 For any changes, deviations or waivers, describe its effect on higher level and relevant configuration
items. Related changes of several products resulting from a common need for change shall be processed
simultaneously. Changes related to an element common to several products shall be presented to all the
concerned parties for effect assessment.
7.3 Change
Change refers to an alteration made on formally approved configuration documents during the project’s
development. The customer and the supplier can both propose a “change request”. For a "change request"
proposed by the customer, notify the supplier in written form and get the supplier′s reply in the form of an

approved "change proposal" in a certain time period before implementation. For a "change proposal" which
will affect either contract or technical requirements, submit it to the customer-level configuration control
board for review and approval before implementation.
7.3.1 Change classification
7.3.1.1 Changes fall into two categories: class 1 (major) and class 2 (minor). The supplier may further
detail the changes according to the management requirements and on the premise that the changes are
under control.
7.3.1.2 Class 1 changes include:
a) changes specified by the customer and affecting contract requirements:
1) cost;
2) warranty clause;
3) delivery requirements;
4) arrangement of major events;
b) changes either functional or development configuration documents, or both; as a result, the following
requirements exceed specified values:
1) functional and performance definitions;
2) reliability, maintainability, safety, survivability, environment adaptability and electromagnetic
compatibility etc.;
3) interface characteristics;
4) critical physical characteristics, such as structure size, mass, moment of inertia;
5) other requirements having a direct impact on the success of the project;
c) changes to product configuration documents that have a significant impact on the following:
1) either functional or development configuration documents or both, as specified in a) and b) above;
2) support equipment and application software;
3) interchangeability of configuration items and their compositions;
4) delivered operation and maintenance manual;
5) already delivered items, etc.
Class 1 changes shall be submitted to the configuration control board at appropriate level for review. Class 1
change can only be implemented after approval from the configuration control board.
7.3.1.3 Class 2 changes do not impact the criteria above for class 1 changes. The supplier shall implement
...