AI Risk Map v1.0

This guide covers both tools in the AI Risk Map suite: the Dashboard (the main assessment workflow) and the Config Editor (the risk engine configuration tool). Whether you are a business owner running your first assessment or a risk lead customising the engine for your enterprise, this guide has what you need.

Who should use this guide

The Two Apps

The suite consists of two separate HTML files that work together. You use the Dashboard to conduct assessments; you use the Config Editor to tune the risk engine to your organisation's standards.

What the tool assesses

The tool covers 60 distinct AI risks grouped into 10 risk families and mapped to 7 AI lifecycle periods. For each in-scope risk, it calculates three ratings:

Starting an Assessment

Open the Dashboard file in any modern browser (Chrome, Edge, Firefox, or Safari). You will see the six-step pipeline at the top of the screen.

The six-step pipeline

Each step in the pipeline turns green when the minimum completion threshold is met. You can click any step in the pipeline at any time to jump between steps — you do not need to complete steps in strict order. Risk ratings update live as you answer questions.

Navigation bar

Step 0 · System Details

This is the entry screen. Before you begin answering questions, record the context for this assessment. The system and vendor details are included in saved assessments, report exports, and exported risk-map images.

Loading existing work

From this screen you can also:

• Load a previously saved assessment (Open saved assessment) — restores all answers, notes, and configuration
• Load a configuration file (Load config) — applies engine settings without overwriting assessment answers

When you are ready, click Start scope to move to Step 1.

Step 1 · Scope Questions

The 30 scope questions are the most important step. They determine which of the 60 risks are relevant to your AI system. Answer carefully — every Yes activates a set of risks and makes corresponding vendor and internal survey rows required.

How scope works

Each question shows three things: the question text, an explanation of what it is really asking, and the risk codes it activates (labelled "Covers risks"). The five possible answers have the following effects:

Using filter chips

The filter bar at the top of the question list lets you navigate efficiently. Use All for a full view, Unanswered to find gaps, and Answered to review decisions. The progress counter at the top shows how many risks are currently in scope.

When is Step 1 complete?

The Scope step turns green in the pipeline when you have answered at least half (15 of 30) of the scope questions. You can always return and refine answers — all ratings update instantly.

Step 2 · Vendor Survey

The vendor survey contains 29 questions about the AI vendor's capabilities, practices, and controls. These are answered on behalf of — or in collaboration with — the AI vendor. Only questions marked Required need a response; these are the ones whose associated risks are in scope.

What each row shows

• The question text and a plain-language explanation of what strong vendor evidence looks like
• The risk codes the question informs
• A Notes field (expandable) for recording specific vendor references, version numbers, or meeting dates
• A Required or Optional badge based on your scope answers

Answer meaning in the vendor survey

CSV workflow for distributed completion

If you need to collect answers asynchronously — for example, by sending the survey to a vendor — use the CSV workflow:

Step 3 · Internal Survey

The internal survey contains 26 questions about your organisation's own governance, data management, and operational practices. These are answered by the internal team — typically the business or product owner, with input from technology, data, legal, and risk colleagues.

The structure and answer options are identical to the vendor survey. The same Required filtering logic applies: only rows whose associated risks are in scope need to be answered.

Owner field

Each question has an Owner field for recording who in the organisation is best placed to provide the answer. The explanation panel under each question describes what information you need and which team or role to consult.

Distributing the survey

The same CSV download and upload workflow from the vendor survey is available. This lets you distribute specific rows to the relevant teams (e.g., data questions to the data team, legal questions to the legal team) and consolidate responses back into the tool.

Step 4 · Controls Catalogue

The controls catalogue starts with 241 built-in controls grouped by risk code. You can also add assessment-specific custom controls under any of the existing 60 risks. A control appears as Required when its associated risk is in scope and that risk's inherent rating is not already LOW. Controls on risks that are already LOW do not need to be assessed.

Adding custom controls

Use Add custom control from the Controls step, or open a risk group and add a control directly to that risk. Custom controls are saved inside the current assessment, not in the global configuration file. They are cleared by Reset Controls and by a full assessment reset.

Each custom control has the same scoring fields as the built-in catalogue: control type, effect direction, weight, status, owner, and notes. You can edit or delete custom controls from the Controls tab. Deleting one also removes its saved status, owner, and notes.

Control status options

Control types

CSV workflow for controls

The controls list can be exported as a CSV, completed offline or distributed across teams, and re-uploaded. Use Download controls from the Controls step. Fill in the status, owner, and notes columns and upload with Upload controls. Uploaded responses are merged into the current assessment.

Custom controls are included in the CSV with a Control ID and Source column. CSV upload can update status, owner, and notes for custom controls that already exist in the assessment, but it does not create new custom control definitions. Use the in-app form for creating or editing definitions.

