ADatP-34 (NISP): NATO Interoperability Standards and Profiles, explained

ADatP-34 is the document number of the NATO Interoperability Standards and Profiles (NISP) — the Alliance's master catalogue of the technical standards and interoperability profiles that communications and information systems must use to interoperate. It is not a message catalogue and not a data-link standard: it is the three-volume reference that tells a programme which standards to implement, in which edition, and how strongly each one binds. If you were looking for NATO message formats, those live in ADatP-3 (STANAG 5500) and APP-11 — ADatP-34 tells you which edition of them to build against.

What ADatP-34 is: the NATO Interoperability Standards and Profiles

Formally, ADatP-34 is an Allied Data Publication whose content is the NISP. It prescribes the technical standards and profiles needed to achieve interoperability of Communications and Information Systems (CIS) in support of NATO's missions and operations, and gives guidance to the three roles that live off it daily: capability planners, programme managers and test managers. The current publicly released edition is ADatP-34 Edition N Version 2 (NISP version 15, 18 August 2023), noted by the NATO C3 Board and released as a replacement for Edition N Version 1 (NISP v14, 2021).

The NISP grew out of the NATO C3 Technical Architecture (NC3TA), whose last version was completed in 2005-2006; the first NISP followed in December 2006 and the document has been revised on a roughly annual cycle ever since. Where the NC3TA was an architecture document, the NISP is a catalogue with legal teeth: per the Alliance C3 Strategy, all NATO Enterprise entities adhere to the mandatory standards and profiles in its Volume 2, and those standards are binding for NATO common-funded systems (see NATO interoperability standards for software for the wider STANAG/APP landscape).

The NISP is published as three volumes in HTML and PDF, backed by a searchable standards database and an ArchiMate-format data export for architecture tools. The database behind the 2023 edition holds roughly 1,280 standards from some 70 organisations — IETF RFCs, W3C, OASIS, OGC and ISO specifications alongside NATO STANAGs and Allied Publications — plus about 400 service profiles. Most of it is not NATO-written: the NISP adopts mature non-NATO standards and binds them into NATO profiles.

Who maintains ADatP-34: the C3 Board, the IP CaT and STANAG 5524

The NISP is developed by the Interoperability Profiles Capability Team (IP CaT) under the authority of the NATO Consultation, Command and Control Board (C3B) — the senior multinational committee for NATO C3 and interoperability policy. In December 2023 the North Atlantic Council approved the renaming of the C3 Board to the Digital Policy Committee (DPC), and the interoperability profiles team continues under that committee; in current NATO listings it appears as the DPC's interoperability standards and profiles team (the NISP database records it as "DPC IP iCaT"). Early editions of the NISP were produced by the NATO Open Systems Working Group before the work moved to the dedicated capability team.

The maintenance rhythm is annual and predictable, which matters for roadmapping:

• Anyone — a nation, a NATO body, a programme — submits a Request for Change (RFC) to the IP CaT.
• RFCs received by 1 September are targeted at the next release; the IP CaT reviews them in dialogue with the responsible standardization bodies.
• The new version is submitted to the C3 Board (now DPC) by the end of the year after internal review.
• Once approved, the NISP becomes the NATO standard covered by STANAG 5524, which records the participating nations' agreement to use its mandatory standards and profiles.

The IP CaT's live database — not the once-a-year PDF — is the definitive source for the current status of any standard or profile, with draft editions updated continuously between official releases.

NISP volumes: what Volume 1, 2 and 3 contain

Since the mid-2010s the NISP has settled into a stable three-volume structure (older editions were carved differently — near-term/long-term standards, profiles and design rules in separate volumes). Each volume has a distinct job:

• Volume 1 — Introduction. Basic concepts (what a standard is in NISP terms, what a profile is), the management and configuration-control framework, the RFC process, and the profile-development guidance in its appendix. Read it once; it is short and it defines the vocabulary the other volumes assume.
• Volume 2 — Agreed Interoperability Standards and Profiles. The normative core: the standards and profiles that are mandatory for NATO common-funded systems, organised against the NATO C3 Taxonomy (baseline 5.0) under headings like User Applications, COI Services, Core Services and Communications Services. It also carries the agreed profiles, including the Federated Mission Networking (FMN) Spiral 3 and Spiral 4 profiles and several dozen service interface profiles.
• Volume 3 — Candidate Interoperability Standards and Profiles. Informative guidance: standards and profiles that are mature enough to plan against for programmes starting in the next one to two years, but not yet mandatory.

Volume 2 is normative for NATO common-funded systems; Volume 3 is informative. That single sentence is the most common thing procurement documents get subtly wrong.

Mandatory vs candidate: the categories that decide what you must build

The NISP assigns every listed standard and profile an obligation status with a precise meaning:

• Mandatory (Volume 2) — application of the standard or profile is enforced for NATO common-funded systems in planning, implementation and testing. Nations are required to use the NISP when developing capabilities that support NATO's missions, and are invited to apply the same rules nationally.
• Candidate (Volume 3) — the standard or profile may be used for testing and programme planning only. It must be sufficiently mature and is expected to become mandatory in the foreseeable future; the NISP's own rule of thumb is that a candidate should not sit in Volume 3 for more than three years.

Two further distinctions stop teams misreading the catalogue. First, obligation is not the same as lifecycle: a standard's own maturity (study/in ratification, promulgated, superseded — or, for non-NATO standards, emerging/mature/fading/obsolete) is tracked by its developing body, and for NATO standards the authoritative status and national reservations live in the NATO Standardization Office's database, not in the NISP. Second, applicability is not conformance: the NISP's Basic Standards Profile associates standards with elements of the C3 Taxonomy, but if a standard applies to a service you implement, the degree of conformance is judged in your project's context — the NISP itself notes that exchanging data between C2 and logistics systems may need only a subset of JC3IEDM (STANAG 5525) concepts.

