Platform
Modules
By sector
By sector
By standard
Blog
News
Events
ADatP-5636
Designers of NATO information and communication systems, and the Communities of Interest that extend the specification with their own metadata elements
ADatP-5636 (the NCMS) sets out the core metadata elements a NATO information system attaches to a resource, covering confidentiality labelling, descriptive data and lifecycle information, so it can be found and handled consistently across the Alliance.
ADatP-5636 is the NATO Core Metadata Specification (NCMS): the Allied Data Publication that defines the set of metadata elements NATO expects to travel with an information resource, so that whoever encounters it later can find it, understand its sensitivity, and handle it consistently across the Alliance's information and communication systems. It is one of three companion publications that together make up NATO's metadata infrastructure - ADatP-4774 supplies the confidentiality label syntax, ADatP-4778 supplies the mechanism for actually binding metadata to a data object, and ADatP-5636 supplies the core set of elements those two mechanisms carry. It is a technical data specification, not a management system or a quality clause: it addresses whoever is designing or building a NATO information system, and any Community of Interest (COI) that needs to extend the core set with its own metadata.
The specification arranges its elements into three layers. The Security Layer carries the confidentiality labels: originatorConfidentialityLabel and metadataConfidentialityLabel are mandatory, alternativeConfidentialityLabel is optional, and all three are built on STANAG 4774. The Common Layer is "primarily based on the elements defined in ISO 15836:2009 as the Dublin Core Metadata Element Set" and carries the bulk of the specification: groups for Coverage, Date, Description, Format, Identifier, Relation, Rights, Subject and Title, plus standalone elements including contributor, creator, custodian, language, contextActivity, provenance, publisher, source and type. The Information Lifecycle Support Layer carries recordsDisposition, recordsHold, status, updatingFrequency and version, all optional, for the tasks of retention, disposition and status tracking.
Only seven elements are mandatory on every resource (Annex A.1): originatorConfidentialityLabel and metadataConfidentialityLabel from the Security Layer, and creator, dateCreated, identifier, publisher and title from the Common Layer. Of those, creator and publisher carry organisational roles - creator is "An entity primarily responsible for creating the resource", publisher "The entity responsible for making the resource officially available" - and each resource has exactly one of each. Everything else is optional, or conditional on another element being used: geographicEncodingScheme is mandatory only if geographicReference is present and prohibited otherwise, dateCopyrighted only applies if copyright is used, extentQualifier only if extent is used, and reasonForRedaction only if a redaction relation is used.
Composite values follow their own structure. A confidentiality label follows STANAG 4774. A point of contact - used for creator, publisher, custodian, contributor and rightsHolder alike - carries six sub-elements (type, name, affiliation, address, email, phone), of which "only type and name are mandatory"; the other four are prohibited outright when the type is "service" rather than a person or organisation. A time interval follows an optional start, end, name and scheme.
One modelling detail is easy to miss: metadataConfidentialityLabel, the label on the metadata set itself rather than on the resource, has no XML element of its own. It is implemented instead by binding an originatorConfidentialityLabel element to the metadata - an implementer looking for a dedicated tag for it will not find one.
The NCMS is deliberately a core set, not an exhaustive one, and a Community of Interest with its own metadata needs works through a fixed order of preference: reuse an existing NCMS element; reuse an existing Dublin Core term; define a COI-specific syntax encoding of an existing element only if the existing encoding is not detailed enough; define an entirely new COI-specific element only if nothing existing fits; or reuse an already-established COI-specific XML element unchanged. "All newly developed COI metadata specifications shall follow" the pattern of reusing the NCMS core and adding only what is genuinely COI-specific - the order matters most while a system's data model is still being designed, since retrofitting it after interfaces and stored metadata are fixed is far more expensive.
ADatP-5636 carries the technical content; it acquires force through STANAG 5636, the agreement NATO nations ratify, and it reaches a system builder only when a contract, a national authority or an internal NATO programme invokes it for a particular system - not because the document exists. Annex C gives the normative XML schema, in the urn:nato:stanag:5636:A:1:elements namespace, and metadata elements are attached to a data object using the STANAG 4778 binding mechanism: "NCMS metadata elements SHALL be bound to data objects in accordance with STANAG 4778", either embedded directly or referenced from elsewhere.
There is no accredited or government body that assesses conformance with ADatP-5636, and no certificate to hold. What the specification asks of an implementation is that it "contain the mandatory elements to ensure the interoperability of metadata based on the specification"; structural conformance is what the normative XML schema validates, while values drawn from a controlled code list are a separate matter the schema does not check on its own and would need something like Schematron rules to catch.
Building or configuring a NATO information system to produce, carry and validate its NCMS metadata elements is systems and software engineering work, done in the information system itself, not something a compliance platform performs. What ComplyTrain supports is the evidence trail around that engineering work: a controlled place to document which optional elements an organisation has chosen to populate and why, how a Community of Interest justified a COI-specific syntax encoding rather than reusing an existing element, and what its information-lifecycle retention and disposition practice actually is - the kind of documented, auditable record any operational standard needs behind it, held as controlled procedures, decision records and training material rather than scattered across individual system builds.
What ComplyTrain does not do: it does not define, validate or host an NCMS-conformant XML schema, does not bind metadata to a data object, and takes no part in the systems-engineering decisions the specification sets out for extending the core element set. Which standards apply to a given NATO information system, and to what tier, is set by the contract and the customer's quality clause, not by us. See what else sits alongside ADatP-5636 in the standards explorer, and talk to us about the documentation trail behind adopting it.
Tell us how you need to work with ADatP-5636 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.
ADatP-5636 itself is technical content, not a contractual obligation. It acquires force through STANAG 5636, which NATO nations ratify, and it reaches a system builder only when a contract, a national authority or an internal NATO programme requires that system to use the NCMS - not simply because the document has been published.
They are three parts of the same metadata infrastructure. ADatP-5636 defines the core metadata elements themselves. ADatP-4774 defines the confidentiality label syntax those elements' Security Layer uses. ADatP-4778 defines the mechanism for binding any of these metadata elements to an actual data object.
Seven, out of the much larger set Annex A lists across the specification: two confidentiality labels (originatorConfidentialityLabel and metadataConfidentialityLabel), plus creator, dateCreated, identifier, publisher and title. Everything else is optional, or required only when a related element is present.
Yes, and the specification sets out a preferred order for doing it: reuse an existing NCMS element first, then an existing Dublin Core term, then a COI-specific encoding of an existing element, and only then a genuinely new COI-specific element.
No. The specification names no accredited body, notified body or government surveillance scheme that assesses an implementation against it. Conformance is a property of the implementation itself - whether it carries the mandatory elements in the defined syntax - checked by XML schema validation and, for controlled code-list values, by additional mechanisms such as Schematron rules.
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.