Platform
Modules
By sector
By sector
By standard
Blog
News
Events
ADMP-01
Defence project and in-service teams writing or reviewing the dependability section of an acquisition specification
NATO guidance on writing dependability (availability, reliability, maintainability, testability, maintenance, safety, software) requirements into a defence acquisition specification.
ADMP-01, an Allied Dependability Management Publication, is NATO guidance for the person writing or reviewing the dependability section of a defence acquisition specification. It hands over no template: the document says plainly: "It is not intended that this document will provide a template from which all new requirements can simply be selected, nor can it give a step by step guide to cover every eventuality." Instead it works through the concepts a requirement-writer needs first, then the seven characteristics that make up dependability: availability, reliability, maintainability, testability, maintenance, safety and software.
Nations record their recommendation to use ADMP-01 through STANREC 4174, a recommendation rather than a ratified commitment, so no nation is treaty-bound to apply it. The current edition, Edition C, Version 1, was promulgated in June 2025 and superseded Edition B, Version 1. The document defines "item" broadly, "systems, equipment, be it hardware or software based, and services", so it is not written for one product type.
It addresses the customer side of a programme: "It should be used by all members of projects and in service organisations including the various NATO agencies who are responsible for dependability." It does not speak to suppliers directly, but a supplier ends up carrying the obligation it produces: once a requirement is set: "The supplier will need to provide evidence to substantiate that the requirement has been met, or where it cannot be met, evidence in support of the request for a relaxation."
Before any dependability figure is set, ADMP-01 asks for several things to be worked out first. A Life Profile: how long the item must be operational, on standby, or switched off, how often a mission repeats, and what maintenance it will need and where. A Boundary: what counts as part of the item versus an external stimulus, power, data, other equipment, assumed to be present, since a poorly-drawn boundary leads to disputes over whether a failure is attributable to the item, particularly where payment depends on the answer. Environmental limits for temperature, humidity, salinity and dust, for normal operation and for survival. And a definition of failure agreed before reliability is specified at all, because "Setting clear and agreed definitions of failure is an important step that is often overlooked." Early on, failure is defined functionally (a mission essential function list, typically Move, Fight, Communicate, Protect); as the design firms up, it is refined to the responsible hardware or software component.
The document is also explicit about the difference between a requirement, essential, evidenced, or formally relaxed only with agreement from all stakeholders, and a target or goal, which is nice to have and gets traded away first when costs rise. Overspecifying is treated as a real risk, not a safety margin: "Setting requirements for 98% reliability or 99% probability of surviving a 48-hour mission is likely to drive up costs significantly" for a level of assurance that may add little real operational value.
Dependability is rarely provable with one test, and ADMP-01 shows why with real numbers. Run an item for 1,000 hours with 10 relevant failures, and the chi-squared method shows "a Mean Time Between Failures (MTBF) of 94 hours has been achieved to a 50% level of confidence, an MTBF of 80 hours has been achieved to a 70% level of confidence and an MTBF of 65 hours to a 90% level of confidence." A sharper example: 99% reliability at 80% confidence on 50 single-use items needs 161 failure-free tests to prove, over three times the batch being bought, and the document calls the requirement itself "unacceptable", not the test method. The evidence assembled is normally an assurance case, not a folder of test reports: "a vehicle to allow reasoned and auditable claims and arguments to be made about the dependability of the item."
Availability is uptime over total time, but the document splits inherent availability (ideal conditions, the figure most contracts use) from operational availability (real logistic delay included, "more difficult to measure and thus gain a figure that is agreeable to everyone"). A single annual percentage is not enough: a 99% target still permits 87.6 hours of downtime a year, and one 48-hour outage meets that figure very differently to 1.5 hours a week.
Reliability distinguishes Mission Reliability, failures that stop the mission, from Basic Reliability, every failure. Usually specified as a mean (MTBF/MTTF) or a probability of success, and a mean is not a floor: specifying "a 200-hour MTBF to support an operating requirement of 200 hours will result in failure" for a meaningful share of the fleet.
Maintainability separates Active Repair Time (the physical fix) from Time To Repair (which adds the logistic delay of getting parts, tools and a trained person to the job), and normally combines a mean (MTTR/MART) with a percentage point, commonly that 90% or 95% of repairs finish inside a stated time.
Testability covers how well an item reports its own failures through Built-In-Test, via metrics such as test coverage (weighted by failure rate), fault detection rate, fault isolation rate and false alarm rate, illustrated with figures such as "92% of all possible fault conditions shall be identified by the built in test routines. Additionally 100% of the fault conditions that could cause safety and mission critical failures shall be identified."
Maintenance splits into corrective, which a specification has little control over since it happens whenever a fault occurs, and preventive, whose frequency and duration can be bounded directly, for example "Preventive maintenance shall not exceed 2 hours per week."
Safety and dependability can pull against each other: monitoring or recording equipment added for safety can itself reduce reliability, and up-armouring a vehicle to protect its crew "taken the all up mass of the vehicles over the original design intent which has had adverse effects on reliability of the under carriage, suspension, braking systems and power output."
Software fails with little advance warning but recovers faster, often with a reboot. ADMP-01 recommends setting requirements at the item level, hardware and software together, provided failure definitions capture software-induced failures specifically.
ADMP-01 does not assume a management system like ISO 9001 already exists. It does lean on a companion document for the mechanics of defining failure: the functional analysis and failure classification process it needs "are described in a dedicated ADMP (ADMP-03)." Its normative references also point to ADMP-02 for managing dependability once an item is in service, ADMP-04 for what the customer's own dependability expert does with the resulting requirements, AAP-20 and AAP-48 for the surrounding NATO life-cycle framework, and the IEC 60300 dependability-management series, IEC 60706, IEC 61124 and ISO/IEC 25000/25010 for the underlying engineering methods.
What it does not do is decide a figure for you, tell a supplier which requirements apply to their programme, or describe any way to be certified against it. There is no accreditation body, no NATO scheme, and no organisation that can be "ADMP-01 certified": the document is guidance for a specification, and it says so of itself: "The purpose of this document is to provide guidance on developing dependability requirements."
ADMP-01 is guidance for writing a specification, not a management system a company implements or gets audited against, so there is no product mapping to claim here. The work it describes, agreeing a Life Profile and a Boundary, defining failure at functional and component level, sizing a test programme to a stated confidence level, and building an assurance case that ties evidence back to each requirement, happens in engineering and procurement, not in software.
What a project or a supplier working to an ADMP-01-shaped requirement needs is disciplined document control: version-controlled records of the agreed failure definitions and Life Profile, test plans and results kept traceable to the requirement they prove, and training records for the people who write and review them. ComplyTrain supports that kind of work generally, as an auditable quality management system: controlled documents, training records, internal audits and corrective-action tracking that a customer can inspect at a design review or acceptance milestone.
ComplyTrain does not calculate an MTBF confidence interval, build an assurance case's technical argument, or decide what availability or reliability figure belongs in a specification; that work sits with the project's own reliability engineers. Which ADMP documents apply, and at what tier, is set by the contract and the customer's quality clause, not by any vendor. If you are preparing to write or respond to a dependability requirement, the standards explorer shows what sits alongside ADMP-01 in the ADMP family, and our team is glad to talk through how you would evidence it.
Tell us how you need to work with ADMP-01 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
Nations record their recommendation to use ADMP-01 through STANREC 4174, which is an invitation, not a ratified commitment, so no nation is treaty-bound to apply it. Whether it binds a particular supplier depends on whether a specific tender or contract carries dependability requirements shaped by it, not on the document existing.
No. ADMP-01 describes no accreditation scheme, no certifying body and no NATO-run assessment. It is guidance for writing a specification; the resulting requirements are checked through testing, verification and validation evidence assembled for the contract, reviewed by the procuring organisation itself.
ADMP-01 is guidance for setting dependability requirements before or during design. ADMP-02 picks up once the item is fielded, covering how dependability is managed in service. ADMP-01 points readers to ADMP-02 rather than duplicating its content.
Yes. The document defines an item as including "systems, equipment, be it hardware or software based, and services," and it gives software its own section, recommending that dependability requirements normally be set at the item level covering hardware and software together.
Edition C, Version 1, promulgated in June 2025. It superseded Edition B, Version 1, which nations were instructed to destroy under their own document-destruction procedures.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.