ISO 5461:2025

Space systems - Failure reporting, analysis and corrective action (FRACA) process requirements

This document provides criteria for planning or rating a failure reporting, analysis and corrective action (FRACA) process, with regard to its capability to collect, process, assess, and eliminate or control failures, in a cost-effective manner that is commensurate with the product safety or mission severity category and life cycle systems engineering product-critical characteristics data. This document is applicable for managing failures that occur to space, launch and ground control systems and equipment after qualification. The requirements in this document apply to all stakeholders that contribute to the design, analysis, test, production and operation of space systems, as required in ISO 14300-2.

Systèmes spatiaux — Exigences relatives au processus de notification des défaillances, d'analyse et d'action corrective (FRACA)

General Information

• Status: Published
• Publication Date: 07-May-2025
• ICS: 49.140 - Space systems and operations
• Technical Committee: ISO/TC 20/SC 14 - Space systems and operations
• Drafting Committee: ISO/TC 20/SC 14 - Space systems and operations
• Current Stage: 6060 - International Standard published
• Start Date: 08-May-2025
• Due Date: 02-Oct-2026
• Completion Date: 08-May-2025

Overview

ISO 5461:2025 - Space systems: Failure reporting, analysis and corrective action (FRACA) defines requirements and criteria for planning, rating and implementing a FRACA process for space, launch and ground control systems after qualification. Published as the first edition in 2025, this standard frames FRACA as a closed‑loop process to collect, verify, analyse and mitigate faults, failures and anomalies of hardware, software, firmware and test/maintenance equipment in a cost‑effective way that is commensurate with product safety or mission severity.

This document is a tier‑three standard under the ISO TC 20/SC 14 framework and supports product assurance requirements in ISO 14300‑2, linking safety, dependability and quality assurance for space systems.

Key topics and technical requirements

• FRACA process elements: reporting, failure verification, failure analysis, corrective action, verification/validation of corrective actions, and trending.
• Tailoring and capability levels: five capability levels (Level 1–5) define progressive FRACA process maturity, from basic process management and reporting to continuous improvement, training and model‑based systems engineering integration.
• Process planning and documentation: requirements for FRACA plans, procedures, resources authorization, and coordination among stakeholders.
• Risk commensurability: FRACA capability must be commensurate with product safety or mission severity categories and life‑cycle systems engineering product‑critical characteristics.
• Data quality and input maturity: criteria for input data maturity levels, cause categories, repeated failure thresholds and notional failure mode distributions (annexes provide supporting guidance).
• Audit and improvement: provisions for FRACA auditing, capability‑level growth and continuous process improvement.
• Scope of applicability: covers failures occurring after qualification during production acceptance testing, operation and disposal phases.

Practical applications and who should use it

ISO 5461:2025 is intended for organizations and roles involved in the design, analysis, test, production and operation of space systems, including:

• Space system suppliers and subcontractors
• Satellite operators and launch service providers
• Programme managers, systems engineers and quality assurance teams
• Reliability, safety and dependability engineers
• Maintenance and operations personnel

Typical use cases include establishing or assessing a FRACA implementation, integrating FRACA requirements into contracts/SOWs, improving failure investigation and corrective action workflows, and aligning FRACA with product assurance and safety programmes.

Related standards

ISO 5461:2025 is intended to be used alongside:

• ISO 14300‑2 (Product assurance)
• ISO 14620‑1 (System safety)
• ISO 23460 (Dependability assurance)
• ISO 23461 (Non‑conformance control)
• ISO 27025 (Product quality assurance) These related standards provide the broader product assurance, safety and non‑conformance management context in which FRACA operates.

Keywords: ISO 5461:2025, FRACA, failure reporting, failure analysis, corrective action, space systems, product assurance, dependability, mission severity, failure investigation.

Standards Content (Sample)