For non-NATO standards the IP CaT applies explicit adoption criteria — cross-vendor implementations, consensus development, freedom from IP encumbrances, openness, stability and testability — and one conflict rule worth remembering: where an adopted non-NATO standard conflicts with a relevant NATO standard, the NATO definition prevails.

Interoperability profiles, SIOPs and how FMN spirals use the NISP

Standards alone do not interoperate — profiles do. In NISP terms, profiles define the specific use of standards at a Service Interoperability Point (SIOP), a reference point in an architecture where one or more service interfaces are instantiated so that systems delivering the same service over different protocols can interoperate. The detailed technical specification of a SIOP lives in a service interface profile (SIP). A profile identifies its capability requirements and supporting NAF architectural views, the characteristic protocols, implementation options, the technical standards, the SIOPs, and its relationships to other profiles — and profiles may reference other profiles to maximise reuse.

Profiles are explicitly dynamic: they must be updated when a standard they reference changes, and profile owners are required to review them every two years. This is where the NISP meets Federated Mission Networking. Each FMN Spiral Specification bundles architecture, instructions, profiles and requirements for a federation increment, and the NISP is where those profiles become visible obligations: the FMN Spiral 3 and Spiral 4 profiles are listed as agreed profiles in Volume 2 of the 2023 edition, while the proposed FMN Spiral 5 profile sat in Volume 3 as a candidate. The FMN Management Group approved the final Spiral 6 specification in November 2025, and its profiles can be expected to enter the NISP the same way — agreed profiles in Volume 2 once adopted (see FMN Spiral 4 requirements for what a spiral's profile set looks like in practice).

The NISP also names the venues where profile conformance is proven: its own review criteria ask responsible parties whether issues with a standard were identified during test events such as CWIX and CIAV. If you are heading there, read the CWIX preparation guide in parallel — the exercise tests the profiles, not the PDF.

ADatP-34 vs ADatP-3 vs APP-11 vs APP-6 vs STANAG

These designations get crossed constantly in requirements documents, so here is the disambiguation table. The short version: ADatP-34 is the catalogue; ADatP-3 and APP-11 are the military-messaging pair it points to; APP-6 is symbology; STANAG is the ratification instrument. All four publications are themselves listed inside ADatP-34 Volume 2, with the exact edition NATO systems are bound to.

So there is no such thing as "an ADatP-34 message". The messages your gateway parses are ADatP-3/APP-11 message text, Link 16 J-series words (STANAG 5516 — see Link 16 and tactical data links), VMF, or a service payload like MIP4; the symbology your map renders is APP-6 (compared with its US twin in APP-6 vs MIL-STD-2525). ADatP-34's job is to say which edition of each of those is current and binding, in which profile combination, at which interface. For the ground-forces data model that plays the same role in the picture-exchange world, see MIP4-IES.

How a software team uses NISP: from profile to compliance matrix

In practice a C2 product team consumes the NISP in four moves, and the artefact they produce — a compliance matrix — is what evaluators, accreditation staff and CWIX planners will actually ask for:

1. Map your interfaces to SIOPs. Every external interface your product exposes or consumes (track exchange, formal messaging, chat, map services, security labelling) is a service interoperability point. Name them; they anchor everything that follows.
2. Look each one up in Volume 2. Find the C3 Taxonomy node for that service in the standards tables — each row gives the title, the publication number, the profiles the standard is used in, and the responsible party who advises NATO on it. If your programme targets an FMN federation, start from the FMN profile instead and take its standard list. Check Volume 3 for what will hit you mid-programme.
3. Build the matrix. Per SIOP, record the standard, the exact edition, your conformance scope (full or the subset the NISP allows you to justify), the obligation status and the evidence you will produce.
4. Prove it. Wire the matrix into your conformance test suite, then exercise it at a coalition test event. A matrix row without test evidence is a claim, not compliance.

A compliance matrix for a coalition C2 product against the 2023 edition looks something like this:

Version the matrix against the NISP edition it was built from, and re-baseline it each year — the annual release cadence means editions shift under long programmes. For the architecture views that accompany the matrix, the NISP's profile elements reference the NATO Architecture Framework (NAF 4), and for the information-model layer underneath MIP4, the NATO C2 Information Model.

Common mistakes engineers make with ADatP-34

• Parsing "ADatP-34 messages". There are none. The message content is ADatP-3/APP-11 (see the ADatP-3 / STANAG 5500 explainer) or a tactical data link; ADatP-34 only cites them. Building an "ADatP-34 parser" is a category error that has cost teams real months.
• Claiming unscoped "NISP compliance". Compliance is per SIOP, per profile, per edition. A bid that says "NISP-compliant" without the matrix reads as noise to an evaluator; a bid with a matrix does not.
• Implementing everything at full conformance — or skipping Volume 2 standards as optional. Applicability is not conformance (subsets can be justified), but mandatory means mandatory for NATO common-funded systems at the SIOPs.
• Building against a stale edition. Edition M, Edition N Ver 1 and Edition N Ver 2 differ in cited editions of the underlying standards; a matrix pinned to a superseded edition fails review. Track the annual release and the 1-September RFC cut-off.
• Ignoring Volume 3. Candidate standards are the ones that become mandatory mid-programme — the NISP expects candidates to move within about three years. Plan them into the roadmap, not the change request.
• Treating the NISP as a status register. Ratification state and national reservations for STANAGs live in the NATO Standardization Office's database; the NISP deliberately does not duplicate them.

Get these right and ADatP-34 stops being an opaque acronym and becomes what it was designed to be: the single checklist that turns "we interoperate with NATO" into a testable engineering statement.