AQAP 2110 and its companion standards

AQAP 2110 isn’t a rulebook you can read cover to cover and be done. It sits within a wider policy framework, leans on other standards, and can be extended by others. If you’re looking at getting AQAP-certified or need to fulfill a contract that invokes AQAP, understanding what the requirements and your obligations are is critical to success.

In this article, we’ll walk through the whole picture, in the order that makes sense: the contract first, because it controls everything else, then the standard, then what sits around it.

Start with the contract

AQAP 2110 does not apply in isolation. It applies because your contract invokes it. The contract also determines how it applies.

By default, every requirement applies in full. There’s no menu of optional clauses. If the standard asks for something and your contract does not explicitly mention it, you still owe it.

Only the contract can remove a requirement

You can drop or reduce a requirement, but only with the Acquirer’s agreement, documented in the contract. You cannot drop it on your own judgement or in your own quality manual just because it seemed excessive. That’s one of the traps companies coming from ISO 9001 can fall into. ISO 9001 lets you exclude requirements you decide don’t apply. AQAP does not. Excluding an AQAP requirement without the Acquirer’s written agreement is a nonconformity, however sensible your reasons may be.

So before you skip anything, ask one question: is there a documented agreement with the Acquirer that says I don’t have to? If not, you still owe it.

Some things the contract can’t touch at all

Contracts can’t sign away a law, a safety duty, or the government’s right to assure your work. You can reduce how a requirement is met. You can’t remove the requirement’s purpose and still call it an AQAP system.

That gives you the order of authority for everything below: the contract first, then AQAP’s own requirements, then any standard AQAP pulls in. Keep that order in mind. It settles almost every “does this apply to me?” question you’ll hit.

The foundation: ISO 9001

AQAP 2110 is built on ISO 9001. It doesn’t replace it. It requires everything ISO 9001 requires, then adds defence-specific requirements on top. This means that without ISO 9001 certification, you cannot move forward with AQAP. Once ISO 9001 requirements have been fulfilled (and certification acquired) you will need to add AQAP QMS requirements on top, which include:

Government access. A Government Quality Assurance Representative (GQAR), acting for the customer, can enter your facility, see your records, and talk to your people. Assurance happens during production, not just after it.
A signed Certificate of Conformity. This tells the customer that what you are delivering is what they ordered, and needs to be included with every delivery. A CoC closes the accountability loop, which is why supplier approval, counterfeit detection, foreign object prevention plans, measurements, and the likes are critical.
A quality plan you submit for acceptance before work starts, built to a companion standard (AQAP 2105).
Configuration management to a defined framework.
Counterfeit-part controls, deeper traceability, and risk planning, each defined in a way that goes beyond what ISO 9001 requires.

Defence is different from ordinary business: the customer often can’t just reject and re-order, a hidden defect can cost lives. The supply chain carries risks such as counterfeit parts, which can have wider security and geo-political implications. Each addition answers one of those realities:

Government access so problems get caught early.
A signed declaration so accountability is clear.
Traceability so a bad batch can be found and pulled.
Counterfeit controls so nobody slips failure into your product.

The takeaway: An ISO 9001 certificate is a strong start, not a finish line. The gap between it and AQAP is where much of the additional defence-quality work begins.

If you’re new to the relationship between ISO 9001 and AQAP, start with What is a QMS? ISO 9001, AQAP, and what defence contracts require.

Policy vs requirements

Two AQAP documents sound similar but do completely different jobs. Getting them mixed up is a common, avoidable mistake.

AQAP-2000 is policy. It sets out NATO’s overall approach to quality. You are never audited against it, and you never cite it as the basis for a requirement.

AQAP 2110 (and its siblings, 2210, 2310, 2105) are the actual requirements. This is what you build to and get audited against.

The same split exists in configuration management: ACMP-2000 is policy and states outright that it can’t be used in contracts, while ACMP-2100 holds the contractual requirements. So when you write your quality manual, cite AQAP 2110, not AQAP-2000. Cite ACMP-2100, not ACMP-2000. Citing the policy tells an auditor you’ve missed the distinction.

The AQAP companion standards

AQAP 2110 doesn’t contain everything it requires. In a few places it points to other documents that carry the detail. These obligations are real even though they live elsewhere.