Step 5 · Output — The Risk Map

The Output step displays a colour-coded heat map of all 60 risks. This is the primary deliverable of the assessment — suitable for governance forums, executive reporting, and board packs.

Switching between views

Use the Base / Inherent / Residual toggle in the top-right of the heat map to switch views. The summary row below the toggle shows the count of risks in each band for the active view.

Risk band meanings

Drilling into a risk

Click any risk tile in the heat map to open a detail panel showing the risk name, code, score, and current Base / Inherent / Residual ratings along with the likelihood and impact coordinates. Out-of-scope risks are shown in grey and are excluded from all calculations.

Overriding scope

You can manually toggle any individual risk in or out of scope from the output view, independent of your Step 1 scope answers. This is useful for edge cases where the scoping logic does not perfectly reflect your situation.

Export options

Config Editor · When to Use It

The Config Editor is a standalone tool for risk leads and governance professionals. It lets you customise how the risk engine calculates ratings so the tool aligns with your organisation's framework, risk appetite, or existing risk matrix.

The five configuration tabs

Saving and sharing configuration

Configuration is saved automatically as part of your assessment JSON. To reuse the same configuration across multiple assessments:

Risk Matrix Tab

The risk matrix defines how combinations of likelihood and impact translate into risk bands. The default is a 5×5 matrix with rows representing impact (bottom to top: Insignificant → Catastrophic) and columns representing likelihood (left to right: Rare → Almost Certain).

Default risk matrix

Editing the matrix

Click any cell to cycle its rating: LOW → MEDIUM → HIGH → EXTREME → LOW. You can also edit the point score inline — point scores are used for internal ranking within a band and do not appear in the output. Cells changed from the default are highlighted with an amber outline.

Click Reset matrix to defaults to revert all cells to the default configuration.

Answer Weights Tab

Answer weights define how much credit each survey or control answer contributes to risk reduction. They are numeric values between 0.0 and 1.0.

When to adjust weights

The default weights are appropriate for most organisations. Consider adjusting in these situations:

• Reduce the Partial weight to 0.25 to apply a more conservative view of partially implemented controls
• Increase the Do not know weight slightly if your organisation treats unknown status as equivalent to partial evidence (not recommended without governance approval)

Survey Evidence Caps Tab

Survey evidence caps define how much a risk can be reduced by vendor and internal survey answers alone. These caps exist to enforce a key design principle: surveys confirm capability; controls demonstrate implementation. Survey answers alone should never be sufficient to eliminate a risk.

Control Treatment Tab

Control treatment settings define how implemented controls reduce residual risk. Controls can reduce likelihood, impact, or both, subject to caps and scaling factors.

Reduction caps

Control effect type factors

Risk Scores Tab

The Risk Scores tab lets you view and override the base taxonomy score and strategy bias for each of the 60 individual risks. This is where you align the tool with your organisation's specific risk appetite.

Base score override

Every risk has a default taxonomy score (1–10) reflecting typical AI system severity. You can override this for risks that are significantly more or less severe for your specific system or industry context. Range: 1–10.

Strategy bias

Apply an organisational risk appetite adjustment as a percentage. A positive strategy bias increases the effective score; this is used to reflect heightened concern about specific risk categories in your operating environment.

The final effective score is: Base score × (1 + Strategy% / 100), capped at 10.

To allow strategy bias to reduce risks below their taxonomy default, enable Allow negative strategy bias in the Risk Scores tab. This is disabled by default to prevent inadvertently understating risks.

Saving & Loading

Auto-save

The Dashboard automatically saves your in-progress assessment to browser session storage every time you make a change. This protects you during refreshes within the same session, but the portable JSON save is the primary way to keep work across browser restarts, devices, or handovers.

Portable save formats

Loading a saved assessment

How the Risk Engine Works

This section is for technical and governance readers who want to understand how Base, Inherent, and Residual ratings are calculated. Understanding the engine helps you interpret results and make informed decisions about configuration priorities.

Base score → likelihood band mapping

The impact band defaults to the same position as the likelihood band. Strategy bias and base score overrides are applied before this mapping. The resulting likelihood × impact coordinate is then looked up in the 5×5 matrix to produce the band (LOW / MEDIUM / HIGH / EXTREME).

Scope gating

Before any calculation, the engine checks scope. A risk is in scope if its driver question (Step 1) was answered Yes or left unanswered. Risks answered No or N/A are excluded and shown as Out of Scope. Manual scope overrides from the output view take precedence.

Inherent risk — the survey layer

The inherent layer applies vendor and internal survey evidence on top of the base risk:

• All survey answers covering each in-scope risk are collected
• Each answer is converted to a strength value using the configured answer weights
• The average strength across all answers for that risk is calculated
• If the average meets or exceeds the strong evidence threshold (default: 0.85), a likelihood reduction of up to the survey likelihood cap (default: 1 level) is applied
• Impact reduction may also apply if the survey impact cap is above 0

Residual risk — the controls layer

The residual layer applies implemented controls on top of the inherent risk:

• All controls associated with each in-scope risk are evaluated
• Each control's effect type (likelihood, impact, or both) determines the direction of reduction
• The strength of each control (Yes/Partial/No) determines contribution amount
• Total likelihood reduction is capped at the Control likelihood cap; impact reduction at the Control impact cap
• Detective and governance controls are scaled by their respective factors
• Rounding is applied using the configured method (floor = conservative)

Risk map layout

The heat map plots all 60 risks across 10 families and 7 AI lifecycle periods. Families are the columns; lifecycle period is the rows. This layout is fixed to ensure consistent meaning across exports and screenshots.

Security & Privacy

Architecture: why the tool is inherently secure

Most web applications work by sending your data to a remote server for processing. AI Risk Map is architecturally different: it is a static HTML file with all logic embedded directly in the browser. There is no back-end, no database, no API endpoint, and no network call made at any point during use.

Data residency and classification

Because no data leaves your device during normal use, there is no data residency concern. The assessment data you enter — which may include details about AI system architecture, vendor capabilities, and organisational controls — remains entirely on your local device unless you explicitly export and share it.

The sensitivity classification of any exported file should follow your organisation's standard data classification policy based on the content of the assessment, not the tool itself.

What is stored and where

Breach risk assessment

A data breach requires either an exposed server, a compromised transmission channel, or unauthorised access to a data store. The AI Risk Map has none of these elements:

• No server → no server-side breach possible
• No data transmission → no interception or man-in-the-middle attack possible
• No database → no database exfiltration possible
• No credentials → no credential stuffing or account takeover possible
• No cloud sync → no cloud storage breach possible
• No third-party scripts → no supply chain injection via CDN possible

The only residual risk is the security of the device and file system on which you run the tool — which is governed by your organisation's endpoint security controls, not by the tool itself.

Using the tool in a corporate environment

If your organisation requires approval for browser-based tools, the following points are relevant for your security review:

• Static HTML/CSS/JavaScript file — no executable installer or system-level access
• No external network requests at runtime — verifiable by inspecting browser DevTools → Network tab (should show zero requests)
• No browser permissions requested (no microphone, camera, location, notifications, or clipboard access)
• No third-party JavaScript libraries loaded from external CDNs — all code is self-contained
• Source code is fully readable by opening the HTML file in any text editor — no obfuscation

Sharing exported files securely

Exported assessment files may contain sensitive risk information about your AI systems and organisational controls. Treat exported files according to your organisation's information security policy:

• Share JSON and CSV exports via approved secure channels (SharePoint, encrypted email, etc.)
• Be aware that the JSON export contains all survey answers and notes — it is the most sensitive export format
• The Results CSV contains only risk band ratings — less sensitive, suitable for wider distribution
• Configuration files contain only engine settings and are safe to share without confidentiality concerns
• Markdown exports are human-readable and may include vendor-related notes — review before sharing externally

Verification for security-conscious teams

Any technically inclined team member can verify the security properties of the tool directly:

Tips & Best Practices

Glossary

Risk Map & Taxonomy

The AI Risk Map covers 60 distinct AI risks arranged across 10 risk families and 7 AI lifecycle periods. The heat map below shows the empty grid — the same layout used in the Dashboard output. Each cell represents one risk. Click any code to expand its description and mitigation below.

The 10 Risk Families

The taxonomy groups risks into ten families based on where in the AI system the risk originates, not where its effects are felt. This keeps assessment focused and actionable: each family maps to a distinct set of controls, owners, and review processes, so organisations can manage AI risk without treating it as a single undifferentiated problem.

The 7 AI Lifecycle Periods

Each risk is assigned to the lifecycle period where it is most effectively addressed — not merely where it becomes visible. Treating lifecycle position as a design dimension forces organisations to act earlier: risks caught at P1 (foundations) cost a fraction of what they cost to remediate at P5 (oversight) or P7 (recovery). The seven periods span the full journey from pre-development through to resilience and recovery.

References

The AI Risk Map taxonomy, risk scoring methodology, and control catalogue are informed by the following authoritative frameworks and standards. Assessors and governance professionals are encouraged to consult these sources when interpreting results or designing treatment plans.

AI Governance & Risk Frameworks

AI Security & Adversarial Risk

Responsible AI & Ethics

Agentic AI & Advanced Systems