Configuration Management for AQAP 2110: A Practical Guide for Defense Manufacturers (2026)

Configuration management under AQAP 2110 (Configuration Management, CM) is the discipline that keeps the physical and functional makeup of a product under control across the entire lifecycle: from the first sketch to disposing of the last unit of a batch twenty years after delivery. In practice CM answers one simple question that a customer auditor asks most often: "What exactly did you build in this batch, and how does it differ from the previous one?" If your engineering team can't show, within 15 minutes, the precise version of every component, every firmware build and every drawing for a specific serial number, you don't have CM, no matter how nice the paperwork looks.

For a civilian manufacturer that level of transparency is a nice bonus. For a defense supplier it's a matter of safety, contractual obligation and maintainability across a 10-to-30 year horizon. A shell, drone or comms system delivered in 2026 may still be in service into the 2050s. Ten years from now the customer will come back with a field failure, and you must know exactly which batch the board came from, which supplier shipped the chip, what firmware was installed at release and whether other units from the same batch fall under suspicion too.

AQAP 2110 lays down five CM processes that must run in parallel: Configuration Identification, Baseline Management, Change Control, Configuration Status Accounting, and Configuration Audits (FCA and PCA). It's a direct borrowing from NATO ACMP-2100 (NATO Configuration Management Policy) and effectively mirrors the American MIL-STD-973 and ANSI/EIA-649 models. The EIA-649 standard is the main industrial CM reference cited by most NATO defense programmes.

This is where the largest gap between AQAP 2110 and ISO 9001 opens up. ISO 9001:2015 doesn't require configuration management explicitly — only hints in clause 8.5.2 "Identification and traceability". In AQAP 2110, CM is a separate mandatory block tied to clause 8.1.4 and ACMP-2100; without it, no certificate. So a company moving from ISO 9001 to AQAP 2110 has to build CM from scratch or substantially rework existing fragments. The mechanics of that transition are unpacked in the AQAP 2110 vs ISO 9001 comparison, and the overall logic of the NATO standard sits in the AQAP 2110 complete guide.

The first step of CM is deciding what exactly is a separate Configuration Item (CI) in your product. A CI is any part of the product that must be separately identified, versioned and controlled over time. Not everything needs to be a CI: an M6 nut to a generic ISO standard isn't a CI because it's interchangeable in unlimited quantity. But the flight control board of an FPV drone is absolutely a CI, because its version directly affects firmware compatibility, in-flight behaviour and product characteristics.

For a UAV manufacturer the typical decomposition looks like this: at the top sits a CI for the full drone assembly (for example, "FPV-X-2026-Rev3"). Below it the main subsystems: airframe, propulsion, flight controller board, video chain, flight controller firmware, ELRS receiver firmware. Below that the critical components: camera optics, motors, ESCs, tactical-grade battery. A document tree shows how drawings, specifications, BOMs and work instructions tie to each CI at every level.

A numbering scheme is a separate topic that deserves serious attention. A good part number includes product family, revision, configuration variant and modification. A bad part number is just a running counter with no structure — after 200 units you'll be lost. A Bureau Veritas auditor at pre-audit almost always asks: "Show me your part-numbering rules, and decode three random serial numbers from your last batch." If the team can't do that quickly, that's a configuration identification failure before Stage 2 even starts.

Companies that build drones and need AQAP 2110 often underestimate the size of the CI tree. It feels like "we have a simple FPV, there are 50 parts in it". In practice, once formalised, you end up with 80 to 150 CIs once you count firmware, configuration variants and engineering documentation. That's normal. More CIs means more transparency, fewer CIs means more white spots an auditor will hit later.

A baseline is a formally approved snapshot of the product configuration state at a specific date. Before a baseline you're still exploring, experimenting, changing things freely. After a baseline, every change goes through a formal Change Control procedure. In ACMP-2100 terminology there are four baseline types: Functional Baseline (approved functional requirements after SRR — system requirements review), Allocated Baseline (requirements allocated across subsystems after PDR — preliminary design review), Product Baseline (full engineering documentation after CDR — critical design review) and Operational Baseline (the in-service product state, updated with each modification).

