Platform
Modules
By sector
By sector
By standard
Blog
News
Events
STANREC 4814
National defence authorities and NATO bodies choosing which software life cycle process standard to adopt, and the suppliers whose contracts end up naming it
STANREC 4814 is a NATO recommendation, not a binding agreement, naming ISO/IEC/IEEE 12207:2017 as the standard nations are invited to use for managing software life cycle processes.
STANREC 4814 is a NATO Standardization Recommendation on systems and software engineering, covering software life cycle processes. The distinction that matters most is in its name: unlike a STANAG, a STANREC does not commit a nation to ratify anything. NATO's own text is explicit that "nations are invited to use the Allied standard(s) covered by the STANREC and to provide feedback to the NSO on the use of the covered Allied standard(s)" - an invitation, not a ratification obligation. Nothing in this document creates a duty for a supplier to sign up to directly. It is supervised under CNAD's Life Cycle Management Group (AC/327 LCMG, Working Group 2).
The document's aim is "to list recommended practices regarding: the software life cycle management in both the quality domain and the engineering domain." Its recommendation names exactly one standard: ISO/IEC/IEEE 12207:2017, Systems and Software Engineering - Software Life Cycle Processes. Unlike some STANRECs that list a whole family of standards, this one is a single, direct pointer.
Alongside that recommendation, it names five further documents under "other related documents," without saying any of them bind anything here: STANAG 4107, on mutual acceptance of government quality assurance and the Allied Quality Assurance Publications; STANAG 4728, on system life cycle management, alongside AAP-20 and AAP-48; ISO/IEC/IEEE 15288:2023, on system life cycle processes; AS9115 Rev A, quality management requirements for aviation, space and defense organizations covering deliverable software, a supplement to EN 9100; and AS9125, issued 2024-10, the equivalent aerospace requirements for non-deliverable software.
This edition supersedes STANAG 4814, Edition 1, dated 23 February 2018. The change of document type between editions is worth noting on its own: what nations once ratified as an agreement, they are now only invited to use. A reader who assumes the current STANREC carries the same weight as the STANAG it replaced would be assuming the wrong thing.
STANREC 4814 has no clauses of its own to audit against. Its testable content sits inside ISO/IEC/IEEE 12207, the standard it recommends, and in the related documents it names for context: STANAG 4107, STANAG 4728 (alongside AAP-20 and AAP-48), and EN 9100, which AS9115 Rev A supplements. The document is reviewed periodically in accordance with AAP-03, with the result recorded in the NATO Standardization Documents Database; that review is the only ongoing mechanism the document names, and it checks the document's own currency, not an organisation.
STANREC 4814 itself gives an organisation nothing to implement in software: it recommends which standard to follow for software life cycle processes, and the testable content sits inside ISO/IEC/IEEE 12207:2017, not here.
What is left is the ordinary discipline of evidencing a choice: recording which software life cycle process model a programme actually follows, holding that decision as a controlled document with its rationale, and keeping the record linked to the contract that specified it, across both the quality and engineering domains the recommendation names. ComplyTrain gives a place to hold that documentation, track who approved it, and keep it current as a programme's software life cycle approach evolves.
ComplyTrain does not define or execute the software engineering processes themselves - that work is done in the development and quality practices built to ISO/IEC/IEEE 12207. Which standard a given contract requires is set by the contract and the customer's quality clause, not by this page. Our standards explorer shows what sits alongside STANREC 4814 - if you're weighing up what a tender is actually asking for, we're glad to talk it through.
Tell us how you need to work with STANREC 4814 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
No. A STANREC is a recommendation: NATO nations are invited to use the standard it names, without the ratification obligation a STANAG carries. Whether ISO/IEC/IEEE 12207 applies to a specific programme is a question for that programme's contract.
A STANAG is an agreement nations ratify and commit to implement. A STANREC recommends a standard without that obligation - nations are invited to use it and to report their experience, but nothing requires them to. STANREC 4814 was itself previously issued as STANAG 4814, Edition 1, before being reissued as a recommendation.
It recommends a single standard, ISO/IEC/IEEE 12207:2017, Systems and Software Engineering - Software Life Cycle Processes, for managing software life cycle activities in both the quality domain and the engineering domain.
Yes. This edition explicitly supersedes STANAG 4814, Edition 1, dated 23 February 2018. The replacement changed the document's type as well as its edition: the earlier version was a binding agreement nations ratified, and the current one is a recommendation.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
A 90-day plan for the smallest defence suppliers: let the tender set your scope, document what you already do, fix the security basics primes check, and keep the system small enough for two people to maintain.
Learn how to qualify, approve and monitor sub-suppliers, flow down requirements through purchase orders, and keep the records an auditor will ask to see under ISO 9001 clause 8.4 and AQAP.
Learn how to run an ISO 9001 Clause 9.3 management review that turns evidence into decisions, with the right inputs, actionable outputs, and a cadence that fits your risks.