# Agentic AI Governance Assessment: [Agentic system name]

> Governance assessment for an AI agent or multi-agent system, organised
> on the four dimensions of Singapore's Model AI Governance Framework
> for Agentic AI, published by the Infocomm Media Development Authority
> (IMDA). Version 1.0 was launched on 22 January 2026; this template
> follows Version 1.5 (published 20 May 2026, updated 5 June 2026). It
> records the agent's scope, the risk factors and bounds, human
> accountability and oversight, technical controls and processes across
> the lifecycle, end-user responsibility, evidence and an action plan.
> Replace every `[bracketed]` value and every row marked *Example*. The
> framework is voluntary guidance; this is a documentation format, not
> legal advice, and it is not an IMDA endorsement or certification.

<!--
Guidance: How to use this template
- Sections 3 to 6 follow the framework's four dimensions in order:
  2.1 assess and bound the risks upfront, 2.2 make humans meaningfully
  accountable, 2.3 implement technical controls and processes, and 2.4
  enable end-user responsibility. Keep the numbering mapping so a
  reviewer can trace each answer to the framework.
- Complete one assessment per agentic system (a single agent or a set
  of agents that work together on one business process). For a
  third-party agent platform, complete it as deployer and attach the
  supplier's evidence.
- Start before build. The framework treats use-case selection and
  bounding as the first control: some processes are better served by a
  deterministic workflow than by an agent.
- The framework is a living document. Download the current version
  from imda.gov.sg and check for updates before each review.
