> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/regulations/component-4/navigation-pathways-and-the-five-step-methodology.md).

# Navigation Pathways and the Five-Step Methodology

Four common task types, the toolkit combinations they call for, and how the toolkit maps back onto the five-step ToR methodology.

Four task types cover the most common situations practitioners encounter. The toolkit combinations below are starting points — adapt based on the specific context established in [Reading Your Context](/experience-digital-transformation/regulations/component-4/reading-your-context-two-questions-that-matter.md).

## P1 — New Instrument in a Domain with No Existing Framework

**When to use.** You are designing a digital signatures law, a data protection framework, a digital identity regulation, or another instrument where there is currently no legislation covering the relevant domain.

**Most relevant for.** All underlying concerns — though institutional design emphasis varies significantly. Countries with the state information sovereignty concern (Pathway 6) require especially careful attention to supervisory independence before rights provisions.

**Toolkit elements to apply**

* **B — Comparative benchmarking first:** identify the most appropriate reference model before drafting begins. This prevents the most common failure mode: transplanting an instrument designed for different institutional conditions.
* **C — Instrument design:** use a policy concept note to resolve foundational design questions before architecture choices are made. For digital identity this is the PKI concept paper; for data protection it is a policy paper on threat model, institutional design, and scope, the same for interoperability regulation.
* **D — Stakeholder engagement:** map and engage resistant constituencies early. Identify the operational pain point that brings the most resistant constituency on board.
* **E — Implementation planning:** design institutional arrangements from the outset, not as an afterthought to legislative drafting.

{% hint style="warning" %}
**Watch for:** Transplanting an international model without adaptation. The gap between formal adequacy and operational effectiveness is widest when instruments are copied rather than adapted to the country's underlying concern and institutional context.
{% endhint %}

## P2 — Reviewing and Updating an Existing Framework

**When to use.** An existing law or framework is being reviewed — because it is outdated, because an international review has identified gaps, or because a domestic incident has revealed weaknesses.

**Most relevant for.** Countries with the constitutional right or institutional accountability underlying concern most commonly undertake scheduled reviews. Countries with the legal authority or state information sovereignty concern more often review in response to external pressure.

**Toolkit elements to apply**

* **A — Regulatory inventory and gap analysis:** assess the existing framework against current [Component 3](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations.md) reference standards, distinguishing formal gaps from operational failures. These require different remedies.
* **B — Comparative benchmarking:** identify what has changed in the international reference landscape since the original instrument was designed.
* **C — Instrument design:** focus on the specific provisions that need to change. Avoid comprehensive redraft unless foundational structural problems have been identified — that requires a different political mandate.
* **D — Stakeholder engagement:** explain what has changed and why to constituencies that have built compliance practice around the existing framework.

{% hint style="warning" %}
**Watch for:** Scope creep — using a periodic review as the vehicle for a comprehensive overhaul when the political window only supports targeted amendments.
{% endhint %}

## P3 — Legal Harmonisation: Meeting a Required International or Regional Standard

**When to use.** The country has a legal obligation to meet a defined standard — EU accession, African Union convention, GCC digital standards, or similar.

**Most relevant for.** Countries with the constitutional right or procedural correctness underlying concern are most likely to be in formal accession processes. The legal authority and state information sovereignty concerns present the greatest adaptation challenges.

**Toolkit elements to apply**

* **A — Regulatory inventory and gap analysis:** map the existing framework against the required standard to identify the specific gaps that must be closed.
* **C — Instrument design:** concentrate design choices on adaptation decisions — which features of the required standard need to be localised to work in this country's context. Formal transposition is not sufficient if the institutional preconditions for operational effectiveness are absent.
* **D — Stakeholder engagement:** manage the tension between formal compliance requirements and practical implementability.
* **E — Implementation planning:** harmonisation obligations include timelines. The plan must meet them while building genuine institutional capacity, not just formal compliance.

{% hint style="warning" %}
**Watch for:** Formal transposition without operational implementation — meeting the letter of the requirement without building the institutional infrastructure that makes the standard functional.
{% endhint %}

## P4 — Regulatory Design as Part of a Digital Transformation Programme

**When to use.** A country is building new digital government infrastructure and the regulatory framework needs to be developed in parallel — a learner registry, a digital identity system, an interoperability platform.

**Most relevant for.** Countries with the constitutional right, institutional accountability, or procedural correctness underlying concern that are actively building digital infrastructure. Digitalisation strategy preparation is the typical agenda-setting context.

**Toolkit elements to apply**

* **C — Instrument design:** the regulatory instrument must be designed in parallel with the technical infrastructure, not after it. Instruments drafted after systems are built consistently underfit the actual data flows and institutional arrangements.
* **D — Stakeholder engagement:** engage the technical infrastructure teams as a primary constituency — their operational knowledge is essential to instrument design.
* **E — Implementation planning:** align regulatory milestones with infrastructure deployment milestones so that legal framework and technical capability become operational simultaneously.
* **A — Regulatory inventory:** identify which adjacent regulatory instruments the new infrastructure depends on and which absent frameworks will create obstacles.

{% hint style="warning" %}
**Watch for:** Regulatory and technical development on separate tracks that only intersect at deployment. The result is either a system deployed without adequate regulatory framework or a framework that does not fit the system as built.
{% endhint %}

## How the Toolkit Maps to the Five-Step Methodology

The Terms of Reference frame this methodology as five sequential steps with named outputs. [The toolkit](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md) deliberately reorganises the same material by task rather than by sequence, because most real assignments enter the process mid-stream. The mapping between the two framings is as follows.

| ToR step                                 | Toolkit element(s)                                                                                                                                                                                                | Outputs and where they are produced                                                                                                                                                  |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Step 1 — Regulatory landscape assessment | [Toolkit A — Regulatory Inventory and Gap Analysis](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md)                                          | Regulatory inventory; gap analysis report. Blank and worked templates: Component 6, Sections 2–3. Prompt 1 in Section 4.3.                                                           |
| Step 2 — Global benchmarking             | [Toolkit B — Comparative Benchmarking](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md)                                                       | Benchmarking report; regulatory model options. Prompt 2 in [Section 4.3](/experience-digital-transformation/regulations/component-4/using-ai-tools-to-support-regulatory-work.md).   |
| Step 3 — Regulatory design               | [Toolkit C — Instrument Design](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md)                                                              | Regulatory concept note; draft regulation outline (template: Component 6, Section 4). Prompts 3–4 in Section 4.3.                                                                    |
| Step 4 — Stakeholder consultation        | [Toolkit D — Stakeholder Engagement](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md), with the legislative-process techniques of Section 3.2 | Consultation reports; revised regulatory drafts. Prompt 5 in [Section 4.3](/experience-digital-transformation/regulations/component-4/using-ai-tools-to-support-regulatory-work.md). |
| Step 5 — Implementation roadmap          | [Toolkit E — Implementation Planning](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md)                                                        | Implementation roadmap; institutional governance model (diagrams: Component 6, Section 5; sequencing logic: Component 5, Chapter 5).                                                 |

{% hint style="success" %}
**The mapping is many-to-many by design, not a renaming.** The toolkit elements are selected and combined by task, and the navigation pathways above show the combinations, while the five ToR steps describe the complete sequence a full national reform programme traverses. A team running the whole sequence applies the elements in roughly the step order; a team entering mid-stream applies whichever elements its pathway requires. Toolkit element and ToR step are not two names for the same thing — several elements can serve one step, and Toolkit D in particular serves Step 4 together with the legislative-process techniques described alongside the toolkit.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/regulations/component-4/navigation-pathways-and-the-five-step-methodology.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.