ISO/IEC/IEEE FDIS 24748-8

• Abstract:

  This document establishes the requirements for technical reviews and audits to be performed throughout the acquisition life cycle for the US Department of Defense (DoD) and other defense agencies. This document provides the definition, description, and intent, as well as the entry, exit and success criteria, for each technical review and audit. It is to be used to establish agreement between acquirers and suppliers on the technical reviews and audits that are needed for the project, as well as the focus and expectations of each technical review and audit.

• Status: Not Published
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7/WG 7 - Life cycle management
• Current Stage: 5060 - Close of voting Proof returned by Secretariat
• Start Date: 28-Apr-2026
• Completion Date: 27-Apr-2026

• Revises: ISO/IEC/IEEE 24748-8:2019 - Systems and software engineering — Life cycle management — Part 8: Technical reviews and audits on defense programs
• Effective Date: 08-Mar-2025

Overview

ISO/IEC/IEEE FDIS 24748-8:2025 is an international standard developed by ISO, IEC, and IEEE for the management of technical reviews and audits throughout the life cycle of defence programs. This standard establishes comprehensive requirements for the planning, execution, and completion of technical reviews and audits during the acquisition and development of defence systems. It supports the needs of government and defence agencies-such as the US Department of Defense (DoD)-and other organizations that require rigorous life cycle management processes to ensure system quality, compliance, and mission readiness.

The document provides definitions, entry and exit criteria, and describes the intent and process for each type of technical review and audit, facilitating clear agreement between acquirers (such as defence departments) and suppliers (contractors, vendors, or development teams) on project expectations and deliverables.

Key Topics

• Technical Reviews and Audits
  The standard defines the requirements, purposes, and processes for each stage, including what constitutes a successful technical review or audit.

  • Alternative Systems Review (ASR)
  • System Requirements Review (SRR)
  • System Functional Review (SFR)
  • Preliminary and Critical Design Reviews (PDR & CDR)
  • Test Readiness, Production Readiness, and Verification Reviews (TRR, PRR, SVR)
  • Configuration Audits (Functional and Physical)
  • Agile-focused reviews (e.g., Project Initiation Review, Iterative Planning Review)

• Configuration Management
  Ensures all system elements and configurations are reviewed for consistency, integrity, and traceability, linking reviews and audits directly to configuration control and baseline management.

• Project Assessment & Control
  Aligns technical reviews and audits with ISO/IEC/IEEE 15288 life cycle processes to monitor project progress, determine technical maturity, and support informed management decision-making.

• Validation and Digital Engineering
  Integrates validation activities and digital engineering practices, including model-based approaches and efficient information exchanges, enhancing data consistency and traceability across the project life cycle.

• Agile and Iterative Development
  Accommodates both traditional and agile acquisition pathways, supporting reviews and audits for incremental and iterative software and systems development in defence contexts.

Applications

ISO/IEC/IEEE FDIS 24748-8 is applicable in multiple contexts, providing practical value in:

• Establishing clear agreements between acquirers and suppliers on technical reviews and audit requirements for defence projects.
• Supporting project managers, systems engineers, auditors, and quality assurance teams in meeting compliance and governance obligations throughout the defence acquisition life cycle.
• Facilitating process improvement and assessment, providing a reference for organizations aiming to align with internationally recognized best practices in systems and software engineering.
• Enabling effective project assessment, control, validation, and decision-making at key life cycle stages or risk-based decision points, particularly when managing complex, high-assurance defence systems.
• Supporting organizations transitioning to or integrating digital engineering practices, or adopting agile methodologies, while maintaining compliance with rigorous defence program requirements.

Related Standards

For comprehensive life cycle management and technical governance, the following standards should be considered alongside ISO/IEC/IEEE FDIS 24748-8:

• ISO/IEC/IEEE 15288: Systems and software engineering – System life cycle processes
• ISO/IEC/IEEE 24748-1: Systems and software engineering – Life cycle management – Part 1: Guide for life cycle management
• ISO/IEC/IEEE 24748-2: Guidance on the application of life cycle processes
• ISO/IEC 24765: Systems and software engineering vocabulary (SEVOCAB)
• IEEE 828: Configuration management in systems and software engineering
• SAE EIA-649-1A: Configuration management requirements for defence contracts
• ISO/IEC 33202: Software engineering - Guidelines for agile development
• ISO/IEC/IEEE 24748-10: Life cycle management - Part 10: Agile development

By adopting ISO/IEC/IEEE FDIS 24748-8, organizations can ensure that their defence program technical reviews and audits are consistent, effective, and compliant with international best practices for systems engineering and life cycle management.

FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
24748-8
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — Life cycle
Voting begins on:
management —
2026-03-02
Part 8:
Voting terminates on:
2026-04-27
Technical reviews and audits on
defence programs
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number © ISO/IEC 2026
ISO/IEC/IEEE FDIS 24748­8:2026(en) © IEEE 2026

FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
24748-8
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — Life cycle
Voting begins on:
management —
Part 8:
Voting terminates on:
Technical reviews and audits on
defence programs
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
© ISO/IEC 2026
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© IEEE 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
respective address below or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
ISO copyright office Institute of Electrical and Electronics Engineers, Inc MADE IN NATIONAL REGULATIONS.
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: [phone]
Email: [e-mail] Email: [e-mail]
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
Reference number
ISO/IEC/IEEE FDIS 24748­8:2026(en) © IEEE 2026

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
ii
Contents Page
Foreword .vi
Introduction .viii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .4
4 Conformance . 4
5 Concepts . 5
5.1 Project assessment and control .5
5.2 Configuration management .5
5.3 Validation .5
5.4 Information and digital engineering .6
5.5 Agile development .6
6 Timing and frequency . 7
6.1 Alignment to system life cycle model . .7
6.2 Risk-based decision points .7
6.3 Entry criteria .7
6.4 Exit criteria .7
6.5 Application to system elements .8
6.6 Iteration and concurrency considerations .8
6.7 Removing, combining or adding reviews or audits .8
7 Technical review and audit processes . 8
7.1 Prepare process .8
7.1.1 Purpose .8
7.1.2 Outcomes .8
7.1.3 Activities and tasks .8
7.2 Conduct process .10
7.2.1 Purpose .10
7.2.2 Outcomes .10
7.2.3 Activities and tasks .10
7.3 Complete process .11
7.3.1 Purpose .11
7.3.2 Outcomes .11
7.3.3 Activities and tasks .11
8 Application to major capability acquisition pathway .12
8.1 Overview . 12
8.1.1 Purpose . 12
8.1.2 Life cycle . 13
8.2 Alternative systems review (ASR) .14
8.2.1 ASR purpose .14
8.2.2 ASR outcomes .14
8.2.3 ASR timing .14
8.2.4 ASR activities and tasks . 15
8.2.5 ASR review topics . 15
8.3 System requirements review (SRR) .16
8.3.1 SRR purpose .16
8.3.2 SRR outcomes .16
8.3.3 SRR timing .17
8.3.4 SRR activities and tasks .17
8.3.5 SRR review topics .17
8.4 System functional review (SFR) .21

© IEEE 2026 – All rights reserved
iii
8.4.1 SFR purpose .21
8.4.2 SFR outcomes .21
8.4.3 SFR timing .21
8.4.4 SFR activities and tasks .21
8.4.5 SFR review topics . 22
8.5 Preliminary design review (PDR) . 22
8.5.1 PDR purpose . 22
8.5.2 PDR outcomes . 23
8.5.3 PDR timing . 23
8.5.4 PDR activities and tasks . 23
8.5.5 PDR review topics . 23
8.6 Critical design review (CDR) . 29
8.6.1 CDR purpose . 29
8.6.2 CDR outcomes . 29
8.6.3 CDR timing . 30
8.6.4 CDR activities and tasks . 30
8.6.5 CDR review topics . 30
8.7 Test readiness review (TRR). 35
8.7.1 TRR purpose . 35
8.7.2 TRR outcomes . 36
8.7.3 TRR timing . 36
8.7.4 TRR activities and tasks . 36
8.7.5 TRR review topics . 36
8.8 Functional configuration audit (FCA) . 39
8.8.1 FCA purpose . 39
8.8.2 FCA outcomes . 39
8.8.3 FCA timing . 39
8.8.4 FCA activities and tasks . 39
8.8.5 FCA audit topics . . 39
8.9 System verification review (SVR) . 40
8.9.1 SVR purpose . 40
8.9.2 SVR outcomes . 40
8.9.3 SVR timing .41
8.9.4 SVR activities and tasks .41
8.9.5 SVR review topics .41
8.10 Production readiness review (PRR) .42
8.10.1 PRR purpose .42
8.10.2 PRR outcomes .42
8.10.3 PRR timing .42
8.10.4 PRR activities and tasks .43
8.10.5 PRR review topics.43
8.11 Physical configuration audit (PCA) .45
8.11.1 PCA purpose .45
8.11.2 PCA outcomes.45
8.11.3 PCA timing .45
8.11.4 PCA activities and tasks . . .45
8.11.5 PCA audit topics .45
9 Application to agile software acquisition pathway . 47
9.1 Overview .47
9.1.1 Purpose .47
9.1.2 Life cycle . 48
9.2 Project initiation review (PIR) . 49
9.2.1 PIR purpose . 49
9.2.2 PIR outcomes . 49
9.2.3 PIR timing . 49
9.2.4 PIR activities and tasks . 49
9.2.5 PIR review topics . 50
9.3 Iterative planning review (IPR) . 50

© IEEE 2026 – All rights reserved
iv
9.3.1 IPR purpose . 50
9.3.2 IPR outcomes .51
9.3.3 IPR timing .51
9.3.4 IPR activities and tasks .51
9.3.5 IPR review topics .51
9.4 Iterative capability review (ICR) . 54
9.4.1 ICR purpose . 54
9.4.2 ICR outcomes . 54
9.4.3 ICR timing . 55
9.4.4 ICR activities and tasks . 55
9.4.5 ICR review topics . 55
9.5 Incremental viability review (IVR) .59
9.5.1 IVR purpose .59
9.5.2 IVR outcomes .59
9.5.3 IVR timing .59
9.5.4 IVR activities and tasks .59
9.5.5 IVR review topics .59
9.6 Incremental release review (IRR) .61
9.6.1 IRR purpose and description.61
9.6.2 IRR outcomes .61
9.6.3 IRR timing .62
9.6.4 IRR activities and tasks .62
9.6.5 IRR review topics .62
9.7 Incremental configuration audit (ICA) . 64
9.7.1 ICA purpose. 64
9.7.2 ICA outcomes . 64
9.7.3 ICA timing . 64
9.7.4 ICA activities and tasks . 65
9.7.5 ICA audit topics . 65
Annex A (informative) Review and audit topics .69
Annex B (informative) Conformance background and options .70
Annex C (informative) Planning considerations .72
Bibliography .80
IEEE notices and abstract .81