International
Standard
ISO 5461
First edition
Space systems — Failure reporting,
2025-05
analysis and corrective action
(FRACA) process requirements
Systèmes spatiaux — Exigences relatives au processus de
notification des défaillances, d'analyse et d'action corrective
(FRACA)
Reference number
© ISO 2025
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .3
4 General requirements . 4
4.1 Overview of FRACA process .4
4.2 Failure reporting .5
4.3 Failure verification .5
4.4 Failure analysis .5
4.5 Corrective action .6
5 Tailoring requirements . 7
5.1 General .7
5.2 Level 1 FRACA process .8
5.2.1 FRACA process management and resources authorization .8
5.2.2 Identification or determination of FRACA process requirements .8
5.2.3 Development or reuse of a FRACA procedure .9
5.2.4 Implementation and coordination of a FRACA process .10
5.2.5 Identification, documentation, reporting and assessment of residual failure risk .11
5.2.6 Implementation of approved corrective action(s) .11
5.2.7 Verification and or validation of corrective actions and failure events .11
5.3 Level 2 FRACA process . 12
5.3.1 Documentation and approval of a FRACA plan . 12
5.3.2 Implementation and coordination of a FRACA process . 12
5.3.3 Verification of reported failures modes . 12
5.4 Level 3 FRACA process . 12
5.4.1 Implementation and coordination of a FRACA process . 12
5.4.2 Failure analyses, corrective actions, and failure trending . 13
5.5 Level 4 FRACA process . 13
5.5.1 FRACA process audit . 13
5.5.2 FRACA process improvement . 13
5.6 Level 5 FRACA process .14
5.6.1 FRACA process continuous improvement .14
5.6.2 FRACA training and model-based systems engineering integration .14
5.6.3 Reliability development growth testing support .14
Annex A (Informative) Supplier's integrated FRACA process .16
Annex B (Informative) Product safety or mission severity category definitions . 17
Annex C (Informative) Qualitative probability level criteria . 19
Annex D (Informative) Notional shop replaceable unit (SRU) failure mode distribution .21
Bibliography .22

iii
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.
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.

iv
Introduction
The failure reporting, analysis and corrective action (FRACA) process is a closed-loop process that manages
faults, failures and anomalies of deliverable hardware, software, firmware, testing or monitoring devices
and maintenance or inspection equipment, which occur after qualification.
This document is a tier-three standard within the ISO TC 20/SC 14 hierarchical framework of space systems
requirements, for the following reasons:
a) ISO 14300-2 (product assurance) requires that system safety, dependability and quality assurance
programme be implemented during the space system life cycle. ISO 14620-1 (system safety), ISO 23460
(dependability), and ISO 27025 (quality assurance) are tier-two standards under ISO 14300-2, which is a
tier-one standard.
b) ISO 14620-1 requires that accidents and safety-critical nonconformances which occur during production,
operations and disposal phases in the space system life cycle be reported, investigated and mitigated.
ISO 23460 requires that reliability-critical failures which occur during the operations phase in the
space system life cycle be reported, analysed and subjected to risk reduction. ISO 27025 requires that
nonconformances which occur during the operations phase in the space system life cycle be reported,
reviewed and dispositioned via a corrective feedback loop. This document and ISO 23461 are tier-three
standards under ISO 14620-1, ISO 23460, and ISO 27025.
The FRACA process as defined in this document and the nonconformance management process as defined in
ISO 23461 are often assumed to provide overlapping functions during the space system life cycle. However,
the FRACA process and nonconformance management process provide separate and unique functions.
The FRACA process is first applied by the supplier to manage verified failures and anomalies of qualified
hardware and software during production acceptance testing. After delivery and deployment of the space
system, the space system operator can team-up with the supplier, via an SOW or MOA, to apply the FRACA
process during the operations and disposal phases of the space system life cycle.
The nonconformance management process is applied by the supplier to manage verified nonconformances
to requirements, from the time of the space system’s conceptual development through its delivery. It is
important to note that not all verified failures or anomalies are nonconformances and vice versa. When
the root cause of a failure or an anomaly during qualification testing is found to be an incorrect design,
fabrication, or performance requirement, then a corrective action should be determined and implemented
by the FRACA process. When the root cause of a failure or an anomaly during operation is found to be
an operator-induced damage, then a corrective action should be determined and implemented by the
nonconformance management process.
As in the case of the FRACA process, after delivery and deployment of the space system, the space system
operator can team-up with the supplier, via an SOW or MOA, to apply the nonconformance management
process during the operations and disposal phases of the space system life cycle.

