AQAP 2110 is the Allied Quality Assurance Publication governing quality management system requirements for design, development, and production of software within defense contracts. While ISO 9001 is the baseline quality standard recognized across industries, AQAP 2110 goes further — it is specifically written for the defense procurement context, imposing additional requirements that reflect the unique demands of military software programs: Government Quality Assurance (GQA) oversight, formal software development planning, and stringent configuration management.
For a software vendor seeking to work on contracts issued by member nations, understanding what AQAP 2110 requires — and how it differs from ISO 9001 in practice — is essential preparation. This article covers the standard's structure, its key requirements, and the certification process that vendors must navigate.
What AQAP 2110 Is and How It Differs from ISO 9001
AQAP 2110 is based on ISO 9001 and incorporates all of its requirements. Vendors certified to AQAP 2110 implicitly satisfy ISO 9001. However, AQAP 2110 adds a layer of defense-specific requirements that ISO 9001 does not contain.
The most significant addition is Government Quality Assurance (GQA). Under AQAP 2110, the contracting authority (typically a national defense ministry or procurement agency) retains the right to conduct surveillance audits of the vendor's quality management system during contract performance. A government quality assurance representative (GQAR) may visit the vendor's site, review development artifacts, witness tests, and verify that the contracted software development processes are actually being followed. This is fundamentally different from ISO 9001, where the audit relationship is purely between the organization and its certification body.
AQAP 2110 also requires vendors to produce a Software Development Plan (SDP) — a formal document that defines how the vendor will manage the software development process for the specific contract. The SDP must address software lifecycle model selection, development environment, quality activities, configuration management, risk management, and the processes for verification and validation. The SDP is subject to approval by the customer before development begins, giving the contracting authority visibility and influence over development process decisions.
A further distinction is the explicit requirement for Software Configuration Management (SCM) that is more prescriptive than ISO 9001's general configuration management requirements. Under AQAP 2110, configuration management must cover identification of configuration items, control of changes, status accounting, and configuration audits. For defense software, this means every version of every software component must be uniquely identified, and changes must follow a controlled process with documented approval and traceability.
Key Requirements: SDP, SCM, Verification and Validation, and Reviews
Software Development Plan (SDP). The SDP is the contract-specific planning document that ties the vendor's general QMS capabilities to the specific program. It must identify the software items within scope, the development methodology to be used, the development and test environments, the configuration management approach, the risk register and mitigation strategies, and the schedule and milestones for quality activities. The SDP is a living document — it must be updated as the program evolves and significant changes require formal approval from the customer.
Software Configuration Management (SCM). AQAP 2110 requires a formal SCM system that provides full traceability from requirements through design, implementation, and testing to delivered software. Configuration item identification must cover source code, build scripts, test suites, documentation, and third-party components. Change control must ensure that no change to a configuration item is made without authorization, review, and documentation. Configuration status accounting must provide a complete audit trail of what changed, when, why, and by whom. Configuration audits — both functional and physical — verify that the delivered software matches its documented specifications.
Verification and Validation (V&V). AQAP 2110 distinguishes between verification (confirming that the software correctly implements its specification) and validation (confirming that the specification correctly captures the customer's needs). Both must be planned in the SDP and executed with documented evidence. Verification activities include code reviews, static analysis, unit testing, integration testing, and system testing. Validation activities typically involve the customer and may include acceptance testing against operational scenarios. AQAP 2110 requires that V&V planning identify what will be checked, by what method, at what stage, and with what acceptance criteria.
Formal Reviews. The standard requires formal reviews at defined stages of the software lifecycle. These typically include a Software Requirements Review (SRR) at the end of requirements definition, a Preliminary Design Review (PDR) and Critical Design Review (CDR) during design, and a Test Readiness Review (TRR) before testing begins. Each review has defined entry criteria, agenda, participants, and exit criteria. The reviews are not purely internal — the customer (or GQAR) is typically invited as an observer or participant. Review minutes, action items, and disposition records are quality records subject to GQA oversight.
Practical impact: The SDP requirement is where many vendors underestimate the effort involved. A compliant SDP for a non-trivial program is typically 50–150 pages, addresses the full development lifecycle, and must be agreed with the customer before work begins. Vendors who approach the SDP as a box-ticking exercise — producing a minimal document that says the right words without reflecting actual practice — are likely to encounter difficulties during GQA audits.
How AQAP 2110 Affects SDLC Processes
The practical effect of AQAP 2110 on software development processes is substantial. The standard does not prohibit agile or iterative methods — it requires that whatever method is used be documented, planned, and consistently followed. Vendors who use agile methods must document how their agile practices satisfy AQAP 2110's requirements for planning, configuration control, and V&V, which requires more explicit process mapping than most commercial agile implementations provide.
Change management becomes significantly more rigorous. In commercial development, a developer who identifies a better approach mid-sprint can implement it with minimal process overhead. In an AQAP 2110 context, changes to baseline design artifacts require a change request, impact analysis, approval from the relevant authority (potentially including the customer), and an update to the affected configuration items and their status. This is not bureaucratic inefficiency — it is the mechanism that maintains traceability and allows GQA oversight to be meaningful.
Test evidence requirements affect how testing is conducted and recorded. It is not sufficient to state that tests were run; test plans, test procedures, test results, and anomaly reports must be maintained as formal records. Defects found during testing must be tracked, root-caused, corrected, and regression-tested with documented evidence at each step. This drives the adoption of formal defect tracking systems and test management tools that many commercial development teams use informally or inconsistently.
Certification Process: NSPA and National Certification Bodies
AQAP 2110 certification for individual contracts is typically managed differently from ISO 9001 certification. Rather than a single global certification, AQAP compliance is generally assessed at the contract level, with GQA oversight performed by the national authority of the contracting nation.
The NATO Support and Procurement Agency (NSPA) provides AQAP-related support and can conduct GQA on behalf of member nations for certain categories of contract. More commonly, national defense procurement agencies have their own quality assurance organizations — the Defence Equipment and Support (DE&S) in the UK, the Direction Générale de l'Armement (DGA) in France, the Bundesamt für Ausrüstung, Informationstechnik und Nutzung der Bundeswehr (BAAINBw) in Germany — that conduct GQA oversight on contracts in their jurisdiction.
Vendors seeking to demonstrate AQAP 2110 compliance typically pursue one of two paths: contract-specific compliance, where the QMS implementation is assessed as part of the contract award process; or third-party certification, where an accredited certification body formally certifies the QMS against AQAP 2110 requirements. Third-party certification provides evidence of capability that can be cited in bids before a specific contract is awarded, which is why larger defense software vendors typically pursue it proactively.
The relationship between AQAP 2110 and national defense quality standards should also be understood. Some nations apply AQAP standards directly; others have national equivalents (the UK's DEFSTAN 05-series, for example) that reference or align with AQAP. Vendors working across multiple national customers should verify which standards apply in each jurisdiction and whether their AQAP 2110 certification satisfies national requirements or requires supplementation.