Who approves a baseline? The Configuration Control Board (CCB) — a standing cross-functional body inside the company that meets regularly (typically weekly or biweekly) and votes on every baseline event. The minimum CCB composition at a defense manufacturer: chief designer, head of production, head of quality, supply-chain representative and — for serious contracts — a customer representative or their authorised official (GQAR). Without a formal CCB minute, a baseline isn't approved, no matter how confidently an engineer says "well, we all talked about it".

Where do you store baselines technically? Two approaches here. The first is a centralised PLM system (Aras, Teamcenter, Windchill, Odoo PLM): expensive, slow to roll out, but gives industrial-grade version control. The second is a Git-style approach: a document repository with version control, tags for baselines, pull requests as the Change Control mechanism. For an engineering team up to about 30 people the second option is often more practical and cheaper. The auditor doesn't mandate a specific technology — what matters is that versions aren't lost, history is complete, and access rights are controlled.

When do you set the first baseline? Not right after the sketch. Not a week before Stage 2. The right moment is after Critical Design Review, before the first batch of full serial production. Up until then the product is still changing fast, and freezing everything formally is just wasted bureaucracy. After CDR it flips — every change has a cost for the customer, so control becomes vital.

Change Control is the heart of CM, and this is exactly where most Ukrainian defense manufacturers break down on their first certification attempt. Engineers are used to making changes fast, verbally, through a Telegram chat: "hey, swap that 10k resistor for a 4.7k, I'll test and let you know". Under AQAP 2110 that kind of change is a critical nonconformity — no trace, no impact analysis, no CCB approval, no documentation update.

The correct cycle starts with an Engineering Change Request (ECR) — a formal application for a change. Anyone on the team can submit an ECR, but with a mandatory rationale: why the change is needed (design defect, improvement, customer requirement, component obsolescence), what exactly changes and what it affects. The CCB runs an impact analysis at the next session: cost, schedule (will the batch be delayed), product performance impact, safety risks, contractual consequences. Most ECRs get rejected at this stage — and that's normal, because the CCB filters real changes from wishlist items.

If the ECR is approved, an Engineering Change Notice (ECN) is generated — a document with the full technical description of the change and updated engineering documentation. The ECN goes into production via an Engineering Change Order (ECO), specifying the exact implementation point: which batch or serial number the change kicks in at, what to do with units already built (rework, retrofit, or nothing), how to update line work instructions. The full ECR → CCB → ECN → ECO cycle typically takes from 5 working days (simple changes) to 4-6 weeks (changes requiring customer concurrence).

Verification is the final step. After ECO release, quality verifies that the change actually made it into the products, documentation was updated in sync and component suppliers received the new specs. Without verification, an ECO hangs in mid-air — formally approved, but in reality half the line is still producing to the old drawing. In defense, a Bureau Veritas auditor almost always picks 3-5 fresh ECOs and checks whether they're implemented in production. If implementation is missing, that's an automatic major nonconformity.

Configuration Status Accounting (CSA) is the knowledge base of the entire product configuration history. Put simply: for any batch built yesterday or three years ago you must be able, in 10-15 minutes, to reconstruct the full picture — which CI versions were used, which ECOs were active at release, which suppliers shipped critical components, and where the corresponding baseline lives.

The central CSA document for a defense manufacturer is the Configuration Identification Card (configuration card), or in Ukrainian shop-floor practice, the "product configuration card". It's a defense-specific document absent from a standard ISO 9001 toolkit. The card is tied to a production batch (not to an individual unit — otherwise paperwork would drown the company) and contains: batch number, release date, batch quantity, list of all CIs with exact versions at release, baseline reference, list of active ECOs, names of responsible engineers and head of quality, and the location of the full project documentation for that version.

How does an auditor verify CSA in practice? They pick 2-3 batches at random from the production journal over the last 6 months, request the configuration card, then go to the warehouse or shop floor and check several physical samples for conformance. If the card says "firmware v2.4.1" but the drone in fact runs v2.3.0, that's an automatic major nonconformity. If the card is missing entirely for a finished batch, that's an automatic Stage 2 failure with no chance to fix on the spot.

