Platform
Modules
By sector
By sector
By standard
Blog
News
Events
ALP-20
Defence administrations and their industrial suppliers who produce, exchange and hold technical and logistic data across a system's support life cycle
NATO guidance recommending which data standards, chiefly the ASD S-series and the PLCS (ISO 10303-239) model, a defence programme should use to exchange technical and logistic data across a product's support life cycle.
ALP-20 is NATO's guidance on exchanging technical and logistic data during a defence product's life cycle support. ALP stands for Allied Logistics Publication, and this one is not itself a data-exchange specification: it surveys the standards already available for the job, chiefly the ASD/AIA "S-series" of Integrated Logistic Support specifications and the ISO 10303-239 (PLCS) data model, and sets out eighteen numbered recommendations on which to use, in what combination, and how to build the interfaces between them. Nations record their recommendation to use it in STANREC 4661, and it places itself inside the wider Integrated Logistic Support guidance set out in ALP-10 under STANAG 4728. Edition A, Version 1 was promulgated on 24 October 2023 and is effective upon receipt; the document does not present itself as superseding an earlier edition.
ALP-20's recommendations are pitched jointly at "Industry and Administrations." Industry produces the technical and logistic data and the IT systems behind it; Administrations, NATO agencies such as NSPA or national logistics authorities, own the Logistic Information System the data feeds into and manage the contracts that call up specific data standards. The document does not bind either side on its own. It binds through what a specific programme's contract, Business Rules or Guidance Document names, a particular ASD specification and issue, a particular exchange format, and it is that document, not ALP-20, that a supplier is actually measured against.
Technical and logistic data fall into two repositories. The initial data repository "allows the system to be taken into account before its use" and is built from ILS activities: the LSA DB, which initialises the maintenance plan and its procedures, and the Provisioning DB, which initialises the parts repository (the Initial Provisioning List). The in-service data repository "allows the tracking of the system during its utilization" and holds applicable and applied configurations, spare parts orders, and feedback. Together the two span the whole support life cycle: design and development, through to in-service maintenance.
The ASD/AIA S-series is the business layer. SX000i is the umbrella document for the whole Integrated Product Support scope; S1000D covers technical documentation; S2000M covers defence material management, provisioning and supply chain, run as electronic data interchange; S3000L covers Logistics Support Analysis and its LSA DB, replacing the older MIL-STD 1388-1A and 1388-2B; S4000P covers preventive maintenance; S5000F covers in-service feedback; S6000T covers training analysis and design. As of this edition's own reference table, the current issues range from S1000D 5.0 (June 2019) to most of the rest at their April 2021 "Block 2021" release, each applicable across land, air and sea domains without distinction.
Underneath the business layer sits PLCS (ISO 10303-239), identified in the document as the medium for conveying data between the S-series specifications. PLCS defines a generic, extensible data model for product maintenance information, specialised for a given exchange through a DEX (a Data EXchange specification both partners agree to before sharing data). PLCS carries its own NATO cover, STANAG 4661, ratified nation by nation (France's ratification dates to 12 January 2010); this is a separate agreement from ALP-20's own recommending document, STANREC 4661, and the two share only their number. Complementary data-quality standards round this out: ISO 8000, which scores how completely a data exchange meets its requirements, and ISO 22745, a language-neutral dictionary for mapping data attributes between systems that use different terms for the same thing.
ALP-20's eighteen numbered recommendations (Chapter 4) group into a few themes rather than a checklist of clauses. Which specifications to prioritise: S1000D, S2000M, S3000L and S5000F as mature, with SX000i, S4000P and S6000T added as needed. How to interface them: the ASD Common Data Model in the short to medium term, adding PLCS once its mappings mature. Governance around any implementation: a controlled Guidance Document or Business Rules document for each specification used, its issue fixed before use for tool compatibility, and no unnecessary multiplication of software tools implementing the same specification. Architecture: moving from point-to-point interfaces, ten of them to connect just five "business" databases in the document's own worked example, to a centralised database built on one common breakdown structure. And, longer-term, treating generic interface development as its own project with industrial partners, pooling project teams across implementations, staying engaged in the S-series and PLCS working groups, and running an ILS Interoperability Forum to demonstrate interoperability through published test cases.
PLCS's own functional scope excludes the representation of financial transactions for orders, purchases or the return of a product, and financial transactions related to its transport, shipping and receipt. A reader assuming this data model captures cost data end to end will not find it here; that stays with whatever ERP or financial system a programme already runs.
No accreditation or certification scheme evaluates conformance to ALP-20 itself, and the document describes none. What actually gets checked is delivered data against the Guidance Document or Business Rules a programme has agreed for whichever specification it invoked, "each ASD specification must be the subject of an application document ... which allows the different partners to have a common vision regarding the implementation modalities of the specification." That check runs between the partners, typically the receiving administration accepting the data, and not through a third-party audit. NSPA's own practice illustrates this concretely: its Business Rules name a specific development specification, a data exchange format, a list of data entities and its own "Technical Documentation Validation and Verification" step, S1000D's own second verification pass for military projects. Where the question is interoperability across systems rather than a single delivery, the document recommends demonstrating it through published data-exchange test cases in an ILS Interoperability Forum run jointly by end-users and IT vendors.
NATO publishes ALP-20 through the NATO Standardization Document Database at no charge. ComplyTrain does not sell it or host a copy; the NSDD listing for ALP-20 is the source.
ALP-20 is a data-exchange and interoperability guidance document, not a quality management standard a company implements a management system against, so there is no product mapping to claim here. The work it actually describes, building the interfaces, choosing and version-locking specification issues, running S-series/PLCS mappings, standing up an LSA DB or a PLCS-based platform, is systems-engineering and PLM/IT work carried out in specialised logistics-data tooling, not in a compliance platform.
What a supplier or administration needs to evidence its part is disciplined document control around that engineering: a controlled Guidance Document or set of Business Rules for each specification a programme has invoked, version records showing which issue of S1000D, S2000M, S3000L or PLCS a contract was built against, training records for the people who maintain the interfaces, and a defensible audit trail of validation and verification work of the kind NSPA runs against its own S1000D deliveries. ComplyTrain supports exactly that kind of record-keeping in general, as an auditable quality management system: controlled documents, training records, and traceable evidence a customer or reviewing administration can inspect.
ComplyTrain does not build data exchange interfaces, host a PLCS database, generate S1000D data modules or S2000M EDI messages, or map data models between the ASD specifications and PLCS; that stays with the engineering and PLM tooling ALP-20 itself describes. Which data standards and issue levels a given programme calls up is set by its contract and the customer's own quality clause, not by us. See the standards explorer for what sits alongside ALP-20 in your programme, and talk to us about the documentation and training side of evidencing that work.
Tell us how you need to work with ALP-20 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, not on its own. ALP-20 is recommended for use through STANREC 4661, a recommendation rather than a ratified obligation. Whether any of it binds a particular supplier depends on whether a specific tender, contract, or Business Rules/Guidance Document requires deliverables to follow a named ASD specification or PLCS edition, not on ALP-20 existing.
They are two different NATO agreements that happen to share a number. STANREC 4661 records nations' recommendation to use ALP-20 itself. STANAG 4661 is the separate agreement, ratified nation by nation, that covers the PLCS standard (ISO 10303-239). Reading one for the other is an easy mistake given the shared number, but they cover different documents.
The ASD S-series is a family of Integrated Logistic Support specifications developed by the aerospace and defence industry associations ASD, AIA and ATA: SX000i as the umbrella document, S1000D for documentation, S2000M for material management, S3000L for logistics support analysis, S4000P for preventive maintenance, S5000F for feedback, and S6000T for training. ALP-20 recommends the mature ones, S1000D, S2000M, S3000L and S5000F, as the priority.
No. ALP-20 does not define its own data model or exchange format; it recommends which existing specifications, chiefly the ASD S-series and PLCS, a programme should use and how to combine them, and it points to the Guidance Document or Business Rules process that turns that recommendation into something implementable on a specific programme.
NATO publishes it free of charge through the NATO Standardization Document Database. ComplyTrain does not sell or host copies of NATO documents.
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.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.