ACMP-2009 guidance on configuration management

What it is

A guidance document, not a contract clause

ACMP-2009, an Allied Configuration Management Publication, is NATO's guidance on how to plan and run Configuration Management (CM) for a defence capability across its entire life, from the Pre-Concept stage through Retirement. It sits in the ACMP series alongside ACMP-2000 (the policy that makes CM mandatory) and ACMP-2100 (the core set of CM requirements that actually goes into contracts). ACMP-2009 fills the space between the two: it is the how-to for the Acquirer, the government or NATO body that owns a programme, on building a Life Cycle Configuration Management Plan (LCCMP) and on deciding what extra CM requirements to write into a contract on top of ACMP-2100's fixed core.

That distinction matters because ACMP-2009 explicitly cannot be referenced in a contract. It has no direct legal force on a Supplier. What binds a Supplier is whatever CM requirements an Acquirer chose, using this guidance, when the tender or contract was written, plus the mandatory core in ACMP-2100. Force runs from STANAG 4427, the agreement by which NATO nations commit to applying the ACMPs, through national implementation (an Annex to this document asks each nation to map its own roles and life-cycle stages onto the ones described here), and then through a specific contract.

The whole approach is built on ISO 10007 as its underlying civil framework, with NATO's own roles, authorities and seven life-cycle stages, drawn from AAP-20 and AAP-48, laid on top.

Roles it defines precisely

The document is exact about who does what, because the same title means different things in different organisations. It fixes, among others: the Configuration Manager (runs CM day to day), the Configuration Authority (decides on proposed changes, not necessarily the same person as the Configuration Manager), the Chief Engineer (owns engineering and operating standards, kept independent of budget and schedule pressure), the Steering Committee (approves deliverables and architecture changes), and the Acquirer itself, which ACMP-2000 defines as the governmental or NATO organisation that defines requirements for a product and enters into a contractual relationship with the Supplier. It also separates eight distinct kinds of authority, operational, transformation, contractual, configuration, production, service provision, maintenance and implementation, that can sit with different people or organisations on the same programme, and often do.

The five CM pillars, through a system's life

The document organises CM into five interacting activities it calls "pillars": Planning, Configuration Identification, Change Control, Configuration Status Accounting and Configuration Audit. What changes stage to stage is not the pillar itself but what it is applied to. In the Pre-Concept stage, Configuration Identification has only the whole capability need to work with; by the Development stage it is identifying detailed subsystems, called Configuration Items (CIs), each with its own Baseline.

Change Control splits proposed changes into two categories: Class I changes affect form, fit or function and force a revision to the Acquirer's own Baseline, while Class II changes are handled internally by the contractor. Two separate streams exist for this: Engineering Change Proposals for permanent design changes, and concessions, sometimes called waivers or deviations, for a documented, time-limited departure from a requirement that does not change the Baseline itself.

Configuration Status Accounting is the recording and reporting side: a system that can retrieve the product breakdown structure, the current definition of every CI, and every Baseline with the ability to roll back to an earlier one. Configuration Audit is the check that a delivered CI actually matches what was specified, in two distinct forms: a Functional Configuration Audit tests whether the CI meets its functional and performance requirements, and a Physical Configuration Audit checks whether it matches its documented physical characteristics as built. The Supplier usually carries out both, but the Acquirer is the one who approves the results.

Building the Life Cycle Configuration Management Plan

ACMP-2009 draws a sharp line between an ordinary Configuration Management Plan (CMP), which is one participant's own static plan for their piece of the work, and the Life Cycle Configuration Management Plan (LCCMP), the Acquirer's single umbrella plan that has to cover every stakeholder across every life-cycle stage. Responsibility for the LCCMP sits with the Acquirer specifically, because only the Acquirer has a view across the whole life cycle; a Supplier's own CMP is always an extension of the LCCMP, never a replacement for it.

The guidance provides an actual template for the plan, organised around Perspective, Context, Governance & Insight and the CM Pillars, a set of numbered Acquirer directives to select from (one example: plan for disposal early, including demilitarisation and environmental constraints), and a mapping of high-level CM activities to outcomes for each of the seven life-cycle stages. Deliberately, there is no single mandatory LCCMP format: the plan is meant to scale with the size, complexity and risk of the programme it covers.

Adding requirements on top of ACMP-2100

ACMP-2100's core set of CM requirements asks a Supplier for exactly one deliverable: access to their own CM plan. Everything else, baselines, drawings, status-accounting data, cooperation with audits, only becomes a contractual obligation if the Acquirer adds it deliberately, as an extra Configuration Management Requirement, using the build-up approach this document describes. What gets added typically differs by stage: documented CM processes and Allocated Baselines at Development, traceable serial or lot numbering and verified Engineering Change Proposal implementation at Production, asset status and retrofit-kit validation at Utilisation and Support, and disposal certification with traceable retirement records at Retirement.

What the guidance does not cover

ACMP-2009 does not itself impose anything on a Supplier; it has no certification attached to it, and it names no specific software, database or tooling for running Configuration Status Accounting. It sets no fixed retention period for CM records and mandates no single LCCMP template. These are all left to the programme, tailored through the directives it provides and the national implementation choices each NATO nation makes for itself.

Standards it references

• ACMP-2000Binds
• ISO 10007Background
• AAP-48Background
• AAP-20Background
• ACMP-2100Background
• STANAG 4728Background
• ALP-10Background
• STANAG 2290Background
• STANAG 4597Background
• APP-20Background