CSA also supports impact analysis in reverse: when a defect surfaces after a year in the field, you have to quickly find which other batches used the problem CI or problem firmware version. Without CSA the only option is recall of the whole production run, which for a defense manufacturer can mean multi-million-euro losses and customer trust damage. The full list of CM-block documents is broken down in the AQAP 2110 documents checklist — a useful companion to this guide.

Configuration Audits are the final mechanism for verifying the CM system, and they're often confused with regular quality audits. This is a separate audit type prescribed by ACMP-2100, with its own methodology. There are two formats, usually run sequentially.

Functional Configuration Audit (FCA) verifies that the product actually meets the functional requirements frozen in the Functional Baseline. The auditor takes the source specifications (for example, "the drone shall sustain 30-minute flight at -15°C with full payload") and tests the real product. If tests pass, FCA closes that fragment of functional requirements. If not, it's either a specification error (formal ECR needed) or a real design defect (CAPA needed). FCA is usually run after first-article testing wraps up and before serial production kicks off.

Physical Configuration Audit (PCA) verifies that the physical realisation of the product matches the Product Baseline documentation. The auditor takes the first unit from the serial batch, disassembles it (with consent), and compares every component against the BOM, every board against the schematic, every mechanical assembly against the drawing. Even small mismatches turn up — for example, the process engineer swapped an M3 screw for M3.5 "because it's easier" but the documentation isn't updated. PCA closes a fragment of engineering and production documentation as "in sync with the real product".

Who runs FCA and PCA? For Ukrainian companies it's either the customer themselves (the MoD, NSPA, an Allied MoD) during a customer audit, or an authorised third party (Bureau Veritas, for instance). Often FCA and PCA are bundled with the MoD customer audit before first-batch delivery — a sensible approach, since the customer is going to verify conformance to specs and documentation anyway. Preparing for FCA/PCA takes separate effort: pull together everything the CCB approved, remove from the line anything not aligned with the current baseline, and have the full engineering documentation package at the active version ready to hand.

Across 200-plus defense projects our team has worked through, the same mistakes show up over and over. Nearly every one comes from "we'll do CM later", where later turns out to be never. Five most common.

First and most widespread — "we run CM in an Excel sheet". Excel itself isn't the problem (though PLM is better); the problem is the absence of a formal change-approval procedure. Someone edits, someone else doesn't see it, a version is lost on save. To the auditor's question "who approved the change to v2.3, and when?" the team answers "well, we all talked about it on Skype". Automatic change-control failure.

Second — drawing changes without updating work instructions. The designer updates the drawing in the system, sends it to production, the process engineer prints it and hangs it on the line — but the operator work instruction stays old. A month later at an audit, the operator follows the instruction, the process engineer says "do it differently", and the floor turns chaotic. That's not a people problem, it's a process problem: an ECO must include updates to ALL related documents, not just the drawing.

Third — printed and system document versions don't match. Classic symptom: the line has a "v2.1" drawing signed off in 2024, the system has the latest "v2.5" from 2026. The operator goes by what they see. The fix is either full digitalisation with thin clients at each workstation, or a strict paper-replacement process with documented destruction of the previous version.

Fourth, and defense-critical — no configuration card for finished batches. Often a company runs CM for prototypes and pilot batches, then "forgets" once serial production starts. Batches ship to the warehouse without a card, because "it's just routine". The auditor asks for the card — it's not there. Major nonconformity, and this often blocks certification until a re-audit.

Fifth — software changes without a CM process, especially painful for drone manufacturers. The embedded developer pushes a commit to Git, builds the firmware, drops it onto the test bench — no ECR, no CCB, no ECO. Firmware is a fully-fledged CI and is subject to CM exactly the same way a board or mechanical assembly is. A separate sore spot is how to budget CM cost, since it's often an invisible line item. The economics is broken down in the AQAP 2110 cost and timeline guide. For manufacturers in the defense industry, the CM investment pays back on the first or second export contract.