© IEEE 2026 – All rights reserved
v
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialised system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
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/IEC documents 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 or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of
IEEE or IEEE SA and participate without compensation from IEEE. While IEEE administers the process and
establishes rules to promote fairness in the consensus development process, IEEE does not independently
evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained
in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take 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 and IEC 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 and https://patents.iec.ch. ISO and IEC 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.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/JTC 1, Information technology, Subcommittee
SC 7, Software and systems engineering, in cooperation with the Systems and Software Engineering
Standards Committee of the IEEE Computer Society, under the Partner Standards Development Organization
cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 24748-8:2019), which has been
technically revised.
The main changes are as follows:
— aligned document structure, terminology, etc. with related ISO standards (e.g. ISO/IEC/IEEE 15288:2023);
— reorganized and consolidated text for more consistent wording and to support different acquisition life
cycles and organizations;
— added information to support software using highly iterative and incremental (agile) life cycles;
— defined common processes for technical reviews and audits on defence projects;
— defined review and audit topics associated with technical reviews and audits, replacing acceptability
criteria;
© IEEE 2026 – All rights reserved
vi
— added context to support readers without significant defence industry experience;
— updated to reflect current best practices (e.g. digital engineering);
— removed selected guidance material (e.g. annexes describing optional reviews);
— updated definitions, acronyms and bibliography to be consistent with revised text.
A list of all parts in the ISO/IEC/IEEE 24748 series can be found on the ISO and IEC websites.
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 and
www.iec.ch/national-committees.

© IEEE 2026 – All rights reserved
vii
Introduction
This document responds to the needs of defence projects to have more specific and detailed requirements for
technical reviews and audits as part of the assessment of projects during their life cycle. The requirements
and guidance in this document have been written at the most general level possible so that they can meet the
needs of defence agencies in different countries, either by direct application or by tailoring for an agency’s
specific needs.
Defence projects can be different from typical commercial projects in several ways:
— Defence systems can have hazards to human safety, the environment and national security that make
their ownership and use prohibited outside of a defence organization. This can constrain the ability of
projects to develop and deploy solutions for test and operational use;
— Acquisition teams can require comprehensive, cohesive technical data for systems and system elements,
particularly plans, requirements and architectural descriptions (e.g. for certification activities or organic
support);
— Acquisition teams using public funds often need extensive visibility into the definition and execution of
supplier processes to support their fiduciary responsibilities.
These differences can result in the need to support more stakeholders in the review and audit process
(6.6) and the need to review and audit more information items than found in typical commercial projects.
However, non-defence projects are encouraged to apply it if useful.
This document can be used in one or more of the following modes:
— by an acquirer and a supplier, to help develop an agreement on the contribution of each party to the
technical reviews and audit approach;
— by a project, to help establish and execute a technical review and audit approach for that project;
— by an organization, to help establish a desired approach to technical reviews and audits that can be
applied across multiple projects;
— by process assessors, to serve as a reference for use in the performance of process assessments that
support organizational process improvement.
NOTE Several tables in this document include a unique identifier (ID) for each table entry. This identifier can be
used as desired to support compact references to the table entry in tailoring descriptions, checklists, etc.

© IEEE 2026 – All rights reserved
viii
FINAL DRAFT International Standard ISO/IEC/IEEE FDIS 24748-8:2026(en)
Systems and software engineering — Life cycle
management —
Part 8:
Technical reviews and audits on defence programs
1 Scope
This document establishes the requirements for technical reviews and audits to be performed throughout
the acquisition life cycle of defence projects. This document provides the purpose, timing, activities and tasks
for each technical review and audit. It can be used to establish agreement between acquirers and suppliers
on the technical reviews and audits that are needed for the project, as well as the focus and expectations of
each technical review and audit.
This document is applicable to:
— those who implement or plan to implement technical reviews and audits in the acquisition of defence-
related systems (and parts thereof) or services;
— those who are responsible for the technical management of projects concerned with the engineering of
systems;
— those responsible for executing ISO/IEC/IEEE 15288 system life cycle processes for defence projects.
While primarily supporting the acquirer-supplier agreement mode, this document also can be used to
support the other modes such as use by organizations, projects and process assessors.
NOTE In this document, the terms "project" and "program" are used interchangeably.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC and IEEE 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/
— IEEE Standards Dictionary Online: available at https:// ieeexplore .ieee .org/ xpls/ dictionary .jsp
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software
Engineering Vocabulary) database and which is publicly accessible at https:// www .computer .org/ sevocab.

