In a defence project, software quality does not end with an application working correctly on the acceptance date. The customer needs control over requirements, configuration, changes, testing, subcontractors and the evidence demonstrating that the product complies with the contract. The customer must also know which version was delivered, on what basis it was accepted and whether it can be maintained and developed safely.
AQAP 2210 brings structure to these matters at software project level. The publication sets out NATO requirements for software quality assurance and is used as a supplement to AQAP 2110 or AQAP 2310. Its significance, however, does not arise merely from the use of the acronym AQAP. In practice, the requirements of the specific contract, the scope of supply, software criticality and the agreed arrangements for oversight and acceptance are decisive.
For the customer, this means that selecting an IT supplier should involve much more than assessing technology, developer availability and price. The organisation needs a partner capable of developing software under controlled conditions, maintaining traceability and producing credible quality evidence. This article explains how to interpret AQAP 2210 requirements and apply them when selecting an IT supplier for the defence sector.
KEY TAKEAWAY: AQAP certification is important evidence of the maturity of a supplier’s quality management system. It does not, however, replace analysis of the specific contract requirements or the quality evidence generated during project delivery.
1. AQAP 2210 at a glance
- AQAP 2210 addresses software quality assurance in projects delivered in a defence environment.
- The current publication is AQAP 2210, Edition B, Version 1, issued in 2022.
- It supplements AQAP 2110 or AQAP 2310 and is not designed as a completely standalone set of requirements.
- Its application to a project primarily results from the contract, procurement specification and referenced quality documents.
- It covers management and technical processes, including quality planning, criticality analysis, requirements, configuration, verification, validation, testing and subcontractor control.
- It does not mandate a single software development model. It can coexist with Agile and DevSecOps provided that the organisation maintains control, accountability and objective evidence.
- A supplier’s certificate does not automatically demonstrate the compliance of every product or project. The certification scope, contract requirements and application of processes to the specific undertaking all matter.
2. What is AQAP 2210?
AQAP stands for Allied Quality Assurance Publications. The AQAP family supports a common approach among NATO nations to the quality of defence supplies. Its purpose is to increase confidence that a supplier can deliver a product that meets contractual requirements and provide the customer with appropriate visibility of processes affecting quality.
AQAP 2210, Edition B, Version 1, contains NATO supplementary software quality assurance requirements. It is project-oriented and covers both management and technical processes. It does not prescribe a particular software methodology, programming language, tool or architecture. Its purpose is to establish a level of planning, control and evidence that gives the customer justified confidence in both the process and the product.
AQAP 2210 is to be used in conjunction with AQAP 2110 or AQAP 2310, depending on the core set of requirements referenced in the contract. In Poland, current publications used in certification processes are described by the Polish Centre for Testing and Certification and the Quality Certification Centre of the Military University of Technology. The status of AQAP 2210 Edition B as an active publication can also be verified in the US ASSIST standardisation document database.
2.1 A contractual requirement, not universally applicable legislation
AQAP 2210 should not be presented as legislation that automatically applies to every company developing defence software. Binding obligations arise primarily from the contract, specification, quality clause and documents referenced by the customer.
In one project, AQAP 2210 may cover the full development lifecycle of a new system. In another, it may apply to the modification of an existing solution, component integration or software maintenance. Requirements may be subject to justified tailoring where the publication and the customer permit it. Such decisions should nevertheless be transparent, approved and documented. A supplier should not independently declare an inconvenient requirement inapplicable.
3. AQAP 2110 and AQAP 2210: what is the difference?
AQAP 2110 and AQAP 2210 are related but perform different functions. AQAP 2110 establishes broad quality assurance requirements for design, development and production. AQAP 2210 expands on these requirements for software and for work performed at individual project level.
| Area | AQAP 2110 | AQAP 2210 |
| Principal scope | Quality assurance in design, development and production | Supplementary software quality assurance |
| Role | Core set of quality assurance requirements | Software-specific supplement to AQAP 2110 or AQAP 2310 |
| Perspective | Supplier quality management system and product delivery | Project, processes and software-related evidence |
| Example areas | Planning, risk, suppliers, nonconformities and delivery oversight | Project Software Quality Plan, criticality, requirements, SCM, V&V and testing |
| Application | Depends on contract requirements and the type of supply | Applies when the contract covers software and references the relevant requirements |
| Standalone use | May serve as the core quality publication | Used in conjunction with AQAP 2110 or AQAP 2310 |
ISO 9001 remains an important foundation for systematic quality management, but it does not describe every mechanism needed in a defence project or the detailed quality requirements for software. Assessment of a potential partner should therefore go beyond asking whether the company holds ISO 9001 certification. The customer should establish whether the supplier’s system covers the relevant AQAP scope and whether the organisation can apply it to the specific project.
4. When does AQAP 2210 apply to an IT project?
The contractual documentation provides the most reliable answer. The requirement may be stated directly in the contract, procurement specification, quality clause or quality plan, or in requirements imposed on the prime contractor and flowed down to subcontractors.
AQAP 2210 may be relevant to projects involving:
- development of new bespoke software;
- development or substantial modification of an existing system;
- software maintenance and support;
- integration of software with hardware, sensors, effectors or platforms;
- command, control and situational awareness systems;
- C2, C4ISR and combat support systems;
- embedded software or a component forming part of a larger product;
- use or modification of commercial off-the-shelf software;
- delivery of a software component by a subcontractor to the prime contractor.
The mere presence of code in a product does not, however, determine an identical scope of requirements. An application supporting an administrative process may require different controls from a component affecting a critical function. Before work begins, the parties should therefore identify at least the scope of supply, their respective responsibilities, software criticality, dependencies, acceptance arrangements and the evidence required by the customer.
4.1 Questions to ask before signing the contract
- Which AQAP publications and editions are referenced?
- Do the requirements apply to the entire supply, a specific component or selected processes?
- Is tailoring permitted and, if so, who approves it?
- What oversight and access rights are granted to the customer or Government Quality Assurance Representative?
- Which plans, records, reports and evidence are required for reviews and acceptance?
- Which obligations must be flowed down to subcontractors?
- How will software criticality be assessed, and how will it affect the rigour of project activities?
Clarifying these points early reduces the risk of costly rework to documentation, testing processes or the supply chain once delivery is under way.
5. Why does AQAP 2210 matter to the customer?
In a conventional commercial project, some ambiguities can be resolved by renegotiating scope or moving a deadline. In a defence project, the consequences of an incorrect configuration, incomplete test or loss of traceability may be much more serious. The system may interact with hardware, process operationally significant data or operate in an environment with limited connectivity and elevated threats.
AQAP 2210 helps the customer reduce risks including:
- delivery of functionality that does not comply with contractual requirements;
- changes introduced without impact assessment and approval;
- absence of links between requirements, design, code and test results;
- inability to identify unequivocally the configuration submitted for acceptance;
- detection of critical defects only during acceptance testing;
- lack of objective evidence that tests were performed;
- uncontrolled use of external components;
- insufficient oversight of subcontractors;
- loss of knowledge needed to maintain and further develop the system;
- closure of a nonconformity without confirmation that the correction was effective.
The principal value is therefore not the number of documents produced, but transparency. The customer can verify how the supplier interprets requirements, controls work, manages open risks and determines that a product is ready.
6. Key AQAP 2210 requirements in a software project
AQAP 2210 covers numerous interrelated processes. Their detailed application depends on the contract, but the areas below are among the most important when assessing a supplier and planning delivery.
6.1 Project Software Quality Plan
The Project Software Quality Plan should demonstrate how the organisation will meet the quality requirements of a specific undertaking. It is not a general quality policy or a document produced only immediately before an audit.
A robust plan connects contractual requirements with the actual way in which the team works. It defines the scope, roles, responsibilities, lifecycle, reviews, verification and validation methods, configuration management, subcontractor control, metrics and required records. It should also identify dependencies between documents and explain how the plan will be updated when the project changes.
The customer should be able to use it to understand not only what the supplier declares, but also when evidence will be provided, who will make decisions and how deviations will be handled.
6.2 Software criticality analysis
Criticality helps align the rigour of project activities with the consequences of a potential failure. The analysis should consider the function of the software, its relationship with the overall system and the potential effect of malfunction on people, the mission, equipment, information and continuity of operations.
The outcome may affect the independence of reviews, test scope, required coverage, reporting frequency, level of change control and treatment of risk. The objective is not to impose the most expensive controls on every component, but to reach a conscious, documented and justified decision.
6.3 Requirements management and traceability
Requirements should be unambiguous, verifiable and subject to change control. The supplier must understand system, software and component requirements, together with constraints arising from architecture, interfaces, security and the operating environment.
Traceability makes it possible to move from a requirement to the design solution, implementation and test, and then back from the test result to the contractual basis. It may be maintained in a matrix or a dedicated tool. What matters is that it remains current and reveals requirements without design coverage, code without justification or tests without a corresponding requirement.
In a mature project, a requirement change triggers an assessment of its impact on architecture, code, tests, documentation, schedules and subcontractors. Updating a backlog item alone is insufficient if the remaining evidence is left out of date.
6.4 Software configuration management
Software configuration management, or SCM, provides unambiguous identification of product items and control over their changes. It does not concern source code alone. Its scope may include requirements, models, scripts, environment configurations, libraries, documentation, test data, tools, build artefacts and installation packages.
The customer should expect clear answers to practical questions such as:
- Which items make up a particular product version?
- Who approved a change, and on what basis?
- Can the build submitted for testing or acceptance be reproduced?
- How are the status of changes and nonconformities recorded?
- Does the supplier control dependencies, libraries and tool versions?
- How are repositories protected and access restricted?
Without these mechanisms, even correctly tested functionality may enter the wrong release or be overwritten by a later change.
6.5 Verification, validation and testing
Verification asks whether the product has been built in accordance with specified requirements and design. Validation establishes whether the solution meets the needs and intended use in its target context. In practice, both types of activity should be planned, have defined criteria and owners, and produce retained results.
The test programme may cover unit, integration, system, performance, security, resilience and acceptance testing. The scope depends on the product and contract. Key considerations include:
- linking tests to requirements;
- defined test environments and test data;
- identification of the product version under test;
- test entry and exit criteria;
- results, deviations and evidence of execution;
- separation of roles where independence is required;
- handling of defects, retesting and regression testing.
Automation can improve repeatability, but a pipeline report is not complete evidence on its own if it does not identify what was tested, which version was used and which criteria governed the assessment.
6.6 Nonconformities and corrective action
The supplier should operate a controlled process for recording, assessing and closing nonconformities. A correction that addresses an immediate defect should be distinguished from corrective action intended to eliminate its cause.
The record should make it possible to determine the impact of the problem, affected versions, the disposition decision, responsibility, retest results and any need to inform the customer. Recurring problems should lead to trend analysis and an assessment of process effectiveness, rather than another sequence of isolated code fixes.
6.7 Subcontractors, COTS and external components
Modern software uses libraries, tools, services, devices and ready-made components. AQAP 2210 does not allow them to be treated as areas outside the supplier’s responsibility. The organisation should assess a component’s suitability, constraints, rights of use, documentation, configuration and effect on requirements.
For commercial off-the-shelf software, objective grounds are needed to establish that the product will fulfil the required function. Where full traceability is not possible, the limitation should be identified, assessed and appropriately managed. Modifying ready-made software may also change the risk profile and responsibility for maintenance.
The same principle applies to subcontractors. The prime contractor should specify requirements, monitor performance and retain evidence of oversight. A subcontractor’s certificate may support qualification, but it does not release the prime contractor from responsibility for compliance of the overall supply.
7. Can Agile and DevSecOps be reconciled with AQAP 2210?
Yes. AQAP 2210 does not prescribe a single lifecycle model or mandate a waterfall approach. Agile and DevSecOps can be used if the organisation can demonstrate control over requirements, configuration, testing, accountability and releases.
| Agile or DevSecOps practice | Corresponding quality mechanism |
| Product backlog | Controlled record of requirements, priorities and changes |
| Definition of Ready | Criteria establishing that a requirement is ready for implementation |
| Definition of Done | Quality, testing, documentation and acceptance criteria |
| Pull request and code review | Documented review and approval of a change |
| Code repository | Item identification and configuration control |
| CI/CD | Repeatable build, automated controls and retained results |
| Test management | Link between requirement, test case, product version and result |
| Release pipeline | Controlled release and unambiguous identification of its contents |
| Retrospective | Process improvement and corrective action |
The most common mistake is to equate agility with an absence of documentation. Documentation in an Agile project may be lighter, generated automatically and maintained in tools. It must nevertheless remain credible, accessible and understandable to those responsible for oversight.
A second risk is excessive reliance on automation. A pipeline may execute thousands of tests, but the customer also needs context: the product version, test scope, criteria, deviations and approval. DevSecOps supports AQAP when it automates a controlled process, not when a stream of logs obscures the absence of accountability.
8. What documents and evidence may the customer expect?
The final evidence set is determined by the contract. There is no single file or binder suitable for every project. In practice, the customer may expect materials such as:
| Area | Examples of documents and records | Control question |
| Planning | Project Software Quality Plan, review schedule and responsibility matrix | Is it clear who makes each decision, when and against which criteria? |
| Requirements | Specifications, change history, traceability matrix and review records | Does every requirement have a source, an owner and a verification method? |
| Configuration | SCM plan, configuration item list, baselines and release register | Can the exact version delivered to the customer be reproduced? |
| Testing | Plans, cases, data, reports, results and defect records | Does the result relate to the correct version and an approved requirement? |
| Nonconformities | Problem reports, decisions, root-cause analysis and retest records | Has the problem been effectively resolved rather than merely marked closed? |
| Suppliers | Qualification criteria, assessments, purchasing requirements and reviews | Have quality obligations been flowed down and are they monitored? |
| COTS and dependencies | Suitability assessment, versions, licences, constraints and functional evidence | Does the organisation understand the risk and can it maintain the component? |
| Acceptance and delivery | Release documentation, acceptance results and list of deviations | Are the contents of the delivery and any remaining limitations unambiguous? |
Evidence should be credible, current, linked to the relevant scope and reproducible. A screenshot without a date, version or owner has limited value. Equally, a policy describing a process does not demonstrate that the process was actually applied to the project.
9. What does AQAP certification demonstrate, and what does it not guarantee?
Certification of a quality management system by a competent body is an important signal to the customer. It shows that a defined scope of the organisation’s activities has been assessed against the specified requirements and that the company maintains processes necessary for controlled delivery.
A certificate may demonstrate:
- implementation and maintenance of a quality system conforming to a specified AQAP publication;
- assessment of the stated scope of activities and locations;
- the existence of controlled processes, responsibilities and records;
- periodic third-party assessment of the system;
- an organisational foundation for performing contracts that require AQAP.
A certificate does not automatically guarantee:
- compliance of every project with every contract;
- a defect-free product;
- fulfilment of requirements outside the certification scope;
- possession of every clearance, authorisation or domain competence required by the project;
- effective application of processes without the right team and oversight;
- acceptance of the supplier by every customer without further qualification.
The customer should therefore verify the issuing body, certificate validity, AQAP publication and edition, certification scope, locations and alignment of that scope with the planned procurement. It is also worth asking the supplier to demonstrate how its quality management system will be applied to the specific project.
10. How should you select an IT supplier for a defence project?
A capable supplier combines three layers: organisational capability, technical competence and understanding of the defence environment. A weakness in any one of them may become apparent only during integration, oversight or acceptance.
10.1 Customer checklist
- [ ] The certification scope covers software development, delivery or maintenance relevant to the planned project.
- [ ] The supplier can translate contractual requirements into a quality plan and the team’s daily work.
- [ ] Requirements, design decisions, implementation and tests remain traceable.
- [ ] Configuration management covers code, documentation, dependencies, environments and releases.
- [ ] The build submitted for testing or acceptance can be reproduced unambiguously.
- [ ] The V&V process has defined roles, criteria, environments and retained results.
- [ ] Nonconformities are assessed, tracked, retested and closed on the basis of evidence.
- [ ] Subcontractors and COTS components are subject to qualification and monitoring.
- [ ] The team understands software-hardware integration and constraints of the target environment.
- [ ] The supplier understands defence systems, NATO standards and work within a supply chain.
- [ ] It can produce the quality evidence required for reviews, oversight and acceptance.
- [ ] It can provide maintenance, change management and controlled development after deployment.
- [ ] The engagement model clearly allocates responsibility for the product, quality, security and decisions.
- [ ] The experience claimed is relevant to the actual scope and criticality of the procurement.
10. Warning signs during supplier qualification
Answers limited to stating that the company is certified or works in Agile should prompt caution. Other warning signs include:
- inability to explain the certification scope;
- a quality plan copied without adaptation to the project;
- no owner for the configuration management process;
- tests that are not linked to requirements and the product version;
- subcontractors treated as solely responsible for their own quality, without prime contractor oversight;
- no controlled process for approving deviations;
- documentation prepared only immediately before acceptance;
- inability to explain how changes will be handled after deployment.
The best test is a discussion based on a realistic scenario: a high-criticality requirement changes, affects a subcontracted component and requires a new integration test. A mature partner can explain the impact assessment, decisions, configuration update, testing and evidence without hiding behind a generic procedure.
11. Why choose TTMS as a partner for the defence sector?
The selection of a technology partner should be based on its fit with the specific undertaking. In the case of TTMS, the relevant strength is the combination of a certified quality management system, technical capabilities and domain experience.
11.1 Certified quality processes
TTMS has obtained AQAP 2110 and AQAP 2210 certification, as described in the TTMS press release. For a prospective customer, this confirms that a defined scope of the company’s quality management system has been independently assessed against requirements used in the defence sector and in software quality assurance.
Certification is not presented as a substitute for project analysis. It provides an organisational foundation on which to build the quality plan, traceability, configuration management and evidence required by a particular contract.
11.2 Technical expertise and domain knowledge
The public TTMS offering for the defence and space sectors includes software development, defence IT engineering services, hardware-software integration, technical consultancy, project management and the provision of specialist teams. TTMS also describes experience involving C2, C4ISR and combat support systems, as well as work in the environment of international organisations.
This combination matters because process conformity cannot replace engineering competence. Conversely, even a highly capable software team may struggle in a defence project if it cannot work with contractual requirements, quality oversight and formal evidence.
11.3 A flexible engagement model
A project may require a complete solution, a distinct component, integration, a software team or individual specialist capabilities. The model should be selected after analysing the scope, responsibilities and quality requirements. Regardless of the form of engagement, ownership of requirements, configuration, testing, risk and acceptance should be clearly established.
TTMS can join the undertaking as a technology partner supporting software development, integration and maintenance. The final obligations, applicable AQAP publications and required evidence should be defined in the documentation of the specific project.
12. What can an engagement with TTMS look like?
12.1 Context and requirements analysis
The first stage establishes the purpose of the system, scope of supply, stakeholders, architecture, quality requirements and security constraints. The team identifies the publications and clauses referenced in the contract and areas requiring clarification.
12.2 Definition of the delivery model
The parties establish responsibilities, team composition, interfaces with the customer and other suppliers, lifecycle, reviews, tools, configuration and required evidence. This stage should also plan the flow-down of requirements to subcontractors.
12.3 Controlled development and reporting
Delivery combines engineering work with requirements, risk, configuration, quality and nonconformity management. The customer receives the agreed visibility of progress, results and open decisions.
12.4 Verification, validation and acceptance
Tests and reviews are performed on controlled versions against approved criteria. The acceptance package should unambiguously identify the delivery contents, results, deviations and remaining limitations.
12.5 Maintenance and controlled development
After deployment, configuration management, problem handling, updates, change impact assessment and documentation maintenance remain necessary. The support model should reflect the importance of the system and the required availability.
13. Are you looking for an IT partner for a defence project?
A defence project requires a simultaneous understanding of technology, quality, integration, security and contractual accountability. It is worth involving the supplier before the architecture and delivery plan are finalised, so that AQAP requirements are not treated as a documentation exercise postponed until acceptance.
Contact TTMS to discuss your project’s technical and quality requirements, allocation of responsibilities and a potential engagement model with the Defence team.
14. Frequently asked questions about AQAP 2210
What is AQAP 2210?
AQAP 2210 is a NATO publication containing supplementary software quality assurance requirements. It is project-oriented and covers the management and technical processes needed for controlled software development and delivery.
What do AQAP 2210 requirements cover?
They include software quality planning, criticality analysis, requirements management, traceability, configuration, subcontractors, COTS software, verification, validation, testing and the treatment of nonconformities. The exact scope in a project is determined by the contract.
What is the difference between AQAP 2110 and AQAP 2210?
AQAP 2110 establishes broad quality assurance requirements for design, development and production. AQAP 2210 expands on software-specific requirements and is used as a supplement to AQAP 2110 or AQAP 2310.
Can AQAP 2210 be used on its own?
Not as a completely independent set of requirements. The current edition is intended for use as a supplement to AQAP 2110 or AQAP 2310. The applicable combination should be specified in the contract.
When is AQAP 2210 required in an IT project?
It is required when referenced in a contract, specification, quality clause or requirements imposed on the contractor. The fact that software is being developed for the defence sector does not, without examination of the documentation, establish an identical set of obligations in every case.
Does every military software supplier need AQAP certification?
There is no universal rule to that effect. The need for certification and its scope depend on the customer, procurement procedure, contract and type of supply. Even where certification is required, its validity and alignment with the project scope should be verified.
Is ISO 9001 sufficient for a defence project?
ISO 9001 can provide an important quality management foundation, but it does not replace detailed AQAP requirements referenced in the contract. Nor does it describe every mechanism focused on software quality assurance in a defence environment.
Is AQAP 2210 compatible with Agile and DevSecOps?
Yes. It does not mandate a single development model. The team must nevertheless retain control over requirements, changes, configuration, testing, accountability and evidence. Agile cannot be used to justify a loss of traceability.
What documents should a software supplier prepare?
Depending on the contract, these may include a Project Software Quality Plan, configuration management plan, requirements register, traceability matrix, review reports, test plans and results, change and nonconformity records, supplier assessments, and release and acceptance documentation.
Does AQAP 2210 cover COTS components and subcontractors?
Yes. The supplier should oversee subcontractors and assess the suitability, configuration, documentation, constraints and risks of ready-made components. Responsibility for the overall supply does not disappear because part of the solution originates from another organisation.
How can the scope of a supplier’s AQAP certificate be verified?
The issuing body, certificate number and validity, AQAP publication and edition, scope of activities, locations and any exclusions should be checked. The scope should correspond to the work actually entrusted to the supplier.
Why choose a supplier certified to AQAP 2110 and AQAP 2210?
The certificates can reduce uncertainty regarding the maturity of the quality management system and the organisation’s ability to operate controlled processes. The customer should still assess technical capabilities, domain experience, certification scope and the proposed application of requirements to the specific project.