v
International Standard ISO 5461:2025(en)
Space systems — Failure reporting, analysis and corrective
action (FRACA) process requirements
1 Scope
This document provides criteria for planning or rating a failure reporting, analysis and corrective action
(FRACA) process, with regard to its capability to collect, process, assess, and eliminate or control failures, in
a cost-effective manner that is commensurate with the product safety or mission severity category and life
cycle systems engineering product-critical characteristics data.
This document is applicable for managing failures that occur to space, launch and ground control systems and
equipment after qualification. The requirements in this document apply to all stakeholders that contribute
to the design, analysis, test, production and operation of space systems, as required in ISO 14300-2.
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 23461, Space systems — Programme management — Non-conformance control system
ISO 10795, Space systems — Programme management and quality — Vocabulary
ISO 14300-2, Space systems — Programme management — Part 2: Product assurance
ISO 14620-1, Space systems — Safety requirements — Part 1: System safety
ISO 17666, Space systems — Risk management
ISO 18676, Space systems — Requirements and guidelines for the management of systems engineering
ISO 19826, Space systems — Programme management — Management of product characteristics
ISO 23460, Space projects — Programme management — Dependability assurance requirements
ISO 27025, Space systems — Programme management — Product quality assurance requirements
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in 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.1
could not verify
CNV
reported effects of an anomaly or failure observed during operation that could not be repeated or verified
during a subsequent evaluation
3.1.2
capability-based FRACA
capability of a defined set of safety, dependability and quality assurance (SD&QA) processes to effectively
address SD&QA-related risks that are applicable to a specific systems engineering (SE) life cycle phase of a
specific product or category of products
3.1.3
capability-level growth
measured improvement in the capability of a defined set of safety, dependability and quality assurance
(SD&QA) processes to effectively address SD&QA-related risks that are applicable to a specific systems
engineering (SE) life cycle phase of a specific product or category of products
3.1.4
cause category
general type of failure cause to which the failed item belongs
3.1.5
FRACA event
failure that occurs during engineering development testing [e.g. reliability life testing (RLT), environmental
stress screening (ESS) and qualification acceptance test procedure (QATP)], during production testing [e.g.
final ESS and final acceptance test procedure (FATP)] or during operation in the field
3.1.6
input data maturity level
qualitative measure of the relative accuracy of the input data in relation to what is considered the most
accurate data
3.1.7
repeated failure
unit of measure threshold applied to repeated occurrences of an identical verified failure mode in different
identical products
EXAMPLE Some space product customers consider three occurrences of an identical verified failure mode in
three different identical products to be a repeated failure threshold.
3.1.8
stakeholder
person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity
3.1.9
timely
performance of a task, subtask, or effort when planning and execution results in the output being provided
with sufficient time for management, if need be, to identify and implement cost-effective action
EXAMPLE Action that avoids or minimizes schedule delays and cost increases for achieving, preserving or
verifying system dependability requirements.
[1]
[SOURCE: ANSI/AIAA Standard S-102.0.1-2019 ]

3.2 Abbreviated terms
BIT built-in test
CDRL contract data requirements list
DED data element description
EDMS electronic data management system
ESS environmental stress screening
FCC failure cause category
FATP final acceptance test procedure
FMEA failure mode and effects analysis
FMECA failure mode, effects and criticality analysis
FRACA failure reporting, analysis and corrective action
FRACAS failure reporting, analysis and corrective action system
FRB failure review board
FTA fault tree analysis
ITAR International Traffic in Arms Regulations
LLAA lessons learned approval authority
MFG manufacturing
MOA memorandum of agreement
MTBCF mean time between critical failures
MTBF mean time between failures
PHS&T Packaging, Handling, Storage and Transportation
QA quality assurance
QATP qualification acceptance test procedure
R&R remove and replace
RCCA root cause corrective action
RDGT reliability development growth testing
RLT reliability life testing
SD&QA safety, dependability and quality assurance
SE systems engineering
SOW statement of work
SRU shop replaceable unit
SPEC specification
TPM technical performance metrics
4 General requirements
4.1 Overview of FRACA process
In the context of this document, the primary functions of the FRACA process shall be to establish and
manage a closed-loop system that is capable of effectively processing and managing the failure reports
and failure analysis reports of qualified hardware and software products, throughout their useful life.
The FRACA process also enables formal reviews of failures, for example, by failure review boards, which
adjudicate anomalies and failures related to functionality and performance after qualification testing, and
which decide on corrective actions to prevent unacceptable anomalies and failures from recurring.
An often-applied ancillary function of the FRACA process is to determine and monitor the mean time
between critical failures (MTBCF) of an operational and replenishable satellite constellation, by verifying
each operational failure and anomaly event in addition to reporting them and analysing them for root cause
corrective actions.
The supplier shall implement the FRACA process when power is first applied to the lowest indenture level of
the first article of each deliverable product, or when that product is subjected to configuration control (i.e.
the drawings or code is placed under change control).
The FRACA process shall include the determination and implementation of vetted root cause corrective
action (RCCA) methods, as needed, for timely elimination or control of the causes of hardware and software
failures detected at all levels of test and inspection. RCCA tasks range from simple activities like, interpreting
built-in test (BIT) results and performing routine remove and replace (R&R) actions, to complicated
activities, like making design changes and retrofitting fielded systems with new components to eliminate or
reduce the recurrence of failures. A notional FRACA closed-loop system is shown in Figure 1.
Figure 1 — FRACA closed-loop system