© IEEE 2026 – All rights reserved
3.1.1
agile
development approach based on iterative development, frequent inspection and adaptation, and incremental
deliveries in which requirements and solutions evolve through collaboration in cross-functional teams and
through continual stakeholder feedback
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.4]
3.1.2
evaluation
systematic determination of the extent to which an entity meets its specified criteria
[SOURCE: ISO/IEC 25001:2014, 4.1]
3.1.3
increment
tested, deliverable version of a product that provides new or modified capabilities
[SOURCE: ISO/IEC 33202:2024, 3.17, modified — “software” has been removed.]
3.1.4
information
knowledge that is exchangeable amongst users (3.1.13), about things, facts, concepts, and so on, in a universe
of discourse
[SOURCE: ISO/IEC 10746-2:2009, 3.2.6]
3.1.5
information item
information product
separately identifiable body of information (3.1.4) that is produced, stored, and delivered for human use
Note 1 to entry: A document produced to meet information requirements can be an information item, part of an
information item, or a combination of several information items.
Note 2 to entry: An information item can be produced in several versions during a project or system (3.1.11) life cycle.
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.12]
3.1.6
information item content
information (3.1.4) included in an information item (3.1.5), associated with a system (3.1.11), product or
service, to satisfy a requirement or need
[SOURCE: ISO/IEC/IEEE 15289:20197, 3.1.13]
3.1.7
iteration
repeating the application of the same process or set of processes on the same level of the system
(3.1.11) structure
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.28]
3.1.8
recursion
repeating the application of the same process or set of processes to successive levels of system
(3.1.11) elements in the system structure
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.31]
Note 1 to entry: No specific order of application is implied by this definition. For software and hardware system
elements, a process may be applied at recursively lower levels for system definition and recursively higher levels for
system realization.
© IEEE 2026 – All rights reserved
Note 2 to entry: This definition does not imply any specific hierarchical, vertical, or horizontal structure for the system
of interest, enabling system, organization, or project.
3.1.9
software configuration item
computer software configuration item
aggregation of software that is designed for configuration management and treated as a single entity in the
configuration management process
Note 1 to entry: The state of technology progression has resulted in the functionality of software code being realized
by its execution while embedded in devices that are not properly described as computers (e.g. digital signal processors,
field programmable gate assemblies). This document uses software configuration item to encompass the broader
execution environment of software code.
[SOURCE: ISO/IEC/IEEE 24765:2017, modified — The admitted term "software configuration item" has been
changed to the preferred term; the abbreviated terms have been rem
...

ISO/IEC JTC 1/SC 7/WG 7 N10027
Date: 2025-12-18
Secretariat: BIS
Second edition
Systems and software engineering — Life cycle management — —
Part 8:
Technical reviews and audits on defence programs
Ingénierie des systèmes — Gestion du cycle de vie — Partie 8: Revues techniques et audits des programmes
de défense
FDIS stage
© ISO/IEC/IEEE 20252026
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
or IEEE at the respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronic Engineers, Inc.
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: + 41 22 749 01 11
EmailE-mail: [e-mail] Email: [e-mail]
Website: www.iso.org Website:
Published in Switzerland
© ISO/IEC 2025, © IEEE 20252026 – All rights reserved
iii
ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
Contents
Foreword . vi
Introduction . viii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 4
4 Conformance . 5
5 Concepts . 5
5.1 Project assessment and control . 5
5.2 Configuration management . 5
5.3 Validation . 6
5.4 Information and digital engineering . 6
5.5 Agile development . 6
6 Timing and frequency . 7
6.1 Alignment to system life cycle model . 7
6.2 Risk-based decision points . 8
6.3 Entry criteria . 8
6.4 Exit criteria . 8
6.5 Application to system elements . 8
6.6 Iteration and concurrency considerations . 8
6.7 Removing, combining or adding reviews or audits . 8
7 Technical review and audit processes . 9
7.1 Prepare process . 9
7.2 Conduct process . 10
7.3 Complete process . 12
8 Application to major capability acquisition pathway . 13
8.1 Overview . 13
8.2 Alternative systems review (ASR) . 16
8.3 System requirements review (SRR) . 18
8.4 System functional review (SFR) . 23
8.5 Preliminary design review (PDR) . 25
8.6 Critical design review (CDR) . 33
8.7 Test readiness review (TRR) . 40
8.8 Functional configuration audit (FCA) . 44
8.9 System verification review (SVR) . 46
8.10 Production readiness review (PRR). 48
8.11 Physical configuration audit (PCA) . 51
9 Application to agile software acquisition pathway . 53
9.1 Overview . 53
9.2 Project initiation review (PIR) . 56
9.3 Iterative planning review (IPR) . 57
9.4 Iterative capability review (ICR) . 62
9.5 Incremental viability review (IVR) . 67
9.6 Incremental release review (IRR) . 70
9.7 Incremental configuration audit (ICA) . 73
Annex A (informative) Review and audit topics . 79
© ISO/IEC/© IEEE 2025 2026 – All rights reserved
iv
Annex B (informative) Conformance background and options . 80
Annex C (informative) Planning considerations . 83
Bibliography . 93
IEEE notices and abstract . 95

© ISO/IEC 2025, © IEEE 20252026 – All rights reserved
v
ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialised system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
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/IEC documents 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 or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA and participate without compensation from IEEE. While IEEE administers the process and establishes
rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test,
or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
Attention is drawnISO and IEC draw attention to the possibility that some of the elementsimplementation of
this document may beinvolve the subjectuse of (a) patent(s). ISO and IEC take 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 and IEC 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 and https://patents.iec.ch.
ISO. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received (see ) or the IEC list of patent declarations received (see ).
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.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/JTC 1, Information technology, Subcommittee
SC 7, Software and systems engineering, in cooperation with the Systems and Software Engineering Standards
Committee of the IEEE Computer Society, under the Partner Standards Development Organization
cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 24748-8:2019), which has been
technically revised.
The main changes are as follows:
— — aligned document structure, terminology, etc. with related ISO standards (e.g. ISO/IEC/IEEE
15288:2023);
© ISO/IEC/© IEEE 2025 2026 – All rights reserved
vi
— — reorganized and consolidated text for more consistent wording and to support different acquisition
life cycles and organizations;
— — added information to support software using highly iterative and incremental (agile) life cycles;
— — defined common processes for technical reviews and audits on defence projects;
— — defined review and audit topics associated with technical reviews and audits, replacing acceptability
criteria;
— — added context to support readers without significant defence industry experience;
— — updated to reflect current best practices (e.g. digital engineering);
— — removed selected guidance material (e.g. annexes describing optional reviews);
— — updated definitions, acronyms and bibliography to be consistent with revised text.
A list of all parts in the ISO/IEC/IEEE 24748 series can be found on the ISO and IEC websites.
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 and www.iec.ch/national-
committees.
© ISO/IEC 2025, © IEEE 20252026 – All rights reserved
vii
ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
Introduction
This document responds to the needs of defence projects to have more specific and detailed requirements for
technical reviews and audits as part of the assessment of projects during their life cycle. The requirements
and guidance in this document have been written at the most general level possible so that they can meet the
needs of defence agencies in different countries, either by direct application or by tailoring for an agency’s
specific needs.
Defence projects can be different from typical commercial projects in several ways:
— — Defence systems can have hazards to human safety, the environment and national security that make
their ownership and use prohibited outside of a defence organization. This can constrain the ability of
projects to develop and deploy solutions for test and operational use;
— — Acquisition teams can require comprehensive, cohesive technical data for systems and system
elements, particularly plans, requirements and architectural descriptions (e.g. for certification activities
or organic support);
— — Acquisition teams using public funds often need extensive visibility into the definition and execution
of supplier processes to support their fiduciary responsibilities.
These differences can result in the need to support more stakeholders in the review and audit process
(6.6(6.6)) and the need to review and audit more information items than found in typical commercial projects.
However, non-defence projects are encouraged to apply it if useful.
This document can be used in one or more of the following modes:
— — by an acquirer and a supplier, to help develop an agreement on the contribution of each party to the
technical reviews and audit approach;
— — by a project, to help establish and execute a technical review and audit approach for that project;
— — by an organization, to help establish a desired approach to technical reviews and audits that can be
applied across multiple projects;
— — by process assessors, to serve as a reference for use in the performance of process assessments that
support organizational process improvement.
NOTE Several tables in this document include a unique identifier (ID) for each table entry. This identifier can be used
as desired to support compact references to the table entry in tailoring descriptions, checklists, etc.
© ISO/IEC/© IEEE 2025 2026 – All rights reserved
viii
FINAL DRAFT International Standard ISO/IEC/IEEE FDIS 24748-8:2025(en)

