Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AMSP-02
A defence organisation or contractor acting as a Customer, Provider or Supplier of Modelling and Simulation as a Service under NATO's Allied Framework
AMSP-02 sets out NATO's Allied Framework for Modelling and Simulation as a Service, defining stakeholder roles and the service-agreement, security and compliance-testing policies that govern shared M&S services.
AMSP-02 is the NATO Allied Modelling and Simulation Publication that sets out the Allied Framework for Modelling and Simulation as a Service (MSaaS): a common approach for NATO and Nations to share modelling and simulation capability as a discoverable, composable service rather than as stand-alone tools each organisation builds separately. It is a concept of employment, not a technical specification - it defines who is involved and how they relate, and leaves the architecture itself to a companion Technical Reference Architecture it points to.
The document is explicit about how it binds: its own procedures "are not formally mandated by NATO, unless supported by a specific NATO Standardization Agreement (STANAG)", and it is instead covered by a Standardization Recommendation, STANREC 4794, so nations are invited to apply it rather than committed to it by ratification. For a Supplier or Provider, what matters in practice is a procurement, licence agreement or programme that has adopted the Allied Framework and makes its policies a condition of participation.
AMSP-02 organises everything around four stakeholder roles. The Customer is "a defense organization with an operational need (e.g., training, mission planning, acquisition), and is the budget holder". The Provider makes M&S products and services available to Users "in accordance with Customer SLAs" and has to "manage and maintain a core set of secure M&S services" to meet them. The User consumes those services and "is responsible for providing data and feedback on performance and functionality". The Supplier "develop[s] and provide[s] M&S products", reaching a Provider "via a product procurement or license agreement" - examples given include large defence contractors, small and medium enterprises, academic institutions and government organisations. Readers commonly collapse Provider and Supplier into one role; the document treats them as distinct, with the Provider carrying the SLA relationship with the Customer and the Supplier one step further back in the chain.
An MSaaS implementation has to align with AMSP-01, NATO's M&S Standards Profile, and comply with the MSaaS Technical Reference Architecture, which is where the actual technical rules live - AMSP-02's own Technical Policies section states simply "None", deferring entirely to that companion document.
The organisational policies are where the substance sits. Every M&S capability has to be defined and provided as a service, and a Service Level Agreement has to be agreed between provider and customer "prior to service usage", documented against the template in Annex A. Each service needs a Service Description Template entry held in a discoverable, machine-readable registry reachable through an MSaaS Portal, and each provider has to declare a forecasted end-of-life date for every version of a service as part of its metadata. Each implementation also has to define its own business model, covering value proposition, stakeholder segments, key partners and activities, cost structure and revenue streams.
Security policy requires providers to address risk management, account management, authentication and authorisation, monitoring, physical security and data handling, and to keep data within a security domain at one classification level, re-classifying if combining it raises that level. One security clause is easy to misread: it requires that "products and services developed by industry SHALL provide the required nation certifications as fit for use" - a national certification a country's own regime demands, not a NATO or AMSP-02 certification, which the document neither creates nor administers.
AMSP-02 sets no certification scheme of its own. Compliance testing of individual M&S services "is the ultimate responsibility of the participating organizations", with NMSG "provid[ing] oversight of the Compliance Testing service" rather than running an audit or issuing a certificate. Integration, verification and compliance testing follow "existing STANAG/STANRECs" rather than AMSP-02 itself - the document cites STANREC 4800, which covers AMSP-04's federation architecture, as the kind of instrument this testing actually runs against. NMSG itself is "the delegated NATO tasking authority for M&S standards", with the Modelling and Simulation Standards Subgroup (MS3) as permanent custodian of the technical standards and the Military Operational Requirements Subgroup (MORS) responsible for identifying operational needs.
AMSP-02 is covered by STANREC 4794, the recommendation that lets NATO nations apply it without a STANAG's ratification obligation. It requires alignment with AMSP-01, the NATO M&S Standards Profile that carries the recommended M&S standards and STANAGs/STANRECs AMSP-02 itself does not list. Its compliance-testing clause points, by example, to STANREC 4800, which covers AMSP-04's federation architecture and federation object model. It also names AMSP-03, NATO's Reference Architecture for Distributed Synthetic Training, as a document NMSG should review alongside AMSP-02 for possible integration, without requiring it directly.
AMSP-02 describes an operational and organisational framework, not a management system implemented in software: agreeing an SLA, describing and registering a service, documenting security practice and declaring an end-of-life date are things an organisation does in how it runs its MSaaS relationships, not inside a compliance tool. What ComplyTrain supports is the evidence trail around that work - a controlled place to hold the SLA and its change history, the Service Description Template entries, the security-practice documentation a provider has to produce on request, and the training records showing the people filling the Customer, Provider, User and Supplier roles understand what each is accountable for.
What ComplyTrain does not do: it does not run the MSaaS service itself, perform NMSG's compliance-testing oversight, design the technical architecture the Technical Reference Architecture governs, or decide which security controls a given implementation needs.
Which parts of the Allied Framework for MSaaS actually apply to a given programme is set by the contract or programme that adopted it, not by us. See what else sits alongside AMSP-02 in the standards explorer, and talk to us about the documentation trail behind an MSaaS service.
Tell us how you need to work with AMSP-02 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. AMSP-02's own procedures "are not formally mandated by NATO, unless supported by a specific NATO Standardization Agreement (STANAG)". It is covered instead by STANREC 4794, a recommendation that nations are invited to apply, not a ratified obligation. A supplier meets it only where a procurement, licence or programme requires it.
A Supplier develops and provides M&S products, reaching a Provider through a procurement or licence agreement. A Provider takes those products and integrates them into services it makes available to Users under a Service Level Agreement with a Customer. The document treats them as separate roles even though one organisation can sometimes fill both.
No. AMSP-02 describes no certification scheme. Compliance testing of an M&S service is the responsibility of the organisation providing it, with NMSG holding oversight rather than issuing any certificate.
No. Its Technical Policies section states plainly "None". The technical architecture, including interfaces and security controls for specific data flows, is covered by the separate MSaaS Technical Reference Architecture, which AMSP-02 requires an implementation to comply with.
A Service Level Agreement agreed between the provider and customer "prior to service usage", a Service Description Template entry registered so the service is discoverable through an MSaaS Portal, and documented security practices the provider can produce on request.
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.