ISO 42001 or NIST AI RMF: where should a Thai company start?

Picture this: a Thai software firm receives a supplier questionnaire from a European customer with a box that reads "Which AI governance framework does your organisation apply?" and two examples next to it: ISO/IEC 42001 and the NIST AI RMF.

The person who has to answer is usually the DPO or the IT lead who already runs PDPA compliance. They are not sure whether both are needed, whether a consultant is required, or whether writing "aligned" is enough. This article compares the two point by point, using the standards index in our knowledge base and the AIPDPA team's notes on the foreign guidance it has read.

How do ISO 42001 and the NIST AI RMF differ?

Mainly in status. ISO/IEC 42001 is a management system standard that an independent auditor can certify. The NIST AI RMF is a framework published by the US National Institute of Standards and Technology for voluntary use; there is no certificate, and an organisation may pick only some of its outcomes.

Their shape differs too. ISO 42001 uses the same skeleton as ISO 9001 and ISO/IEC 27001, clauses 4–10 on a Plan-Do-Check-Act cycle, plus an Annex A of 38 controls. NIST is written as 72 outcomes grouped into four functions, GOVERN, MAP, MEASURE and MANAGE, and never says what your documents should look like.

The table is adapted from the AIPDPA team's application guide (see the ISO 42001 starter guide). It is a team note, not ISO or NIST text. The column to remember is the last one, because it is the only one with legal consequences.

What does ISO 42001 require that NIST does not?

ISO 42001 wants documents an auditor can pick up. The team's notes single out three as the core of a certification audit: an AI policy approved by top management (clause 5.2), a Statement of Applicability (SoA) explaining which Annex A controls were chosen or excluded and why, and an AI system impact assessment covering individuals and society.

ISO text is copyrighted and sold, so our knowledge base holds only clause numbers and titles. Below are the titles from the planning clause, where both risk assessment and impact assessment sit.

NIST never names a document. It states the outcome. The clearest example is the AI inventory: GOVERN 1.6 says there must be a mechanism to inventory AI systems, resourced according to the organisation's risk priorities.

In practice an ISO organisation ends up with an auditable stack of documents, while a NIST organisation ends up knowing what to control but has to design its own evidence. The team's notes warn that announcing "we follow the AI RMF" without saying which outcomes means little and may overstate the position.

Does a company that only buys AI have to do every control?

No, and this is where most wasted effort happens. Both frameworks are written for those who build models and those who deploy them. Most Thai organisations sit on the deploying side: they buy ChatGPT, Copilot or a CV-screening tool from a vendor.

ISO: put the reasoning in the SoA

According to the team's notes, about half of section A.6 (system life cycle) and nearly all of A.7 (data for AI systems) is model-developer work that a deployer cannot do. The right place to say so is the SoA: "not applicable, we deploy and do not develop models". The foreign guides the team read agree that auditors accept this when the reasoning is clear.

• Clearly yours: A.2 AI policy · A.3 roles and reporting of concerns · A.4 resource and system inventory · A.5 impact assessment · A.8 user information and incident communication · A.9 responsible use and human oversight · A.10 third parties
• Usually excludable: the design-and-build parts of A.6.1–A.6.2 · A.7 acquisition and preparation of training data
• Watch out: if you fine-tune a model on your own data or build your own RAG system, parts of A.7 apply to you again

NIST: start with twelve outcomes

NIST itself says organisations may select among categories according to their resources. The AIPDPA team picked the twelve outcomes with the best return for an organisation that deploys other people's AI and already has a PDPA function. The order below is the team's view, not a NIST ranking.

1. GOVERN 2.1 name an owner for AI; the DPO can hold it for now
2. GOVERN 1.6 keep an AI inventory, one line per system
3. GOVERN 1.3 define three risk tiers with criteria
4. GOVERN 1.2 a one-page AI use policy (GenAI policy guide)
5. GOVERN 6.1 procurement criteria and vendor contract clauses
6. GOVERN 3.2 write down who may override an AI result
7. GOVERN 4.3 define an AI incident and plug it into the existing breach plan
8. MAP 3.2 ask who could be harmed, how, when and by what
9. MEASURE 2.8 log usage and human overrides
10. MEASURE 3.3 open an appeal route and count its use
11. MANAGE 2.4 write shutdown criteria in advance
12. MANAGE 4.3 keep incident and change registers

The team observes that none of the twelve requires buying a tool; they are documents, contracts and settings you already have. The hardest is number five, because it means negotiating with a vendor, and it has to happen before signing.

Do both frameworks say the same thing about AI vendors?

They do, and this is where the frameworks and Thai law line up most clearly. NIST gives a whole category, GOVERN 6, to third-party risk, including the risk of infringing someone else's intellectual property.

ISO gives the same topic a whole section, A.10, on allocating responsibilities, suppliers and customers.

For a Thai organisation, A.10 and GOVERN 6 end in a single document: the agreement with the vendor. Where an AI vendor processes personal data on your behalf, section 40 paragraph three of the PDPA already requires the data controller to put an agreement in place. Here the international frameworks and Thai law ask for the same thing.

One agreement therefore does three jobs: it meets section 40, it is your A.10 evidence, and it answers GOVERN 6.1. The AI-specific clauses worth adding are covered in what to ask your AI vendor.

When is ISO 42001 certification worth it?

Short answer: when someone outside asks for it. The team's notes conclude that a Thai organisation should certify when foreign customers or partners start asking, especially those under the EU AI Act, when it provides AI to others, or when a sector regulator begins citing international standards.

On time and money, the team's notes cite a US consultancy (rhymetec, 2024) estimating six to eleven months or more without outside help. The team itself flags these as US market figures from a firm selling the service: fine for an order of magnitude, not for a plan. Thai prices need quotes from certification bodies operating in Thailand.

Why add NIST even after choosing ISO?

Because ISO answers who is accountable and when things are reviewed, but says little about what to measure. NIST has a whole MEASURE function on testing reliability, safety, privacy and bias. Fairness is a good example.

The PDPA does not tell you to measure bias in a system that decides about people, and NIST fills that gap. One caution: collecting religion, ethnicity or disability data to test for bias means handling sensitive personal data, which needs a lawful basis first. Good intentions are not a lawful basis.

The team's recommended path therefore has three layers: the PDPA as the base because it already binds you, the ISO 42001 structure as the backbone for documents and review cycles, and NIST to specify what each control measures. The team's guide maps the two frameworks almost one to one, for example ISO A.4 to GOVERN 1.6, and ISO A.10 to GOVERN 6, MAP 4 and MANAGE 3.

Common mistakes

• Using an internet translation instead of the standard. Translations remain under ISO copyright, are fine for understanding but useless before an auditor, and the one the team reviewed contains at least one error.
• Sending all 72 NIST outcomes to a vendor as a questionnaire and filing it. Nobody reads it. Twelve outcomes actually implemented are worth more.
• Relabelling a DPIA as an AI system impact assessment. A DPIA is a good base, but you must add societal impact and foreseeable misuse.
• Assessing once at go-live. Both frameworks expect repeat cycles and a fresh look whenever the model or vendor changes.
• Treating every AI incident as a data breach. A system that answers wrongly or shows bias without leaking data does not trigger notification to the PDPC Office, but it still needs logging and fixing.

The overlap between the two frameworks and the PDPA can live in one system. AIPDPA has an AI registry and an AI Risk Radar that lays Thai law, the NIST AI RMF and ISO 42001 side by side. You can also run the free AI risk check first. If you sell into Europe, continue with the EU AI Act for Thai businesses.

Who stands behind this guide?

Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel

Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)