Systems and software engineering — Life cycle management — —
Part 8:
Technical reviews and audits on defence programs
1 Scope
This document establishes the requirements for technical reviews and audits to be performed throughout the
acquisition life cycle of defence projects. This document provides the purpose, timing, activities and tasks for
each technical review and audit. It can be used to establish agreement between acquirers and suppliers on the
technical reviews and audits that are needed for the project, as well as the focus and expectations of each
technical review and audit.
This document is applicable to:
— — those who implement or plan to implement technical reviews and audits in the acquisition of defence-
related systems (and parts thereof) or services;
— — those who are responsible for the technical management of projects concerned with the engineering
of systems;
— — those responsible for executing ISO/IEC/IEEE 15288 system life cycle processes for defence projects.
While primarily supporting the acquirer-supplier agreement mode, this document also can be used to support
the other modes such as use by organizations, projects and process assessors.
NOTE In this document, the terms "project" and "program" are used interchangeably.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC and IEEE 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/
— — IEEE Standards Dictionary Online: available at https://ieeexplore.ieee.org/xpls/dictionary.jsp
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software Engineering
Vocabulary) database and which is publicly accessible at https://www.computer.org/sevocab.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved

ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
3.1.1 3.1.1
agile
development approach based on iterative development, frequent inspection and adaptation, and incremental
deliveries in which requirements and solutions evolve through collaboration in cross-functional teams and
through continual stakeholder feedback
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.4]
3.1.2 3.1.2
evaluation
systematic determination of the extent to which an entity meets its specified criteria
[SOURCE: ISO/IEC 25001:2014, 4.1]
3.1.3 3.1.3
increment
tested, deliverable version of a product that provides new or modified capabilities
[SOURCE: ISO/IEC 33202:2024, 3.17, modified — “software” has been removed.]
3.1.4 3.1.4
information
knowledge that is exchangeable amongst users ((3.1.13), about things, facts, concepts, and so on, in a universe
of discourse
[SOURCE: ISO/IEC 10746-2:2009, 3.2.6]
3.1.5 3.1.5
information item
information product
separately identifiable body of information ((3.1.4) that is produced, stored, and delivered for human use
Note 1 to entry: A document produced to meet information requirements can be an information item, part of an
information item, or a combination of several information items.
Note 2 to entry: An information item can be produced in several versions during a project or system ((3.1.11) life cycle.
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.12]
3.1.6 3.1.6
information item content
information ((3.1.4) included in an information item ((3.1.5), associated with a system ((3.1.11), product or
service, to satisfy a requirement or need
[SOURCE: ISO/IEC/IEEE 15289:20197, 3.1.133.1.13]
3.1.7 3.1.7
iteration
repeating the application of the same process or set of processes on the same level of the system
((3.1.11) structure
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.28]
© ISO/IEC/© IEEE 2025 2026 – All rights reserved
3.1.8 3.1.8
recursion
repeating the application of the same process or set of processes to successive levels of system
((3.1.11) elements in the system structure
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.31]
Note 1 to entry: No specific order of application is implied by this definition. For software and hardware system elements,
a process may be applied at recursively lower levels for system definition and recursively higher levels for system
realization.
Note 2 to entry: This definition does not imply any specific hierarchical, vertical, or horizontal structure for the system
of interest, enabling system, organization, or project.
3.1.9 3.1.9
software configuration item
computer software configuration item
aggregation of software that is designed for configuration management and treated as a single entity in the
configuration management process
Note 1 to entry: The state of technology progression has resulted in the functionality of software code being realized by
its execution while embedded in devices that are not properly described as computers (e.g. digital signal processors, field
programmable gate assemblies). This document uses software configuration item to encompass the broader execution
environment of software code.
[SOURCE: ISO/IEC/IEEE 24765:2017, modified — The admitted term "software configuration item" has been
changed to the preferred term; the abbreviated terms have been removed; note 1 to entry has been added.]
3.1.10 3.1.10
specification
information item ((3.1.5) that identifies, in a complete, precise, and verifiable manner, the requirements,
design, behaviour, or other expected characteristics of a system ((3.1.11), service, or process
Note 1 to entry: The more generic term is used for consistent terminology within this document and includes terms such
as system performance specification, system requirements document, system or subsystem specification, or agile ((3.1.1)
backlog.
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.26, modified — Note 1 to entry has been added.]
3.1.11 3.1.11
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g.
aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym (e.g. aircraft),
though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services, and personnel required for operations and support to the degree necessary
for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]
© ISO/IEC 2025, © IEEE 20252026 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
3.1.12 3.1.12
technical review
systems engineering technical review
a systems engineering activity conducted at a logical transition point in a system life cycle, by which the
progress of a project is assessed relative to its technical requirements using a mutually agreed-upon set of
criteria
Note 1 to entry: Includes both incremental and system perspectives, as applicable, and considers technical maturity
amidst programmatic constraints (cost/schedule), to ascertain readiness to proceed to subsequent activities with
acceptable risk.
Note 2 to entry: Unless otherwise stated, the use of the term “review” in this document is intended to refer specifically to
a technical review.
3.1.13 3.1.13
user
individual or group that interacts with a system ((3.1.11) or benefits from a system during its utilization
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.53]
3.2 Abbreviated terms
ASR alternative systems review
CDR critical design review
ICA incremental configuration audit
ICR iterative capability review
ID identifier
IPR iterative planning review
IRR incremental release review
IVR incremental viability review
FCA functional configuration audit
MVCR minimum viable capability release
MVP minimum viable product
PCA physical configuration audit
PIR project initiation review
PDR preliminary design review
PRR production readiness review
RASIC responsible, accountable, supports, informed, consulted (model)
SBOM software bill of materials
SFR system functional review
SME subject matter expert
SRR system requirements review
SVR system verification review
TRR test readiness review
© ISO/IEC/© IEEE 2025 2026 – All rights reserved
4 Conformance
Users of this document can make claims of conformance (conformance statements) to some or all
requirements in this document. Users can structure the form of such claims to meet their needs, therefore this
document does not prescribe the form of these claims.
Also, per ISO/IEC 17007, this document does not address specific methods or procedures for individual
conformity assessment activities, nor does it address general rules or methodology for conformity assessment.
For more information about conformance, see Annex BAnnex B.
5 Concepts
5.1 Project assessment and control
Reviews and audits support the “assess the project” activity of the ISO/IEC/IEEE 15288 project assessment
and control process. The overall purpose of this process is to:
— — assess if plans are aligned and feasible;
— — determine the status of the project, technical and process performance;
— — direct execution to confirm that the performance is according to plans and schedules, within projected
budgets, to satisfy project objectives.
This process evaluates, periodically and at major events, the progress and achievements against requirements,
plans, and overall strategic objectives. Information is provided for management action when significant
variances are detected.
Although both reviews and audits support project assessment and control, technical reviews tend to include
more focus on proactive areas such as risk identification, whereas configuration audits focus more on
confirming the proper operation and outcomes of the configuration management system (5.2(5.2).). Together,
they provide key points throughout the project to evaluate significant achievements and to assess technical
maturity and risk. Project assessment is performed at major project decision points by means of these reviews
and audits, and the results inform a project’s management to enable any required project control actions.
These actions can include redirecting project activities and tasks as appropriate to correct identified
deficiencies.
5.2 Configuration management
Reviews and audits also support the “perform configuration identification” and “configuration verification and
audit” activities of the ISO/IEC/IEEE 15288 configuration management process. The overall purpose of the
configuration management process is to manage system and system element configurations over their life
cycle. Managing includes establishing and maintaining consistency, integrity, traceability, and control.
Configurations include information items and their product configuration information (e.g. version number).
Reviews and audits typically assess sets of related information items (e.g. requirements, architecture, design)
for desired attributes such as consistency, integrity, and traceability. Thus, reviews and audits can be used
where appropriate to support the incorporation of quality information items into a project configuration
baseline (e.g. functional baseline, allocated baseline, or product baseline) and to provide confidence that the
baseline is sufficiently mature to be used in future activities. See ISO/IEC/IEEE 24748-7, IEEE 828 and SAE
EIA-649-1A for more information on configuration management for defence projects, including configuration
baselines and configuration audits.
© ISO/IEC 2025, © IEEE 20252026 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
5.3 Validation
Reviews and audits also support the ISO/IEC/IEEE 15288 validation process. The overall purpose of this
process is to provide objective evidence that the system, when in use, fulfils its business or mission objectives
and stakeholder needs and requirements, achieving its intended use in its intended operational environment.
Although validation can be done for the system of interest (or a system element) after it has been implemented
or integrated and verified, validation can also be performed for individual information items produced in the
definition and realization of the system and its elements. The validation process can help confirm:
— — the “right” information items have been produced according to the needs and requirements of the
stakeholders;
— — whether or not these information items will result in the “right” system once realized.
Reviews and audits provide opportunities for stakeholders to provide early and frequent feedback on the
evolution of the system and its associated information items with respect to the stakeholders’ needs and
requirements. These stakeholder discussions (in-process validation) can help determine that the proposed
baselines are acceptable to the organization, customer, user, and other stakeholders.
Proposed changes to enhance system performance or to reduce risk or cost are welcome for consideration,
but after baselining these will go through formal change control, since others can be building on previously
defined and released information items.
5.4 Information and digital engineering
Much of the value of a review or audit comes from the effective evaluation of project information and
consideration of the results. Project information can be provided in a static format (a document or database),
as an interactive model or simulation, as a demonstration, or any other means best suited to the expected
outcomes of the review or audit. In some cases, the evaluation can be used to determine formal acceptance of
an information item. However, an excessive focus on information item acceptance can get in the way of
supporting the project assessment and control (5.1(5.1),), configuration management (5.2(5.2)) and
validation (5.3(5.3)) needs of the project. This document uses the term “review or audit topic” to establish the
necessary information and associated attributes needed to support the review or audit outcomes. As much as
possible, this document specifies the necessary information item content and its attributes, not how the
information is made available, to support its use across different organizations and life cycles. However, some
suggestions for information items to use with the review and audit topics are included in Annex AAnnex A.
An incomplete information item (“draft,” “preliminary,” etc.) can be used for some reviews or audits, so long
as the completeness and other technical qualities support the expected outcomes of the review or audit.
Generally, review and audit topics do not distinguish between incomplete and complete information items.
Modern engineering practices incorporate digital engineering concepts, enabling the use of integrated models
and simulations throughout the project lifecycle to digitally represent the system and associated information
item content. The extent to which a project adopts a digital engineering approach will not impact “what”
reviews and audits need to be conducted, but it can have a profound and revolutionary impact upon “how”
they are conducted. A well-defined digital ecosystem, with an associated authoritative source of truth and
static and interactive models of systems and their environment, will enable timely and iterative analyses. In
addition, by leveraging constructive, virtual, and live simulation tools, the ecosystem can enable exploration
of options not easily analysed elsewise.
5.5 Agile development
To create frequent opportunities for effective project assessment and control, validation, and value delivery,
some projects adopt the principles and practices described in ISO/IEC 33202 and ISO/IEC/IEEE 24748-10,
© ISO/IEC/© IEEE 2025 2026 – All rights reserved
particularly for software systems or system elements. Typical agile implementation aspects relevant to this
standard include:
— — Stakeholder needs, system requirements, design, etc. can evolve rapidly over the course of the project,
with different functional capabilities at different levels of maturity at any point. A "definition of ready"
may be defined to support decision gates (6.1(6.1),), such as determining that sufficient information exists
to start implementation. However, these decisions can happen so frequently as to overwhelm the ability
of key stakeholders to participate in them (6.6(6.6););
— — To support this highly iterative and incremental approach, stakeholder needs and associated
requirements may be defined in units of work called agile backlog items, sometimes supplemented by
global requirements captured in a "definition of done". These backlog items may be decomposed into
smaller related units of work and ultimately allocated to specific schedule periods, responsible teams,
system element implementation versions, and associated test or other verification data as needed. Where
a complete set of requirements, etc., is needed for a system or system element (introduction), extracting
such information directly from agile backlog information can be difficult, in part because the sequence in
which backlog items are implemented will usually affect the result. This can lead to the creation of
alternate representations (including traditional requirements specifications, interface control documents,
and other such documents) for systems and system elements;
— — Rather than relying on large-scale reviews of comprehensive configuration baselines of increasing
fidelity over the course of the project, agile projects may use lightweight reviews of backlog item definition
and completion, coupled with validation of deliverable products in an operationally representative
environment, creating a single technical baseline that evolves incrementally as the backlog evolves. This
approach is particularly effective for software, where modern languages and tools can narrow the
distinction between requirements, design, implementation and test, and where the cost to correct defects
is lower than many physical systems.
9Clause 9 addresses technical reviews and audits for agile projects.
6 Timing and frequency
6.1 Alignment to system life cycle model
Per ISO/IEC/IEEE 15288, every system has a life cycle model that comprises one or more stages, as needed.
The stages can be iterative, concurrent, or overlapping, as appropriate for the system’s scope, magnitude,
complexity, changing needs, and opportunities. Typical system life cycle stages include concept, development,
production, utilization, support, and retirement. These stages describe the major progress and achievement
milestones of the system through its life cycle.
Stages give rise to decision gates. These decision gates apply specific decision criteria and are used by
organizations to understand and manage the inherent uncertainties and risks associated with business case,
costs, schedule, performance, or functionality of a system. The stages thus provide a framework within which
a project has high-level visibility and control of technical management and technical processes.
Reviews and audits are assessment tools that provide decision-makers with sufficient information on the
project’s technical readiness to proceed to the next stage or to the next decision point within a stage. As a
result, reviews and audits are often aligned to the beginning or end of each stage, as well as to key decision
points within a stage, as appropriate.
See ISO/IEC/IEEE 24748-1 for details on different system life cycle models and how to select a life cycle model
for a specific project. ISO/IEC/IEEE 24748-2 provides additional information on decision gates.
© ISO/IEC 2025, © IEEE 20252026 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
6.2 Risk-based decision points
In addition to life cycle stage boundaries, a review or audit can be held prior to a project task that poses
significant technical or programmatic risks. For example, a test readiness review can be held prior to a
particular test that has significant safety or security risks.
6.3 Entry criteria
A review or audit should not be conducted (7.2(7.2)) unless and until the system under development meets
the associated entry criteria. Entry criteria should support the purpose of the review or audit, including the
required level of development maturity. The entry criteria are applied across all requirements and technical
disciplines. Example entry criteria include:
— — completion of required activities and tasks to prepare for the review or audit (7.1(7.1););
— — availability of specific information items necessary to support the review or audit topics (5.4(5.4).).
Entry criteria should be documented in appropriate project plans prior to the start of the review or audit.
6.4 Exit criteria
The conduct of a review or audit (7.2(7.2)) should be considered complete only after the associated exit
criteria have been met. Example exit criteria include:
— — confirmation that the expected review or audit outcomes have been achieved;
— — action items have been properly dispositioned.
Exit criteria should be documented in appropriate project plans prior to the start of the review or audit.
6.5 Application to system elements
For complex systems, the project can choose to use recursion to perform certain reviews or audits for one or
more system elements depending on the interdependencies involved. These recursive system-element-level
reviews or audits support an overall system-level review or audit. This document takes a minimalistic
approach to defining the content of each review and audit such that the content is intended to be sufficient to
support each instance of that review or audit performed by a given project.
6.6 Iteration and concurrency considerations
For those projects that repeat all or part of the life cycle stages (e.g. to support incremental deliveries), some
or all reviews and audits may be performed as part of each iteration. However, particularly for projects that
iterate frequently, this can strain the availability of the review or audit team and related resources. In this
case, a project can combine certain reviews or audits or hold certain reviews or audits after a given number
of iterations. For these cases, the project should consider the trade-offs between the potential risks of not
holding all reviews and audits every iteration and the adverse impacts to project resources.
6.7 Removing, combining or adding reviews or audits
Projects should only conduct reviews or audits that are necessary given the structure of the project’s
acquisition life cycle, e.g. where in the acquisition cycle the project will enter, or one-of-a-kind projects without
a production requirement.
Projects can also add other reviews or audits, based on project characteristics such as complexity, risk posture,
nature, or specific domain. Some examples include operational readiness review, system readiness review,
© ISO/IEC/© IEEE 2025 2026 – All rights reserved
and transition readiness review. The specific approach to adding such reviews is beyond the scope of this
document.
7 Technical review and audit processes
7.1 Prepare process
7.1.1 Purpose
The purpose of the prepare process is to support the efficient and effective conduct and completion of the
review or audit.
NOTE Annex CAnnex C provides additional information on review planning, including guidance on defining roles,
responsibilities, and other key attributes for participants in the review or audit.
7.1.2 Outcomes
As a result of the successful execution of the prepare process, these outcomes shall be achieved:
a) a) participants in the review or audit (C.4(C.4)) are identified and prepared to contribute to a
successful review;
b) b) necessary materials, including review or audit topics and related information items (5.4(5.4),),
are available to conduct the review;
c) c) potential impediments affecting the ability to achieve the purpose of the review or audit are
identified and addressed;
d) d) entry criteria (6.3(6.3)) are accepted as complete.
7.1.3 Activities and tasks
The activities and tasks defined in 0Table 1 shall be implemented for this process in accordance with
applicable organization policies and procedures.
Table 1 — Activities and tasks: prepare process
ID Description
P11 Review and update planning. This activity consists of tasks P1101 to P1106.
P1101 Confirm that project plans define the review or audit sufficiently to support the expected outcomes of the
review or audit.
P1102 Confirm that project plans define the roles, responsibilities, and other key attributes for expected
participants in the review or audit.
P1103 Confirm that any standards defined by the acquirer organization as required for use in the review or audit
have been applied and tailored for the project.
P1104 Where supplier involvement is permitted, confirm that the acquirer-supplier agreement identifies the
required support.
P1105 Coordinate any unique methods required to apply review or audit topics (e.g. the disassembly, inspection,
and reassembly of a production-representative configuration item to support verification against related
design documentation).
P1106 Coordinate a preliminary agenda with the review or audit team and other key stakeholders prior to
conducting the review or audit.
P12 Establish team. This activity consists of tasks P1201 to P1204.
© ISO/IEC 2025, © IEEE 20252026 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-8:2025(E2026(en)
ID Description
P1201 Identify and coordinate with the specific individuals who will be part of the acquirer governance team for
the review or audit.
P1202 Identify and coordinate with the full team membership and other key stakeholders in advance of
conducting the review or audit, including expectations on review or audit topics and associated
information items or alternate sources of information (e.g. demo
...