- Common pitfall: relying on instructions in the system prompt ("do not
  delete files") as the main safeguard. Prefer limits enforced by the
  system, such as tool permissions and approval gates.
-->

## Document control

<!-- Guidance: Name the accountable owner for the agent, not just the engineering team. The framework is explicit that the deploying organisation and its people remain accountable for what agents do. -->

| Field | Value |
|---|---|
| Document ID | [AGOV-SG-001] |
| Agentic system | [Name, version] |
| Agents in scope | [Agent IDs from the agent catalogue] |
| Business process | [Process the agents support] |
| Role in the value chain | [Deployer / System provider or app developer / Platform provider / Model developer / Several] |
| Accountable executive | [@exec-owner] |
| Assessment owner | [@assessment-lead] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Approvers / reviewers | [@security], [@risk], [@legal], [@dpo], [@product] |
| Framework version used | IMDA MGF for Agentic AI, Version 1.5 (20 May 2026, updated 5 June 2026) |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD or on a change trigger (section 5.5) |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Accountable executive | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Risk owner | [@name] | [Accept residual risk / Do not accept] | YYYY-MM-DD |
| Data protection officer | [@name] | [Opinion] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope and risk factors |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for pilot with internal users only |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Model update triggered full review; payment tool added behind approval gate |

## Contents

1. [Purpose and scope](#1-purpose-and-scope)
2. [Agent inventory and value chain](#2-agent-inventory-and-value-chain)
3. [Dimension 1: Assess and bound the risks upfront](#3-dimension-1-assess-and-bound-the-risks-upfront)
4. [Dimension 2: Make humans meaningfully accountable](#4-dimension-2-make-humans-meaningfully-accountable)
5. [Dimension 3: Implement technical controls and processes](#5-dimension-3-implement-technical-controls-and-processes)
6. [Dimension 4: Enable end-user responsibility](#6-dimension-4-enable-end-user-responsibility)
7. [Residual risk and decision](#7-residual-risk-and-decision)
8. [Evidence register](#8-evidence-register)
9. [Action plan](#9-action-plan)
10. [Cross-reference to other frameworks](#10-cross-reference-to-other-frameworks)
11. [Glossary and references](#11-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: Describe the goal the agents pursue, what they can change in the world, and who is affected. If you cannot say what the agent must never do, the scope is not yet clear enough to assess. -->

| Item | Description |
|---|---|
| Business goal | [Outcome the agentic system delivers] |
| Why an agent | [Why a deterministic workflow or a non-agentic model is not sufficient] |
| Users | [Internal staff / Customers / Other agents] |
| People affected | [Customers, counterparties, employees, the public] |
| Actions the agent may take | [Read, draft, send, buy, change records, run code] |
| Actions the agent must never take | [Explicit prohibited actions] |
| Deployment stage | [Concept / Pilot / Limited release / General availability] |
| Jurisdictions | [Singapore and others] |

*Example:* A procurement assistant reads purchase requests, checks them
against the purchasing policy, compares three approved suppliers through
their APIs and drafts a purchase order. It may place orders up to
SGD 2,000 after a human approval; it must never add a new supplier,
change bank details or approve its own request.

Record the alternatives you considered. The framework asks deployers to
weigh benefit against risk before choosing an agent, and some processes
with fixed steps are safer and cheaper as a deterministic workflow with
one model call. Write that comparison here so a reviewer can see the
choice was deliberate.

## 2. Agent inventory and value chain

<!-- Guidance: List every agent and every external party that contributes to the system. Accountability tends to diffuse when several suppliers are involved; this table is where you pin it down. -->

### 2.1 Agent inventory

| Agent ID | Purpose | Model | Tools and systems reachable | Memory | Acts as | Human owner |
|---|---|---|---|---|---|---|
| AGT-001 *(Example)* | Orchestrator for purchase requests | [Model, version] | Policy KB (read), AGT-002, AGT-003 | Session only | On behalf of requester | [@proc-lead] |
| AGT-002 *(Example)* | Supplier quote comparison | [Model, version] | Supplier APIs via MCP (read) | None | Independently, as service | [@proc-lead] |
| AGT-003 *(Example)* | Purchase order drafting and placement | [Model, version] | ERP purchase module (write, behind approval) | None | On behalf of requester | [@finance-ops] |
| AGT-00N | [Purpose] | [Model] | [Tools] | [Memory] | [Capacity] | [@name] |

### 2.2 Value chain and responsibilities

| Party | Role (framework value chain) | What they provide | Contractual responsibilities agreed | Evidence |
|---|---|---|---|---|
| [Model vendor] *(Example)* | Model developer | Foundation model | Usage policy, incident notification within [72 h] | EV-003 |
| [Agent platform] *(Example)* | Platform provider | Orchestration runtime, logging | Log retention, access control, security attestation | EV-004 |
| [Internal team] *(Example)* | System provider or app developer | Agent design, prompts, tool integration | Internal policy | EV-001 |
| [MCP server vendor] *(Example)* | Tooling provider | Supplier API connector | Change notification, vulnerability disclosure | EV-005 |
| [Business unit] *(Example)* | Deployer | Use in procurement | Owns outcomes and user training | EV-002 |

Where a supplier's agent is opaque (you cannot see its reasoning,
logs or tool calls), record what visibility you negotiated and what
compensating controls you apply.

## 3. Dimension 1: Assess and bound the risks upfront

<!-- Guidance: Framework section 2.1. First rate the use case on factors that drive impact and likelihood, then bound the risk by design: limits on tools, autonomy and blast radius, plus identity and permissions for each agent. -->

### 3.1 Risk factors

Rate each factor Low, Medium or High with a one-line reason. The
framework separates factors that raise the severity of a failure from
those that raise its likelihood; version 1.5 also asks you to weigh
system complexity and reliance on third-party solutions.

| Factor | Drives | Rating | Reason |
|---|---|---|---|
| Error tolerance of the domain and criticality of processes supported | Impact | [H/M/L] | *Example:* Medium, financial commitments up to SGD 2,000 |
| Access to sensitive or personal data, including persistence in memory | Impact | [H/M/L] | *Example:* Low, no personal data beyond requester name |
| Access to external systems | Impact and likelihood | [H/M/L] | *Example:* High, supplier APIs outside our control |
| Breadth of actions (read only or write, few tools or open-ended tools) | Impact | [H/M/L] | *Example:* Medium, one write action |
| Reversibility of actions | Impact | [H/M/L] | *Example:* Medium, orders can be cancelled within 24 hours |
| Level of autonomy (fixed procedure or self-directed) | Likelihood | [H/M/L] | *Example:* Low, follows a defined procedure |
| Task complexity (number of steps, judgement needed) | Likelihood | [H/M/L] | *Example:* Medium |
| System complexity, including multi-agent interaction | Likelihood | [H/M/L] | *Example:* Medium, three agents |
| Use of third-party agents, platforms or tools | Likelihood | [H/M/L] | *Example:* High, external MCP server |
| Feasibility of human review at each step | Oversight | [H/M/L] | *Example:* Feasible at order placement only |

Overall inherent rating: [High / Medium / Low], justified in two
sentences.

### 3.2 Limits by design

| ID | Limit | Type | How enforced | Evidence |
|---|---|---|---|---|
| AGOV-LIM-001 *(Example)* | Least-privilege tools: AGT-002 read only on supplier APIs | Access | Tool gateway policy, not prompt | EV-006 |
| AGOV-LIM-002 *(Example)* | Agent follows the purchasing procedure as a fixed workflow | Autonomy | Orchestration graph with fixed steps | EV-007 |
| AGOV-LIM-003 *(Example)* | Order value cap SGD 2,000 per order and SGD 10,000 per day | Blast radius | ERP rule outside the agent | EV-008 |
| AGOV-LIM-004 *(Example)* | Kill switch disables all agent credentials within 5 minutes | Blast radius | Identity provider runbook, tested quarterly | EV-009 |
| AGOV-LIM-005 *(Example)* | Code execution, if any, only in an isolated sandbox without network | Blast radius | Container policy | EV-010 |
| AGOV-LIM-00N | [Limit] | [Type] | [Mechanism] | [EV] |

Prefer deterministic limits enforced by the system. Where a limit
depends on model behaviour, add monitoring or a human check on top and
record that here.

### 3.3 Agent identity and authorisation

| Practice | Status | Implementation |
|---|---|---|
| Each agent has its own unique, verifiable identity | [Yes / Partial / No] | *Example:* Workload identity per agent in [IdP] |
| Each identity is linked to an accountable human, supervising agent or department | [ ] | [How] |
| The capacity in which the agent acts (on its own or for a named user) is recorded | [ ] | [How] |
| Identities and permissions are issued and tracked centrally, and unused ones removed | [ ] | [Catalogue location] |
| Permissions are scoped, time or session bound and not transferable | [ ] | [How] |
| A delegated agent never receives more rights than the delegating human has | [ ] | [How checked] |
| Delegations of authority are logged | [ ] | [Log location] |

## 4. Dimension 2: Make humans meaningfully accountable

<!-- Guidance: Framework section 2.2. Allocate responsibility inside and outside the organisation, then design oversight that people can actually perform. Watch for automation bias: approvals that are always granted are not oversight. -->

### 4.1 Internal allocation of responsibility

| Group | Responsibilities for this system | Named lead |
|---|---|---|
| Key decision makers | Approve permitted use cases, data access limits, risk appetite and escalation route | [@exec] |
| Product team | Requirements, controls, phased rollout, testing, monitoring, user education | [@product] |
| Cybersecurity team | Security baseline, threat modelling, red teaming, incident response | [@security] |
| Users | Use within policy, complete training, report issues promptly | [@user-lead] |

Adaptive governance: describe how the organisation keeps up with new
agent capabilities and risks (for example a monthly review forum, a
named owner who tracks framework updates, and a fast path for
emergency policy changes).

### 4.2 Significant checkpoints requiring human approval

| ID | Checkpoint | Category | Approver | Form of input | Information shown | Fail-safe |
|---|---|---|---|---|---|---|
| AGOV-HIL-001 *(Example)* | Before placing any order | Irreversible and financial | Requester's manager | Approve or reject | Supplier, amount, policy check result, agent confidence | Deny if no response in 4 h |
| AGOV-HIL-002 *(Example)* | Agent proposes a supplier outside the approved list | Atypical behaviour | Procurement officer | Reject only (cannot be approved by agent flow) | Request and reason | Deny by default |
| AGOV-HIL-003 *(Example)* | Order above user's own threshold | User-defined | Requester | Approve, edit or reject | Order summary | Deny |
| AGOV-HIL-00N | [Checkpoint] | [High-stakes / Irreversible / Atypical / User-defined] | [Role] | [Approve / Edit plan / Written justification] | [Fields] | [Behaviour on failure] |

Keep approval requests short, specific and clear about the risk. For
high-risk actions, require a written reason. If the approval service is
down or no approver responds, the action must be denied, not executed.

### 4.3 Effectiveness of oversight

| Measure | Target | Current | Review cadence |
|---|---|---|---|
| Approval override (rejection or edit) rate | *Example:* between 3 % and 20 %; a rate near zero triggers review | [Value] | Monthly |
| Median time to approve | *Example:* above 20 seconds for orders | [Value] | Monthly |
| Approver training completion | 100 % before access | [Value] | Quarterly |
| Audit of a sample of approved actions | [n] per month | [Value] | Monthly |

Version 1.5 adds monitoring of override rates and response times as a
guard against automation bias. Very fast, near-universal approvals
suggest rubber-stamping; investigate and redesign the checkpoint.
Detailed oversight design lives in Human Oversight Design
(`ai-data/human-oversight-design`).

## 5. Dimension 3: Implement technical controls and processes

<!-- Guidance: Framework section 2.3. Controls at design time, testing before deployment, gradual rollout with monitoring after deployment, and change management throughout. Favour structural, rule-based controls for high-risk actions; use model-based checks where rules cannot express the risk. -->

### 5.1 Design and development controls

| ID | Component | Control | Type | Status |
|---|---|---|---|---|
| AGOV-CTL-001 *(Example)* | Planning | Agent restates the task and asks for clarification when ambiguous; plan is logged | Prompt plus logging | Done |
| AGOV-CTL-002 *(Example)* | Tools | Strict input schemas on every tool; write access only where required | Structural | Done |
| AGOV-CTL-003 *(Example)* | Tools | Agent hands control to the user for secrets and credentials | Structural | Done |
| AGOV-CTL-004 *(Example)* | Protocols | Allow-list of MCP servers; unknown servers blocked at gateway | Structural | Done |
| AGOV-CTL-005 *(Example)* | Multi-agent | Agents exchange typed messages, not free text; no shared memory | Structural | In progress |
| AGOV-CTL-006 *(Example)* | Runtime | Rate limits on tool calls; output filter for prompt injection indicators | Runtime, model-based | Done |
| AGOV-CTL-00N | [Component] | [Control] | [Structural / Runtime / Model-based / Prompt] | [Status] |

For threats to these components, use Agentic AI Threat Model
(`ai-data/agentic-threat-model`); for permission design, Agent Tool
Permission Design (`ai-data/agent-tool-permission-design`).

### 5.2 Pre-deployment testing

| ID | Test focus | Method | Environment | Runs | Result | Evidence |
|---|---|---|---|---|---|---|
| AGOV-TST-001 *(Example)* | Task completion and policy adherence across the whole workflow | Scenario suite of [n] requests | Staging with ERP replica | 5 per scenario | [Pass rate] | EV-011 |
| AGOV-TST-002 *(Example)* | Disallowed actions are blocked | Attempt new supplier, bank detail change, self-approval | Staging | 20 attempts | [Blocked n of n] | EV-012 |
| AGOV-TST-003 *(Example)* | Prompt injection through supplier data | Red team payloads in quotes | Staging | [n] | [Result] | EV-013 |
| AGOV-TST-004 *(Example)* | Agents tested together, not only individually | End-to-end multi-agent runs | Staging | [n] | [Result] | EV-014 |
| AGOV-TST-00N | [Focus] | [Method] | [Env] | [Runs] | [Result] | [EV] |

Agent behaviour varies between runs; repeat each scenario and report
the distribution, not a single pass. Use realistic environments and
data. See Agent Evaluation Plan (`ai-data/agent-evaluation-plan`).

### 5.3 Gradual rollout

| Phase | Users | Tools and protocols enabled | Systems exposed | Exit criteria |
|---|---|---|---|---|
| 1 *(Example)* | Trained procurement staff (10) | No external MCP; read-only supplier data | ERP sandbox | Two weeks without severity 1 or 2 incidents |
| 2 *(Example)* | One department | Allow-listed supplier MCP server | ERP production, order cap SGD 500 | Override rate within target |
| 3 *(Example)* | All staff | As phase 2 | Order cap SGD 2,000 | Quarterly audit clean |

### 5.4 Monitoring and logging

| Item | Decision |
|---|---|
| Monitoring objectives | [Real-time intervention / Incident debugging / Periodic audit] |
| What is logged | [Plans, tool calls with arguments, agent-to-agent messages, approvals, identity used] |
| Alerts | *Example:* Attempted unauthorised tool call; repeated failures; anomalous trajectory |
| Intervention per alert level | *Example:* Low, queued review; high, pause the agent until a human reviews; critical, revoke credentials and fall back to manual process |
| Log integrity | [Append-only store, retention period] |
| Observability standard | [OpenTelemetry traces to platform] |
| Feedback loop | [Incidents added to test suite within N days] |

Details of traces and metrics belong in LLM Observability Spec
(`ai-data/llm-observability-spec`).

### 5.5 Change management

| Trigger type | Examples | Review level |
|---|---|---|
| Technical | Model version change, new or modified tool | Full governance review |
| Environmental | New business unit, new market, new supplier type | Full review of section 3 |
| Performance | Anomalies, rising error or override rates | Targeted review, possible rollback |
| Regulatory | New guidance or law | Applicability check |
| Minor | Prompt wording refinement with no new capability | Light review by product owner |

## 6. Dimension 4: Enable end-user responsibility

<!-- Guidance: Framework section 2.4. Distinguish users who interact with an agent (for example customers) from users who build agents into their own work (for example employees). Each group needs different information and training. -->

### 6.1 Users who interact with the agent

| Disclosure | Where and how | Status |
|---|---|---|
| The user is told they are dealing with an agent | [UI banner at first message] | [ ] |
| What the agent can do and decide, and what it cannot | [Help panel] | [ ] |
| How user data is collected, stored and used | [Privacy notice link] | [ ] |
| The user's own responsibilities (for example check before confirming) | [Confirmation screen] | [ ] |
| A human contact and escalation route | [Contact link] | [ ] |

### 6.2 Users who integrate agents into their work

| Training topic | Audience | Format | Completion |
|---|---|---|---|
| How agents work and fail (planning, tools, injection) | All users | 30-minute module | [%] |
| How to review and reject agent proposals well | Approvers | Workshop with cases | [%] |
| Keeping core skills (tradecraft) and manual fallback | Process owners | Annual drill | [%] |

Plan for business continuity: if the agent is switched off, staff must
still be able to run the process by hand. Track whether skills are
eroding and schedule manual runs. Link to AI Literacy Plan
(`ai-data/ai-literacy-plan`).

## 7. Residual risk and decision

<!-- Guidance: The framework accepts that some risk always remains. Make the remaining risk explicit and have the accountable owner accept or reject it. -->

| ID | Residual risk | Rating | Why tolerable | Conditions |
|---|---|---|---|---|
| AGOV-RES-001 *(Example)* | Injection through supplier data leads to wrong supplier choice | Medium | Order cap and approval gate limit loss | Quarterly red team |
| AGOV-RES-002 *(Example)* | Approver fatigue reduces review quality | Medium | Override rate monitored | Redesign if below target for 2 months |
| AGOV-RES-00N | [Risk] | [Rating] | [Reason] | [Conditions] |

Decision: [Proceed / Proceed with conditions / Do not proceed].
Accepted by [@exec-owner] on YYYY-MM-DD.

## 8. Evidence register

<!-- Guidance: Every claim in sections 3 to 6 should point to evidence a reviewer can open. Avoid "see Confluence"; give the exact location and date. -->

| ID | Evidence | Supports | Location | Date |
|---|---|---|---|---|
| EV-001 *(Example)* | Agent design document | 2.1, 5.1 | [Link] | YYYY-MM-DD |
| EV-006 *(Example)* | Tool gateway policy export | AGOV-LIM-001 | [Link] | YYYY-MM-DD |
| EV-009 *(Example)* | Kill switch drill record | AGOV-LIM-004 | [Link] | YYYY-MM-DD |
| EV-012 *(Example)* | Disallowed action test log | AGOV-TST-002 | [Link] | YYYY-MM-DD |
| EV-0NN | [Evidence] | [Item] | [Link] | YYYY-MM-DD |

## 9. Action plan

<!-- Guidance: Record every gap found above as an action with an owner and date. Close actions with evidence, not with a status change alone. -->

| ID | Dimension | Gap | Action | Owner | Due | Status |
|---|---|---|---|---|---|---|
| AGOV-ACT-001 *(Example)* | 1 | Agent identities shared across two agents | Issue separate workload identities | [@platform] | YYYY-MM-DD | Open |
| AGOV-ACT-002 *(Example)* | 2 | No override-rate dashboard | Build approval metrics view | [@product] | YYYY-MM-DD | Open |
| AGOV-ACT-003 *(Example)* | 3 | Multi-agent messages are free text | Introduce typed schemas | [@eng] | YYYY-MM-DD | In progress |
| AGOV-ACT-004 *(Example)* | 4 | No manual fallback drill | Schedule semi-annual drill | [@ops] | YYYY-MM-DD | Open |
| AGOV-ACT-00N | [1-4] | [Gap] | [Action] | [@name] | YYYY-MM-DD | [Status] |

```mermaid
flowchart LR
  A[Scope and inventory] --> B[Dim 1: assess and bound]
  B --> C{Agent suitable?}
  C -- No --> D[Use deterministic workflow]
  C -- Yes --> E[Dim 2: accountability and checkpoints]
  E --> F[Dim 3: controls, testing, rollout]
  F --> G[Dim 4: user transparency and training]
  G --> H[Residual risk decision]
  H --> I[Monitor and change triggers]
  I --> B
```

## 10. Cross-reference to other frameworks

<!-- Guidance: Map once so the same evidence serves several obligations. Check that each referenced document is the current version. -->

| This assessment | Related framework or template |
|---|---|
| Section 3 risk factors | AI Risk Assessment (`ai-data/ai-risk-assessment`); NIST AI RMF Map and Measure functions |
| Section 3.2 and 5.1 controls | OWASP Top 10 for Agentic Applications via Agentic AI Threat Model (`ai-data/agentic-threat-model`) |
| Section 4 oversight | Human Oversight Design (`ai-data/human-oversight-design`); EU AI Act Article 14 for high-risk systems |
| Section 5.4 incidents | AI Incident Report (`ai-data/ai-incident-report`) |
| Section 6 transparency | AI Content Transparency Plan (`ai-data/ai-content-transparency-plan`) |
| Regulatory scope | AI Regulatory Applicability Register (`compliance/ai-regulatory-applicability-register`) |
| Management system | ISO/IEC 42001 AI Management System (`compliance/iso-42001-ai-management`) |

## 11. Glossary and references

<!-- Guidance: Use the framework's terms consistently; define them in your own words here. -->

| Term | Meaning in this document |
|---|---|
| Agent | Software that plans and takes multi-step actions toward a goal, usually driven by a language model and tools |
| Agentic system | One or more agents working on a process, with their tools, memory and controls |
| Bounding | Limiting what an agent can reach and do, by design, before deployment |
| Significant checkpoint | A point in the workflow where a human must approve before the agent continues |
| Automation bias | Over-reliance on an automated system, especially one that has been reliable |
| Tradecraft | The professional skills staff need to do the work without the agent |
| Kill switch | A tested way to stop all agent actions quickly |

References:

- IMDA, Model AI Governance Framework for Agentic AI, Version 1.5, published 20 May 2026, updated 5 June 2026, https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf
- IMDA factsheet, Updated Model AI Governance Framework for Agentic AI, 20 May 2026
- IMDA and PDPC, Model AI Governance Framework, second edition (2020); AI Verify Foundation and IMDA, Model AI Governance Framework for Generative AI (2024)
- Related templates: AI Agent Specification (`ai-data/ai-agent-spec`), Multi-Agent System Design (`ai-data/multi-agent-system-design`), Agent Safety Case (`ai-data/agent-safety-case`)

## Standard and licence note

Based on the Model AI Governance Framework for Agentic AI published by
the Infocomm Media Development Authority of Singapore, Version 1.5
(20 May 2026, updated 5 June 2026), which builds on Version 1.0
launched in January 2026. The framework is voluntary guidance. This
template follows its four dimensions and section numbering; all text,
tables and examples are original paraphrases and no framework text is
reproduced. Check imda.gov.sg for the current version before each
review. This is a documentation format, not legal advice, and use of
it does not imply endorsement by IMDA. Template licence: MIT.