4.2 Failure reporting
On qualification and production hardware and software, anomalies shall be reported at all levels of test
and inspection after the first application of power at the lowest level of the assembly. Each failure shall
require investigation for the cause (failure analysis) and corrective action. An unscheduled adjustment,
other than a calibration made during maintenance actions, shall be considered a failure for the purposes
of the FRACA process. Piece-part failure analyses shall be incorporated into the FRACA process. Failures
of equipment undergoing reliability development growth testing (RDGT) shall be included in the FRACA
process. Functional failures caused by software or hardware to software interfaces shall be included in the
FRACAS process and be subject to the same failure analysis and corrective action processes.
All hardware or software with the same configuration as the affected item shall be considered suspect and
assessed for probability of exhibiting the identical failure mode. Serialized suspect system hardware or
software shall be reported and addressed by the serial number in corrective action statements.
During testing of research and advanced development prototype and prequalification hardware and
software, logs shall be maintained of significant events, discrepancies and anomalies. These logs shall
represent a complete failure and discrepancy history of each item. These logs shall be periodically reviewed,
and hardware and design corrective actions taken to eliminate failure causes.
4.3 Failure verification
Following the entry of each failure into the FRACA process, the actual occurrence of the anomalous incident
shall be verified; and the failure shall be validated as a legitimate problem or failure. Verification may be
accomplished either by repeating the actions that led to the failure or by reviewing the direct evidence of the
failure. These findings shall be documented, along with a detailed explanation of the verity and validity of
the initial report entry, by means of an update to the original report. Examples of appropriate documentation
include eyewitness statements, timelines, test monitoring equipment printouts, photographic evidence,
schematics and logic diagrams, and requirements traces. The supplier shall consult with the customer
where system requirements require clarification. Requirements for the use of built-in-test (BIT) capabilities
in verifying anomalies shall be documented in the FRACA plan.
The severity classification for verified failures shall be defined and qualified or rated based on the
downstream effect(s) on the system or mission. Table 1 provides the baseline failure severity classification
criteria.
4.4 Failure analysis
Depending on the FRACA process capability level required, each verified anomaly or failure shall be analysed
to determine the proximate, contributing, or root cause(s), and to determine the appropriate corrective
action(s). The results of investigations and analyses shall be documented in the failure analysis report, and
approval of investigation and analysis results shall be by an authorized signatory. The investigations and
analyses shall be documented and include the following:
a) a systematic assessment of candidate root causes for the failure using an appropriate methodology, such
as fishbone analysis;
b) identification of single and multiple failure mechanisms that could have caused the observed failure,
using an appropriate methodology, such as fault tree analysis;
c) a mapping of potential failure mechanisms with candidate root causes, using an appropriate
methodology, such as fault tree analysis;
d) a description of the sequence of events that occurred prior to the observed failure to identify definite or
candidate root causes, using an appropriate methodology, such as event tree analysis.
If a capability level 3 FRACA process is required, the supplier shall perform root cause analysis to determine:
— what happened;
— why it happened;
— what can be done to prevent it from reoccurring.
Impartial experts representing multiple disciplines, including those individuals most familiar with the
circumstances under which the failure occurred, review the failure documentation and other information
sources to identify basic and contributing causes. A thorough root cause analysis shall fully characterize the
processes and systems related to the failure, analyse the causal chain through a series of “why” questions
that reach the root cause, identify the contribution of human actions and other risk elements, and identify the
actions (or improvements to processes and systems) that would have prevented the failure from occurring.
4.5 Corrective action
The supplier shall identify and document the appropriate corrective action, or set of actions, to:
— prevent recurrence of correctable failures throughout the product’s useful life; and
— mitigate the effects of anticipated failures.
The supplier shall consider cost, schedule and other programmatic constraints in identifying the appropriate
corrective action. If no corrective action is warranted, the supplier shall provide adequate documentation
to support this conclusion. The supplier shall track the approved corrective action to completion, and
throughout that process, the adequacy of the corrective action and its implementation shall be assessed and
documented.
In assessing the appropriate corrective action, the supplier shall obtain input from all product assurance
disciplines potentially affected by the failure in accordance with ISO 14300-2, including system safety in
accordance with ISO 14620-1, systems engineering, reliability and maintainability in accordance with
ISO 23460, quality assurance in accordance with ISO 27025, test and evaluation, and risk management
in accordance with ISO 17666. Customer input shall also be obtained if required, or where the impact of
redesign trade-offs on requirements is unclear. The supplier shall assure that each approved corrective
action is appropriate to meet the product’s qualification/certification requirements, including packaging,
handling, storage and transportation (PHS&T) requirements, in a timely and verifiable manner, by:
a) providing a detailed description of the approved corrective action;
b) assigning qualified personnel to be responsible for implementing the corrective action;
c) preparing a detailed schedule and establishing criteria for performing each step of the corrective action;
d) monitoring and reporting the progress of the corrective action during its implementation;
e) reviewing the results of the corrective action to verify all applicable requirements are met;
f) gathering metrics and lessons learned on the corrective action following its completion;
g) documenting close-out of the initial product failure report if the desired effectivity of the corrective
action is satisfact
...