AQAP-2105 defines what goes in your quality plan. AQAP 2110 requires the plan; 2105 tells you what an acceptable one contains.
ACMP-2100 holds the configuration management requirements your CM plan is built to.
AQAP-2070 is the mechanism for government quality assurance at sub-suppliers in other NATO countries. AQAP 2110 says sub-tier GQA can be required; 2070 is how it actually happens across borders.

One worth watching: AS/EN5553, the industry benchmark for counterfeit-part prevention. AQAP 2110 requires you to have a counterfeit process, but it doesn’t mandate AS/EN5553. AS/EN5553 is a common way to meet the AQAP requirement, not an AQAP requirement itself. Know the difference, so you can always say where an obligation actually comes from: the NATO framework, your contract, or a standard you chose to adopt.

The supplements that sit on top

Two standards can be layered over AQAP 2110 and change what you are required to do. A single line in your contract brings them in.

AQAP 2310 is an alternative base, not an add-on. Where AQAP 2110 is built on ISO 9001, AQAP 2310 is built on the aerospace standard AS/EN9100. Where applicable, aviation and space contracts use 2310 as the base instead of 2110. A contract picks one or the other.

AQAP 2210 is the software supplement, and it’s the one that catches people out. It never applies alone; it’s always added to AQAP 2110 or 2310. When a contract invokes it, you owe a whole software-quality regime on top of the base: a software quality plan submitted before development starts, a criticality analysis, software configuration management, controls over off-the-shelf software, and testing scaled to how critical the software is.

Two things make 2210 easy to miss and easy to underestimate:

You won’t see it coming by reading AQAP 2110. Nothing in 2110 tells you a software quality plan is required. That obligation lives in 2210, and 2210 is invoked by your contract. If your product has embedded software, check whether the contract invokes it.
The workload depends entirely on criticality. 2210 makes you sort each piece of software by how bad failure would be, and scales the rigour to match. Safety-critical software pulls demanding controls; lower-criticality software pulls light ones. So the criticality analysis isn’t paperwork — it sets the size of the whole job. Rate it too low and your testing won’t match the real risk. Rate it too high and you waste effort.

Underneath it all: the STANAGs

One layer sits beneath everything and explains why the system works between countries at all. A STANAG is the NATO standardization agreement through which member nations adopt common standards and procedures. STANAG 4107 is the one that lets government quality assurance done in one nation be accepted by another. It’s part of why government quality assurance can be recognized across national boundaries. You’ll rarely cite it, but it’s the reason the whole structure holds together.

One requirement, all the way through

Here’s how it fits together in practice. Follow configuration management from contract to delivery:

The contract invokes AQAP 2110. That brings the configuration management requirement into play. No invocation, no obligation.
AQAP 2110 requires configuration management to a defined framework, but points elsewhere for the detail.
The detail is in ACMP-2100. You build your CM plan to it, and cite it — not the ACMP-2000 policy above it.
If the contract also invoked AQAP 2210 and your product has software, the obligation extends into software configuration management, under 2210’s rules.
If the Acquirer agrees in writing to a lighter regime for a low-risk item, that’s valid tailoring. If you quietly scale it back yourself, that’s a nonconformity.

One requirement, shaped at every step by the contract above it. That’s the pattern for all of AQAP 2110.

What to do with this

Three habits keep you out of trouble:

Read the contract first. It tells you which standards apply, how they apply, and in what form. Everything else is subject to it.
Cite the right document. Requirements, never policy. ACMP-2100, never ACMP-2000. Cite the publication your contract actually invoked.
Never exclude anything on your own. If you’re not doing something the standard asks for, make sure a written agreement with the Acquirer says you don’t have to.

Get those right and AQAP 2110 stops being a wall of clauses and becomes what it is: one document in a clear structure, with the contract on top. That’s the difference between meeting the letter of a clause and understanding what defence quality assurance is there to achieve.

This matters particularly for smaller defence suppliers trying to establish themselves in a market where recognised standards are increasingly part of how companies build trust. We explored that theme after MSPO 2026.

If you’re working out what applies to your own contracts and want a second pair of eyes, that’s what we do.