What's new

Behaviour changes that affect how you use the platform, newest first. Each entry links to the page that explains the current behaviour in full.

2026-10-21 — TPRM and governance: maker-checker gates closed

The same four-eyes check, run as analyst, manager, a second manager and a viewer. Closed in third-party risk: one person could hold all three sign-off seats; the older completion path and cancellation were open to analysts; an assessment awaiting approval could be completed by a status change; scores stayed editable after the preparer signed; analysts could accept vendor risk, reopen an acceptance, or end a vendor relationship; the remediation owner could accept their own finding; a proposer could decide their own register proposal. See Vendor assessments, Vendor findings and Vendors.

Closed in governance: an analyst could pull an approved policy back to draft or retire a live one; an analyst could approve a policy exception, and a requester could approve their own; publishing a policy with no uploaded version failed with an error instead of a clear message. See Roles, Exceptions and Lifecycle.

2026-10-21 — Compliance: maker-checker gates closed

A four-eyes check of the compliance module, run as analyst, manager, approver and a viewer-role implementor. The sign-off chain, verify-close, extensions and the assessee lane held; five gaps are closed:

• Cancelling an engagement needs a manager, like reopening one. See Running an assessment.
• The implementor, owner or remediator of a finding cannot accept its risk; an independent manager must. See Accepting a risk.
• An accepted risk cannot be reopened early by an analyst; ending an acceptance needs a manager.
• The person asked for evidence does not mark it received or rejected. See Evidence requests.
• A sign-off after a return always counts. A quick re-sign used to be swallowed as a double click, leaving the reviewer nothing to review. See Sign-off.

2026-10-20 — Risk: maker-checker gates closed

A four-eyes check of the risk module as analyst, manager and risk owner found five places where the person doing the work could also approve it. All are closed:

• Closing a risk needs a manager or above, like accepting one. See Status.
• An active acceptance cannot be ended by an analyst's status edit; only a manager's Withdraw (or expiry) ends it. See Accepting a risk.
• The preparer's signature freezes the assessment. Editing after signing is refused until the reviewer returns it. See Sign-off.
• A proposer does not decide their own risk proposal without a recorded reason. See Proposals from findings.
• Engagement owners start their own engagements. The working statuses no longer need an administrator. See Create and scope.

2026-10-12 — Risk: overdue treatments are counted

The Overdue count on the Treatments page showed 0 for treatments the daily check had already marked Overdue, and the Overdue due-date filter left them out. Both now include them, so the page agrees with the board pack. See Treatments.

2026-10-06 — Risk: sign-off you can rely on, your own methodology, governed acceptance

The risk module was reviewed end to end and reworked where the record could not be trusted.

• Sign-off is ordered and segregated. Preparer, reviewer and approver sign in turn, and must be different people — or the same person records why. Reviewed risks are frozen until returned. See Risk engagements.
• Closing an engagement needs reviewed work. Only reviewed risks are written back; closing early needs a recorded reason; an empty engagement cannot be closed.
• Your own risk methodology. Set where Critical, High and Medium start and write bilingual likelihood and impact criteria; every level in the product follows it, and the criteria are shown to whoever scores. See Risk methodology.
• Accepting a risk is a recorded decision with a rationale, an approver and an expiry; it comes back for review when it expires. See Accepting a risk.
• Appetite is checked on the current score, not the inherent one. See Appetite.
• Board pack. Download the risk committee report as PDF or Word, in English or Arabic, from Reports → Board Profile. See Board reporting.
• Owners by name. Pick a risk's owner from your organisation and reassign it later; the review frequency can be changed too.

2026-10-05 — The risk register reads like a register

The risk register list and risk page have been reworked.

• Owners show again. The Owner column and the owner on the risk page were blank for every risk; they now show the accountable person.
• Scores carry their level. Inherent and residual each show the score and its level together (for example 16 · Critical), so a treated risk's lower residual is visible at a glance. The separate Level column, which only ever described the inherent score, is gone.
• Every column sorts. Click a header to sort, click again to reverse.
• The risk page has a proper header with the code, status, owner, category, next review and last assessed date, and a lifecycle showing how far the risk has come.
• Arabic shows Arabic. The risk page shows the Arabic title in the Arabic interface instead of stacking it under the English one, and its labels are translated.

2026-09-21 — A work program is a versioned methodology

Saved work programs in the Program Library now carry a version and a status, so "which methodology did this audit follow?" has an answer.

• Only an approved version can be applied to an engagement. A draft is work in progress; a retired version has been withdrawn.
• An approved version is immutable. To change one, start the next version — it opens as a draft at n+1 and the version your past audits followed is untouched.
• The engagement records which version it ran under and shows it on the Overview tab under Methodology. The name and version are copied onto the engagement, so the record holds even if the programme is later superseded, retired or deleted.
• A program can pre-link its steps to control-library controls, so applying it starts each control's history rather than leaving a blank line.

Programs that already existed are treated as approved version 1, so nothing you had stops working.

See Audit engagements → The work program is a versioned methodology.

2026-09-20 — A control is a thing you own, not text you retype

Internal Audit → Control Library is new. Until now a control was free text on a work program step, so the same control tested in two cycles was two unrelated pieces of writing, and "when did we last test this?" had no answer.

• Controls have a reference and a life of their own. A step cites a control from the library instead of retyping it, and the library counts how many steps have tested each one.
• A regulator clause is not a control. Several controls routinely cite one clause — ECC-2-2-1 may cover four separate access controls — and nothing in the product will merge two controls because they share a citation.
• Retire, do not delete. A control that has been tested cannot be deleted or renumbered: the working papers cite it. Retiring removes it from new work, keeps its history, asks why, and can be reversed.
• Build it from what you already have. scripts/backfill-audit-controls.ts proposes a library from your existing work programs. It writes a spreadsheet for a person to review and creates nothing until you say so; where it is unsure whether two steps mean the same control, it leaves them separate.

Each control now has a test history. Open a control to see every time it has been tested, grouped by cycle, with the conclusion, the verdict, who approved it and any findings raised. The page states plainly when a control has failed in consecutive cycles — a remediation that did not hold — and excludes verdicts on working papers nobody has approved yet, because a draft opinion is not a result.

Steps cite controls from the picker on the Fieldwork tab, and the link travels into a saved work program, so applying it next cycle arrives already linked.

See Control library.

2026-09-20 — A working paper now carries three signatures, and each one is kept

The working-paper chain used to have two stages. One Approve click recorded the same person as both reviewer and approver, so a paper that had passed one pair of eyes said it had passed two.

• Three stages, three acts. Submit for review (preparer), Sign review (Reviewer or Lead Auditor), then Approve (Lead Auditor or audit manager). Approval is deliberately narrower than review.
• Open review notes block both signatures. A note raised after the review still stops the approval.
• Sending work back is explicit. The approver can return a paper to the reviewer or straight to the preparer; an approved paper reopens to either.
• Every signature is photographed. The paper's content at each signature is stored unchanged, and an issued report records which version of each paper it was built on — so amending a paper afterwards cannot rewrite what the report rested on.
• Too small a team is allowed, but never silent. If one person must hold two signatures, they record why, in their own words, on that paper. There is no organisation-wide switch.

See Audit engagements → The three signatures on a working paper.

2026-09-20 — The record holds: nine integrity fixes from the module review

A full review of the audit module found several places where the product promised something the server did not enforce. All are closed.

• A finding needs an exception. The manual always said the exception verdict was the only door to a finding; the server now refuses any other origin (NOT_EXCEPTION), and the Findings tab no longer has its own "Create Finding" button. Raise a finding from the workpaper that failed its test.
• Closed means closed. Once an engagement is closed or cancelled, its fields, steps, working papers, sign-offs, evidence, requests and report refuse changes (ENGAGEMENT_CLOSED). Remediation — actions, responses, finding stages — continues, because it outlives the engagement by design.
• Closing needs an issued report. The gate used to refuse only a draft report, so an engagement that never wrote one could close and be recorded as audit coverage. Advisory engagements are exempt.
• The lead auditor is a team decision. Changing an engagement's lead auditor now needs the Lead Auditor role or an audit manager — the same floor as managing the team. Previously any team member could make themselves lead.
• "Move to final report" is what the header button now says, because that is what it does: it advances the engagement stage. Issuing the report itself happens on the Report tab.
• Report sections you write are narrative. A section sent to the server under a new key is stored as prose whatever it claims to be; only Refresh records writes the generated record sections.
• Milestones record who acted. Completing a milestone records you as the implementer; approving records you as the approver, needs a reviewer role, and is refused for the implementer. Nobody is named from a dropdown any more.
• The AI draft disclosure was wrong and has been corrected on the Reporting page: the model is sent the confirmed findings. It is never sent sample sizes, control references, evidence, management responses or unconfirmed draft observations.
• My Evidence Requests now goes overdue on the same rule as the engagement's Requests tab — when a line is still owed past the due date — instead of a header date check that could never see a partially answered request.
• Typed sampling numbers save again on the two working papers that still carried a legacy sample link from the earlier analytics design.

See Engagements, Reporting.

2026-09-19 — Data analytics is a tool of its own; results attach as evidence

Analytics is no longer part of a control assessment. It lives in the Data Analytics menu, it works on your imported populations, and it does not appear inside an audit step at all.

When a result proves something, export it and attach the file to a step as evidence. From there it is reviewed with the working paper, carried into the report and retained like every other piece of evidence. Nothing is bound: the same result can support two steps, and the analysis is not owned by either.

Every exported file now opens with its provenance — the population, the source system and file, the row count, who agreed the extract was complete and on what basis — then the test and its parameters, or the sample's method, size, basis, seed and conclusion. A spreadsheet of matched rows with no statement of what was searched is not evidence of anything.

What changed for you:

• An audit step has four tabs again: Procedure, Testing, Review, Audit.
• The four sampling numbers on a working paper are yours to type again.
• Marking an item To report no longer opens the finding form. It flags the item and carries the flag into the exported file; the finding is raised on the step from its working paper's exception verdict, which is now the only door findings come through.
• Test runs and samples no longer carry DA-nnn / S-nn references, and a re-run no longer supersedes an earlier one — both stay readable.
• A signed-off step no longer freezes your analysis. It still refuses new evidence until it is returned for rework.

See Data analytics.

2026-09-19 — The step's Analytics tab is gone; analytics sits under Testing

A step no longer has a separate Analytics tab. Testing a population and drawing a sample now happen under Data Analytics, so what belongs on the step is the record of what was filed against it — and that reads better beside the sampling numbers and the conclusion it supports than behind another tab.

Open an engagement → Fieldwork → a step → Testing, and you will find what the step asks for, the test runs filed against it, and its sample, in that order. Nothing was removed: every run, sample and disposition is where it was.

See Data analytics.

2026-09-19 — Draw a sample from a population, and work it on a spreadsheet

Sampling now works the way testing does. Open a population under Data Analytics and draw a sample from the new Sampling section without choosing an audit step first. It carries no reference and writes to no working paper until you use File against a step — at which point it takes its S-nn and records its size, population, method and exception count on that step's paper.

This closes a real defect: because the old screen asked which step before you had a sample, a treasury sample could be filed against a vendor-onboarding step and nothing objected.

Samples also travel now. Export sample gives you the drawn rows with empty Outcome, Note and Audited amount columns; work them wherever you work; Upload worked sample reads the file back and records every outcome at once, matching on the Row index column. It reads the words people actually type, refuses yes and no as ambiguous rather than guessing, reports each line it could not read, and leaves a blank outcome untested — never as "no exception".

See Data analytics.

2026-09-18 — Test a population without choosing an audit step first

Analytics no longer makes you pick an audit step before you can look at data. Open a population under Data Analytics and run tests on it directly. That is how the work actually goes: get the extract, explore it, and decide what it proves afterwards.

A run made this way is exploratory — fully usable, every item can be worked, but it carries no reference and cannot raise a finding, because it does not belong to any audit work yet. File against a step is one action and is where it becomes evidence: it takes its DA-nnn reference then, joins that step's working paper, and can raise findings. Everything you decided while exploring comes with it.

Sampling is unchanged and still belongs to a step, because drawing a sample writes its size and method onto that step's working paper.

2026-09-18 — Test a population, and draw a sample that traces back to it

The rest of audit data analytics. A step in Fieldwork now has an Analytics tab: run a test over a population whose completeness you agreed, work the items it finds, and draw a sample from it.

Seven tests, each saying what it catches: duplicate records, gaps in a sequence, value tests (including the just-below-an-approval-limit case), date anomalies, matching two populations against each other, Benford's Law and stratification. Weekend and holiday tests read your organisation's calendar — the default weekend is Friday and Saturday.

A result is a worklist, not a verdict. Items start unexplained, and each one is explained, recorded as an error, or raised as a finding. Explaining needs an explanation. Several items that share one can be decided together. A run that matched nothing says "No items met the test criteria." — never "passed", and never coloured like success.

Sampling has a basis now. Two calculators (attribute, and monetary-unit for value testing), a stored seed so a draw can be reproduced, and per-item outcomes. An untested item is reported as untested rather than counted as clean, and while any remain there is no conclusion. Once tested, an attribute sample reports the upper deviation limit against your tolerable rate — the number that actually decides whether a control can be relied on.

The sampling numbers on a working paper stop being typed. Drawing a sample writes the size, population and method onto the step, and the exception count is derived from the item outcomes. Those four then show as the record with a link to the sample, instead of fields that would refuse to save.

A test that cannot run says why — Benford's Law below 500 values, a value test on a text column, a population whose completeness has not been agreed.

Imported rows now have a shelf life. Agreeing a population's completeness starts a retention clock (two years by default, configurable), after which an overnight job deletes its rows. What is deleted is the copy of the personal data; the completeness assertion, the runs, the items you dispositioned and the sample items you tested all survive, because deleting those would remove the basis of a finding the report still cites.

Finance-formatted extracts import properly. 15,000.50 and 15/01/2026 are stored as 15000.5 and 2026-01-15 so the tests can read them, with your originals kept beside the column. A date column that could be read either way — 05/03/2026 — stays text and asks you to export it as YYYY-MM-DD rather than guessing, because a wrong guess makes every cut-off test wrong invisibly.

See Data analytics.

2026-09-18 — Import a population and prove it is complete

The first piece of audit data analytics. Internal Audit → Data Analytics takes a CSV or Excel extract, profiles every column, and flags the ones holding personal data.

The part that matters is what it will not let you do. A dataset arrives as a draft and cannot be tested until you record how you established it is the whole population — record count agreed, control total agreed, system owner confirmed, or an explanation. A test over a population nobody proved was complete reads like evidence and is not.

A variance between your extract and the source report is fine; an unexplained one is not. Write down what accounts for it and the dataset locks, with your name and the date against the sentence describing how completeness was established. After that the assertion is the basis of any testing over it, so it cannot be edited — re-import instead.

Also worth knowing:

• Type inference is strict. One "see credit note" in an amount column makes the whole column text with no total, rather than coercing and producing a figure that will not tie.
• 100,000 rows is the ceiling, and an extract above it is refused rather than truncated.
• Every import records a SHA-256 of the file.
• Columns holding personal data are flagged — by heading and by the shape of the values, so a column called ref full of IBANs is still caught. The data stays on your own server.
• Importing, recording completeness and agreeing it need fieldwork permission; only an organisation administrator can delete a draft, and nobody can delete a population whose completeness has been agreed.

Testing and sampling come next. See Data analytics.

2026-09-18 — The audit report carries the audit

The report was six free-text boxes. Its findings section was a bullet list of titles — so the condition, criteria, root cause, impact, recommendation and management response recorded against each finding never reached the document at all. Neither did what was examined, what was scoped out, who agreed to fix what, or which criteria were tested.

The report now has two halves, ordered for its two readers.

You write the argument. Executive summary, key themes, matters requiring board attention, background, objectives, scope, approach, basis for the opinion, conclusion. Each carries a prompt explaining what the section is really asking.

The engagement generates the record. Findings in full, what was examined with its samples and results, scope limitations with the reasons you gave, risk and control assessment, control strengths, the management action plan, criteria coverage, previous findings on the same entity, and an evidence appendix. These are shown as they will print and cannot be typed into — everything in them was already recorded during the audit.

What changes day to day:

• Refresh records rebuilds the generated sections from the engagement. Everything you have written is kept. Issuing refreshes once by itself first, so the version the committee receives is the engagement as it stood then.
• AI drafting writes the narrative only. The model is sent the confirmed findings (title, severity, condition, cause, recommendation) and the engagement's scope and opinion — the material a summary is written from. It is never sent sample sizes, control references, evidence, management responses or unconfirmed draft observations, and it never writes the generated record sections. (Corrected 2026-09-20: an earlier version of this entry said findings were not sent. They are.)
• The report will not claim compliance. Criteria coverage reports what was tested and what it concluded. There is no compliance column.
• It will not print a number that overstates. Where sample sizes were not recorded, it says Not recorded rather than 0.
• A step taken out of scope no longer blocks the report. It could never be signed off, and the issue gate was counting it.
• Existing reports upgrade on the first refresh. Your opinion rationale moves into Basis for the audit opinion; anything you wrote is kept.

See The audit report.

2026-09-17 — The audit program and its workpapers are one tab

An engagement kept two lists of the same test steps. Program held the RACM steps with a status you set yourself; Workpapers held a parallel list under different names, with its own status coming from the sign-off chain. Nothing kept the two in agreement, and the engagement's completion percentage read the one people forgot to update — so an engagement could show 0% complete while holding twelve workpapers, eight of them concluded.

They are now one Fieldwork tab. One row per test step, in program order; opening a row opens that step's workpaper.

What changes day to day:

• No more "generate workpaper". A step is created with its workpaper already there — adding a step is the whole action.
• You no longer set a step's status. It reads from the work: nothing recorded, in progress, or signed off. Approving the workpaper is what completes the step, so completion always reflects reviewed work.
• Workpapers can no longer be created outside the program. Anything you add mid-audit becomes a step marked added during fieldwork. Existing free-standing workpapers were converted and marked the same way — none were lost.
• Editing a step updates its workpaper. The text used to be copied once, so revising a risk statement left the auditor reading the old one.
• Marking a step not applicable asks why, and the step leaves the completion denominator. Seven of seven, not seven of ten.
• A step that has been worked on cannot be deleted — scope it out instead. Deleting one used to leave its workpaper behind with no step at all.

2026-09-17 — An evidence request tracks each document separately

If you asked for eight documents and five arrived, the request said submitted — before its due date, with a green tick. It then fell outside both the overdue check and the reminder sweep, so the three missing documents were never chased by anything.

A request is now a numbered list. PBC-014.1 to PBC-014.8, each with its own status, evidence and decision, and the request's own status is calculated from them rather than set by anyone. Five of eight reads partially submitted, and once the date passes it goes overdue on the strength of the lines still owed — with a reminder that names them.

What changes day to day:

• Attaching is submitting. The "mark as submitted" button is gone; a line with something attached is submitted, a line without is still owed.
• Accept and send back work per line. Five good documents stay accepted and locked while one goes back with a reason — you no longer have to reject the whole request to chase one item.
• Not applicable is a proper answer, with a reason, for items that do not exist at this entity. It is not a rejection.
• Auditees can leave a note on any line, so "with IT, expected Thursday" lands in the record instead of an email.
• Requests have references — PBC-014 — that you can quote.
• Register downloads the engagement's whole PBC list as CSV, one row per document asked for.

Existing requests were each given a single line holding whatever evidence they already had, so nothing was lost. Note that a request marked submitted in the past keeps that status: the system cannot know how many documents were originally asked for. This prevents the next one rather than finding the old ones.

See Evidence requests (PBC).

2026-09-17 — Audit coverage over a cycle, not just a year

Your annual plan says what you will audit this year. Your Audit Committee also asks when you last looked at something and when you will look again — and nothing answered that.

Audit Universe → Coverage rotation projects every auditable entity across the next one, three or five cycles, from its audit frequency and the date it was last audited. Planned engagements show as facts; everything else is a forecast. The committee paper now carries the same figures, including the entities not due for audit within the horizon at all.

The rotation is read-only by design — it is a projection, not an approved schedule, and the annual plan remains the only thing your committee approves.

Set frequency by tier puts critical and high on 12 months, medium on 24 and low on 36, in one step, showing you what would change before it writes anything.

One field changed: the audit universe used to ask for "Audit Cycle (Years)" when you created an entity. Nothing read it — coverage, the plan suggester and the heat map all use audit frequency in months, which until now only appeared when you edited an entity. The create form now asks for the field the product actually uses.

See Building the annual audit plan.

2026-09-17 — The annual audit plan shows its working

The plan builder would rank an audit universe nobody had scored. Unscored entities all tie, so what came out was a list ordered by audit-cycle coverage that looked like a risk assessment — and it looked authoritative enough to reach a board pack.

A plan now needs a scored universe. Open a plan and Planning readiness lists the five things that have to be true — universe, risk factors, scoring, effort estimates, capacity — with what is missing and a link to each. Below 50% scored the suggestion is refused; between 50% and 90% it generates and carries a written caveat into the plan paper.

Other changes in the same release:

• Mandatory audits. Mark an entity as required by a regulator or the board, with the obligation stated, and it is committed to the plan ahead of higher-scoring discretionary audits and never deferred for capacity.
• Scoring has a visible door. Score is now an action on every row of the audit universe, not only inside the risk heat map. Scores of 1 or 5 ask for a short reason, and a score can be cleared.
• The plan explains its deferrals. Every entity that did not make the cut says why, and a deferred critical-tier entity is flagged.
• The Audit Committee paper. Export the plan to Word or PDF — methodology, capacity derivation, selections, and the deferred list with reasons.
• Committee send-backs. Return to draft reopens an approved plan and clears its approval stamps.
• Risk Factors and Capacity Planning moved out of Audit Settings into the Internal Audit menu, in the order the work is actually done.

Plan creation no longer asks for a total budget in days. It was never used for anything; the number that drives the plan is its capacity.

See Building the annual audit plan.

2026-09-16 — Policies are approved by their named reviewers, and only by them

An approval used to be one click by one person. The reviewers you assigned were never consulted, nothing stopped an author approving their own document, and the Submit for Review button wrote the status through a route that did no checking at all — so a draft could be moved to published in a single step, past everyone.

Approval is now something a document reaches, not something anyone sets.

• Reviewers are named, and naming them means something. A document cannot be submitted for review without at least one required reviewer, and cannot be approved until every required reviewer has approved it. The panel shows the count — 3 of 5 required approvals — so you can see who is outstanding.
• They are told. Assigning a reviewer notifies them in the app and by email, with a link straight to the document. Governance → My Reviews lists what is waiting on you, and the governance dashboard has an Awaiting my approval tile.
• You cannot approve what you wrote. Neither the author of the version under review nor whoever last edited its text may approve it.
• Returning resets the round. Any reviewer can send a document back to draft; when it is resubmitted everyone approves again. Earlier decisions stay in the history, they just stop counting toward the current round.
• Advisory reviewers can be named alongside required ones. Their view is recorded but does not gate — though an advisory reviewer who returns a document still sends it back.

Two things also closed alongside it. Publishing now requires an approved version with a confirmed file — publishing launches an organisation-wide attestation campaign, and an empty draft could previously be published and formally acknowledged by everyone. And the status field was removed from the policy edit form, because it was the unchecked door; lifecycle changes now go through their own actions.

What this changes for documents already in review

A policy sitting in review with no reviewers assigned cannot be approved until you name some. Assign them on the Approvals tab and it will proceed normally. Nothing already approved or published was altered.

See Versions, reviewers and approvals and Roles and permissions.

2026-09-16 — NCA frameworks now group into domains on the coverage screen

Coverage & AI read every NCA control as its own domain. The screen groups a framework's controls by their reference number — 1 is a domain, 1-1 a sub-domain, 1-1-1 a control — but it only understood dots as separators. The Saudi NCA catalogues number with dashes, so nothing grouped.

On NCA ECC-1:2021 that meant 87 single-control "domains" listed instead of the framework's 5, and Generate scaffold proposing 87 one-control policies with no procedures instead of a governing policy with 24. The same applied to ECC-2:2024 and CSCC-1:2019. ISO, NIST and SAMA frameworks were never affected.

Both separators are now understood, including a framework that mixes them. ECC-1:2021 reads as its real 5 domains, and its scaffold proposes one governing policy with 24 procedures — one per sub-domain, each pre-mapped to the controls it covers. See Coverage and AI.

Scaffold proposals raised before this fix are not worth reviewing

A scaffold generated for an NCA framework while the grouping was broken is a long list of pending proposals, each naming a single control and carrying no procedures. They are safe to reject or dismiss in bulk — re-running Generate scaffold produces the correct single proposal.

2026-09-16 — Coverage and scaffold need governance AI switched on

Neither the coverage scan nor Generate scaffold uses AI — both are ordinary calculations over your own control mappings, and neither sends anything outside your network. Both nonetheless sit behind the governance AI-assistance switch, and with it off they are refused and the coverage card stays empty, which reads as a page that failed to load rather than a permission that is switched off.

This is now stated on Coverage and AI. If your organisation has declined AI assistance and you want coverage analysis, an administrator can enable governance AI in Settings → AI assistance.

2026-09-16 — Three governance fixes: policy file upload, exceptions, review dates

Policy file upload now completes. The upload handed the browser a destination but never recorded where it had sent the file, so confirming the upload always failed. Nothing could be attached to a policy version — and because publishing requires the artefact, nothing could be published either. Uploads work end to end now: upload, preview, download, publish.

Policy files now upload on installations with no object storage. The module only ever supported uploading straight to an S3 bucket, so on a self-hosted installation without one — the common on-prem case — policy files could not be attached at all, and nothing could be published. Those installations now upload through the application into the database, the same way audit and third-party- risk evidence already worked. Nothing to configure: the platform uses whichever path your installation supports, and the experience is the same either way. See Versions, reviewers and files.

One more change alongside it: a version is publishable only once its file is confirmed present in storage, so an upload you abandoned half-way no longer looks like a valid artefact.

The Exceptions tab works. It never loaded existing exceptions, and its request form sent a request the server could not accept, so no exception could be raised from the screen. The tab now lists every exception against the document and drives the full lifecycle — start review, approve, reject, withdraw, and renew an expired one. The request form asks for the justification and compensating controls that approval requires, with live character counts, so a request can no longer be raised that an approver would be unable to grant.

Review dates are scheduled for every frequency. A policy set to semi-annual or biennial got no next review date when it was approved, and so never appeared under Reviews due on the governance dashboard — the two frequencies most likely to be forgotten were the two the platform forgot. All four frequencies now schedule correctly.

The review-frequency dropdown also offered Bi-Annual, Monthly and As Needed, none of which the platform accepts; choosing one made saving the policy fail. The list is now the four real options: quarterly, semi-annual, annual, biennial. If a policy of yours has no review date set, re-approving it will schedule one.

2026-09-16 — The governance module is documented in full

The manual covered governance in four pages: the library, coverage, AI proposals and an overview. Most of what the module actually does was undocumented — the seven-state document lifecycle and which transitions are legal, version reviewers and approvals, the two-phase file upload, bilingual authoring and AI redlines, attestation campaigns and how their population is frozen at launch, the exception lifecycle with its two-year cap and renewal chain, control mapping strengths, and who is allowed to do any of it.

Governance now has eleven pages, one per surface, covering every action the module exposes. Two are worth reading even if you have used the module for months:

• Document lifecycle — published and effective are different states, and the difference is what lets you issue a policy ahead of the date it binds people.
• Roles and permissions — analysts generate, managers ratify. Every AI agent is analyst-level; accepting what it produces is not.

Nothing about the product changed. Start at Governance.

2026-09-30 — Controls reduce how likely a risk is, not how bad it is

The residual score was the inherent score reduced by the combined effectiveness of the mapped controls, and the residual likelihood and impact were then derived by splitting that reduction across both dimensions. The effect: a fatality risk assessed at likelihood 3 × impact 5 came back as roughly likelihood 1 × impact 2 — the platform recording, on the assessor's behalf, that a permit-to-work system had reduced the consequence of a death from catastrophic to minor.

Impact is what happens if the event occurs, and controls of this kind do not change it. Impact now carries through untouched, and the whole reduction lands on likelihood. The score follows: residual likelihood × impact.

Two consequences worth knowing:

• A residual has a floor. Likelihood stops at 1, so a risk can never be controlled below 1 × its impact. Five effective controls used to take a 15 down to 0.1; they now take it to 5 and stop. Past that point, mapping more controls stops moving the number — which is the honest answer rather than a score describing your paperwork.
• Residual scores will rise on existing risks. Nothing about your controls changed; the arithmetic that was understating severe risks did. Risks with a high impact move the most, which is the point.

Existing residuals are recalculated through the normal audited path the next time an assessment or control mapping is touched. See Controls.

2026-09-30 — A control that is not in place no longer reduces your risk

The control assessment records two things about every control — whether it is implemented, and how well it works — and only the second reached the arithmetic. A control marked Not implemented and rated Highly effective took 95% off the risk it was mapped to, and the screen showed a full green bar above a residual score built on it.

Both fields count now. A control that is not implemented, or marked not applicable, contributes nothing; a partially implemented one is capped at 30% however it is rated; an implemented one contributes its rating in full. Where the status limits the rating, the card says which figure is being used and why.

Changing the implementation status on its own now recalculates the score and the residual. It previously recalculated nothing unless the effectiveness rating changed in the same edit — so the most consequential correction on the screen, "this control is not actually in place", changed the label and left the number where it was.

Existing control assessments are corrected on upgrade. Residual scores already written to the register keep their previous value until the mapping is next edited, because moving a register score without an audit entry would be worse than carrying a generous one. See Controls.

2026-09-30 — Controls you can add where you need them, and a library that can be read back to you

Create a control without leaving the assessment. The control picker offered only controls that already existed, so discovering the library was missing the one you needed meant leaving the assessment, creating it on the library page and finding your way back. New control now adds it and selects it in place. It goes into the organisation's library, not into this assessment alone, so the next assessor finds it too. See Controls.

Suggested controls. With risk AI assistance switched on, Suggest returns the controls from your own library that bear on the risk being assessed, each with a relevance, a confidence and one sentence saying why. It cannot invent a control — every suggestion is checked against the library first and anything else is dropped — and it maps nothing: you still set the implementation status and effectiveness yourself. Off by default, per organisation, in Settings → AI assistance.

Mapping a control now updates the residual dimensions too. Rating a control's effectiveness recalculated the residual score but left the residual likelihood and impact untouched, so the same risk could read 4.5 in the register and sit at 3 × 4 on the residual heat map. Both move together now.

2026-09-30 — The board profile shows what is left, not what you started with

Top ten by residual. The board profile ranked its top ten risks by inherent score — the score before any control exists — so a risk you had already reduced from 20 to 6 outranked one sitting untouched at 16, and the page a committee reads as "our top risks" led with the risks you had dealt with. It now ranks by residual where a risk has been assessed, falling back to inherent where it has not, so an unexamined risk does not sink for being unexamined. Both scores stay on the page side by side.

Trend arrows ignore open engagements. The arrow compares a risk's last two assessments, and it was reading assessments out of engagements that were still in progress — so somebody part-way through an assessment could move the board's trend against a register their work had not yet touched. Only closed engagements count now, which is the same rule the rest of the module already followed: closing is what makes an engagement's conclusion real.

Overdue treatments are counted once. The overnight job flips a past-due treatment to the overdue status; the board profile's overdue tile counted only treatments that were past due and had not yet been flipped. The number therefore fell when the job ran. It now counts both.

See Board reporting.

2026-09-26 — A report that does not move, and a page that speaks Arabic

Issued reports. An engagement report can now be issued: the platform freezes the built document and stores a fingerprint of it — recomputed and re-checked every time the version is opened — and re-rendering that version reads the stored copy rather than live data. The fingerprint identifies the stored record, not the bytes of a downloaded file; the page says what that does and does not prove. Until now every compliance report was built from today's figures, so reopening a completed engagement or carrying a finding into the next period changed what a closed period said about itself — correct for working, wrong for a document already filed. From the engagement's ⋯ menu, Issued reports — and completing an engagement now issues its closing record automatically, so the period's own figures are kept without anyone having to remember. See Issued reports.

Refusals speak your language. Every message the platform returns when it declines something — a workpaper it will not save, a framework it will not replace, a programme it will not delete — is now translated. Where the refusal turns on a count, it names it: a programme that still holds three engagements says so, with the right plural in both languages. Most refusals do not turn on a count and read as a plain sentence.

A control whose published text is incomplete says so. A few bundled packs come from a published PDF and a handful of requirements lost the text that ran onto the next page. Those controls now carry a marker on the workpaper, in your language, instead of presenting half a rule as the whole one.

A framework can be put away. An instance accumulates editions nobody assesses against, and until now nothing could ever leave the list. Archive hides an edition from the pickers and refuses new engagements on it, while leaving every engagement that already uses it untouched and readable; Restore brings it back. Instance-wide content, so it needs a super admin. See Putting an edition away.

A programme's status can be set. It is active, completed or archived, a manager changes it on the programme page, and the three words mean the same thing everywhere. Until now nothing in the platform could change it — every programme read "Active" — while two of the four words on screen described states that could not exist. See The programme page.

The control workbook carries the governance. The Excel export now includes the N/A justification on a scoped-out control, and on every finding its root-cause category, repeat count, original due date, extension count, verifier and — where one was accepted rather than fixed — who accepted it, why, and when the acceptance expires. An ungraded control reads Not graded on the gap sheet too, instead of scoring zero against its target. See The control workbook.

Counts read correctly in Arabic. Arabic has six plural forms and the module was writing one, so "3 controls" read correctly and "1 control", "2 controls", "11 controls" and "100 controls" did not. Every label that puts a number next to a noun now selects the right form in both languages. A domain with nothing graded shows a dash rather than a label with nothing after it.

Smaller corrections.

• The progress band on an engagement says how far along it is — Early, Under way, Well advanced, Nearly complete — instead of calling it At Risk because 10% of the controls are done. The band is computed from progress alone and never saw the due date, so it was in no position to judge.

• The Review step of the new-engagement wizard is no longer badged optional. It is where the engagement is created.

• A compliance engagement is no longer called an audit engagement on the compliance module's own pages, in either language. Internal audit is a different module with its own engagements; the audit trail keeps its name.

• The carry-forward step appears where the programme is chosen. It was on the step before, which is filled in before the platform knows whether there is anything to carry — so on a straight pass through the wizard it never showed at all.

• The programme list when starting an engagement offers only programmes on the framework you picked, and the platform refuses a mismatch. Changing a programme's status needs a manager, which is what the screen and this manual always said.

• Reading the issued reports list needs an analyst or above, like reading one, and is recorded. A draft engagement can no longer be issued. A super administrator can withdraw an issued version with a written reason, which is what makes an engagement completed by mistake removable at all.

• The carry-forward step no longer offers a source it will refuse: a cancelled engagement is not listed, the most recent completed one is the default, and the wizard states whether the findings will move forward or be copied before you commit.

• Settings renders in Arabic, including the Remediation page.

• An ungraded control no longer shows as grade 0. It says not graded, on every list, which is what the workpaper itself has always said.

• Arrows point the right way in Arabic throughout the module.

• Three words that had all been called "assessed" are now graded, started and signed off, meaning one thing each — including the two cards on the engagement page, which had kept the old word over a count of the started ones.

• Retiring a framework edition needs a super admin. Loading a new one still needs a manager; taking one away affects every organisation on the instance.

• Deleting a compliance programme requires it to be empty, and a crosswalk verdict you record is yours alone rather than everyone's.

• Every rendering of an issued version — the cover, the footer, the file name and the list — now gives the same version number and says Issued. A stored v2 used to render a cover reading "v1 · Draft".

• The Arabic report PDF no longer mirrors its own figures: an average maturity of 3.0 printed as 0.3. Dates, percentages, framework names and brackets all read correctly, and an Arabic name inside an English pack renders in Arabic instead of as broken characters.

• An issued version whose stored record no longer matches its fingerprint is marked in the list and withdrawn from download, rather than handed over with a warning in a header. View opens the PDF, not a developer payload.

2026-09-25 — The manual audited against the product

Every factual claim in the compliance manual — 148 of them — was read against the code. Where the two disagreed, the product was usually the thing that needed changing.

• Deleting a compliance programme can no longer take its engagements with it. The manual said they survive; the database said otherwise, and deleting a programme destroyed every engagement inside it along with their workpapers, evidence, findings and sign-offs — including completed ones, which cannot be deleted on their own at all. A programme must now be empty before it can be removed. See Deleting.
• Overdue really is set only by the nightly job. The manual said so and the interface never offered it, but the underlying request accepted it, so a finding could be stamped overdue by hand and the next night's run would quietly disagree. Change the due date instead.
• New project only appears for people who can create one (a manager). It used to show for everyone and fail on submit.
• Corrections to the manual itself: the extension cap and escalation intervals live under Settings → Remediation, not Reminders, and a manager sets them; deleting a crosswalk needs an org admin while ratifying needs a manager; a request is received before it can be rejected; and the gap analysis page measures against the target profile, which is a different number from the engagement's compliance rate. See What the numbers mean.

2026-09-24 — Doors for things the server already did

Three capabilities existed on the server with nothing in the product to reach them, and one permission was stricter in the interface than in the rule it was meant to enforce.

• A grade can be withdrawn. Clicking the level you already chose — or Clear next to the reading — puts the axis back to not graded and takes the maturity, the grade stamp and any suggested conclusion with it. The rule had always been there; the scale could only ever record a grade, never remove one. See Grading a control.
• Evidence version history opens from the item's row: every version, who uploaded it, when, and its integrity hash, each one downloadable. See Freshness and versions.
• Anyone can browse the framework library. Loading a pack still needs a manager, because it affects the whole instance, but the browser used to be hidden entirely — so an analyst could not see what existed in order to ask.
• Your crosswalk reasoning is yours. A manual link or an AI proposal is now visible only inside the organisation that created it. Version links and the mapping engine's suggestions describe the frameworks and stay visible to everyone, as before. See Who can see a crosswalk.
• A completed engagement can be migrated to a new framework version. It is the usual case — you finish the year on one version and move to the next — and nothing is written to the closed record. Only a cancelled engagement is refused. See Moving an engagement.
• Review notes show Resolve only to the people who can clear one — the note's author, or a reviewer or approver on the engagement. The preparer being reviewed used to see a button that always failed.

2026-09-23 — One language per screen

The bilingual pass was measured by key parity between the two message files, which says nothing about whether a screen calls for a translation at all. The scanners that check this now cover every compliance directory and catch four things they used to miss: a status rendered as its raw database value, a date formatted against the reader's browser rather than the platform's language, English hidden in the second argument of an error toast, and a palette colour that only worked in light mode.

• Compliance programmes are documented and translated. The Projects pages had never been through a bilingual pass: the create form was English only and stacked both languages in one label, which the design rules forbid. It now renders in the language you are working in, and a failed create says why. See Compliance programmes.
• Statuses read as words, not keys. The sign-off dashboard, the observations lanes, the risk-proposal badges and the programme pills showed values like not_started and needs_info. They use the same translated labels as the rest of the platform.
• Dates follow the platform's language, not the reader's laptop. The same engagement no longer shows two different date formats to two people looking at the same Arabic screen.

2026-09-22 — The controls the docs promised

An adversarial re-review found features that worked through the API but had no door in the product, and numbers that disagreed between screens. Both are closed.

• Migrate to version… is now on the engagement's ⋯ menu, with a preview of what carries and what needs re-assessing, and a note under the engagement name when its framework has a newer version. See Moving an engagement.
• Crosswalks are managed in the product: ratify, reject, delete, add a link by hand, or ask the model for candidates. Importing a pack that replaces one you hold now links the unchanged controls for you. See Crosswalks.
• The extension allowance is visible on the finding, and the cap and both escalation intervals are editable under Settings → Remediation.
• A rejected evidence request shows the reason in the assignee's lane.
• Root-cause category can be set when the finding is raised.
• Carrying findings forward is honest about the source: a completed period's finding is superseded, a live one is copied and stays open, and a cancelled engagement cannot be rolled forward. See Root cause and repeat findings.
• Exports are analyst-and-above and always audit-logged, in every format.
• Progress can no longer read above 100% when scoped-out controls are signed off, and maturity averages exclude them.

2026-09-21 — Reports you can hand to a regulator

• Engagement pack and organisation posture pack as PDF and Word, in English or Arabic, built from the same numbers as the screens: executive summary, posture by domain, design vs operating effectiveness, findings with aging and root cause, a sign-off attestation page. Downloads are audit-logged. See Reporting.
• Dashboard: open findings by age, on-time closure, mean time to remediate, repeat findings, and a twelve-month compliance trend from gap-analysis snapshots.
• Reports page: posture by framework and remediation analytics at a glance, with the pack downloads beside them.

2026-09-21 — A framework engine, not a framework list

• Five more bundled packs — NCA ECC-2:2024, NCA CSCC-1:2019, NCSA NIA v2.1, SAMA BCM, SWIFT CSCF v2025 — generated from the publishers' workbooks. Every pack now states its authority, jurisdiction and the languages its control text ships in; an English-only pack shows a translation pending marker when you work in Arabic. See Frameworks.
• Versions you can see and compare. A framework's page lists its family; Compare shows what was added, removed and changed by control reference. Importing a bundled pack that replaces one you already have now creates a new version — never a duplicate.
• Migrate an engagement to a new version. Unchanged controls carry their grades; changed ones are listed for re-assessment; the original engagement is untouched. See Moving an engagement.
• Crosswalks. Links between controls of different frameworks — version links, engine or AI suggestions for a manager to ratify, and manual links. The workpaper shows prior results on mapped controls; nothing is inherited. AI proposals sit behind the compliance AI consent.

2026-09-21 — Evidence you can reuse, findings you can work

• Upload once, link many. A workpaper's Link existing searches the organisation's evidence library and attaches an artefact already on file without copying it. Linked items show where they came from and can be unlinked. See Attach evidence.
• Evidence freshness and versions. Record when evidence was collected and until when it is valid; the nightly job flags lapsed items stale. Upload a new version from the row — the old file is retired, the chain stays visible. Every download is re-hashed against the stored checksum.
• Evidence requests can be rejected, with a reason the assessee sees, and chased with Send reminder.
• Findings carry a period and a repeat count. Rolling an engagement forward now marks the original superseded and the copy the live one; a finding that survives cycles wears Repeat ×N. See Root cause and repeat findings.
• Root-cause categories, on the finding and as a list filter.
• The observations list is a triage surface: owner, due/aging, sort, pagination, and bulk assign / categorise. See Working the list.
• Extensions are capped (two approved by default) and a finding overdue for a further two weeks escalates to managers. See Due dates and extensions.

2026-09-21 — One number, one rule, everywhere

• Every screen agrees. Progress is signed-off ÷ applicable and average maturity is over graded controls only — on the engagement page, the organisation dashboard, the gap analysis, the report and the Excel export. An ungraded control shows as not graded rather than as a zero, and the gap analysis lists it as not yet assessed rather than below target.
• Late findings are counted as late. The open-findings list, the findings statistics and the findings summary now include findings the nightly job has marked overdue; previously they dropped out the morning after.
• Findings analytics now report on-time closure (against the first committed due date) and mean time to remediate (from the actual remediation), plus aging and repeat rates.
• Reopening a closed engagement needs a manager, and clears the completion date. See Running an assessment.
• Review notes are resolved by whoever raised them, or an engagement reviewer/approver — not by the preparer being reviewed. See Sign-off.
• Closed engagements are closed for snapshots and evidence requests too, and snapshot comparison refuses two snapshots that were not measured against the same target profile. See Gap analysis.
• The AI assistant and finding analysis need an analyst role, run through the same model routing as every other AI feature — so the local/hosted statement on the consent screen is true for them — and only ever see your own organisation's findings.

2026-09-21 — Grading records what you graded, and nothing else

• A fresh workpaper is "not graded", not graded zero. Both scales start empty; nothing is recorded until you choose a level, and typing an observation does not grade the control. Ungraded controls no longer drag every average to zero — the report, the dashboard and the Excel export now say not graded and average only what was graded.
• Your compliance conclusion stays yours. Choosing a status by hand now persists as your decision; reopening the workpaper no longer reverts it to the suggestion. The line under the field says whether the value is suggested or set by the assessor.
• Design and operating effectiveness reach the deliverables. Both axes are now columns in the Excel export, a section in the on-screen report, and importable from Excel.
• Accepting a risk works from the screen. Choosing Accepted opens a dialog for the rationale and expiry the platform requires (7 days to 2 years); the acceptance is shown on the finding. See Findings and remediation.
• Carrying work forward leaves it signable. A carried grade arrives in progress, and carried findings are recorded in the audit trail.
• Importing N/A now needs a justification, exactly as on screen. See Running an assessment.

2026-09-14 — Compliance: tighter records, clearer permissions

A review of the compliance module tightened how the record of truth behaves. What changes for you:

• Signed-off workpapers are read-only. Once a preparer has signed, editing needs the workpaper returned for rework first — a reviewer's name should never sit against text they did not see. The Excel import skips signed rows and tells you how many.
• Closed engagements are closed. Completed and cancelled engagements now refuse new findings, review notes, team changes, evidence and sign-off actions, not just workpaper edits. Reopen first.
• Due dates are governed. A finding's due date can be set once; moving it goes through an extension with a reason and a manager's decision, so on-time closure is always measured against the first committed date.
• Accepting a risk needs a manager, a rationale and an expiry (maximum two years), and the platform reopens the finding when the acceptance lapses. See Findings and remediation.
• Verification separates duties properly. Whoever claimed the remediation cannot verify it, even when no implementor was assigned.
• Buttons match your permissions. The compliance screens no longer offer actions your role cannot perform. Raising findings and evidence requests is manager-level; assessing controls and attaching evidence is analyst-level.
• Evidence is safer and more durable. Uploads are stored centrally with a platform-computed checksum, executables are refused at upload and every download is served as an attachment, and deleting evidence removes the file rather than orphaning it.
• Gap analysis snapshots record which target profile they measured, and the timeline's Compare button now works. See Gap analysis and snapshots.

2026-09-14 — AI assistance is now opt-in, module by module

Every AI feature in the platform is off until you turn it on, and each module is turned on separately. This applies to features that already existed, so if your team uses any of them, an administrator needs to enable them again.

Module	What it covers
Compliance	Observation drafting, the assessment assistant, generating and analysing findings
Internal Audit	Drafting an audit finding and an engagement report
Risk	Drafting a risk engagement report
Third-party risk	Analysing a vendor and a third-party finding
Governance	Policy mapping, coverage, scaffolding, authoring and redlining

Settings → AI assistance is where an organisation administrator makes the decision. Each module lists exactly what would be sent to the model before you choose, because these are not the same decision: letting a model read your own control assessments is a narrower step than handing it a vendor's questionnaire answers or your policy library. One switch for everything would force you to accept the widest in order to get the narrowest.

The page also tells you which kind of model this instance uses. With a local model the text stays inside your network. With a hosted model it is processed by a third party.

Enabling or disabling any module is recorded in the audit trail.

A configured API key is not consent

An AI key in the environment is a deployment decision. Permission for your organisation's material to reach a model is yours, and nothing runs until you give it.

2026-09-14 — Grading a control, rethought

• Maturity is graded on a 0–5 scale instead of a dropdown. The whole range stays visible, so where a control sits and how far apart its design and operating grades are can be read at a glance.
• Compliance status is suggested from the grades and sits beside the overall maturity it comes from. It stays yours to change: the suggestion stops steering the moment you pick a status, and instead tells you what the grades would have said, with one click back to it.
• Draft from evidence writes a first-pass observation from the control's requirement, your grades and the evidence attached to the workpaper. It reads the evidence record rather than the files themselves, and never saves — the text is yours to edit. It is off until an administrator enables it under Settings → AI assistance. See Running an assessment.
• The Assessment Status field is gone from the workpaper. It was server-owned and shown in full on the Sign-off tab. In its place, a line now appears only when the fields are actually locked, saying why: the engagement is closed, the workpaper is signed off, or you have read-only access.

2026-09-14 — Scheduled jobs now run (all modules)

This one is not compliance-specific and it has a first-day effect worth planning for.

Every nightly job — compliance, risk, third-party risk, internal audit and governance — was being turned away before it reached the platform. Overdue flips, due-soon reminders, escalations, digests, policy activation on the effective date and acceptance expiry have therefore never run on an existing installation.

What happens on the first night after this update

The jobs catch up. Expect, in one batch:

• findings, remediation actions, treatments and evidence requests that are already past due flipping to overdue;
• an overdue digest to each owner, and escalations on items that have been overdue a long time;
• policies whose effective date has passed moving from published to effective;
• third-party risk acceptances whose expiry has passed reopening their finding.

None of this is new data. It is the backlog the platform should have been reporting all along, arriving at once. Tell your owners it is coming, and read the first morning's digest as a catch-up rather than as one day's activity.

Compliance flips are capped per run, so a very large backlog is worked through over consecutive nights rather than in one long job.

Administrators: these jobs need CRON_SECRET set in the environment. Without it every scheduled job refuses to run. See the deployment guide.

2026-09-13 — The risk library is now the only path into the register

• Organisation Risk Library. The risk library page now leads with your own library: every risk statement your organisation has adopted, with an Origin badge showing the catalog it came from or In-house.
• Bundled catalogs feed the library, not the register. The button on ISO 27005, NCA and the other catalogs is now Add to library. It copies the definitions into your organisation library and creates nothing in the register.
• Import from the library to the register. Instantiate one entry with the Import button on its row, or everything not yet in the register with Import all to register. Imported risks arrive as identified with the library's inherent score, ready to be owned, mapped and evaluated.
• Add your own. Add risk on the library page records an in-house risk statement, bilingual, with an indicative inherent score. Entries can be edited and deleted from the preview table by managers.
• Existing installations. Risks that were imported straight from a catalog before this change stay in the register untouched, and now also appear in your organisation library with their origin recorded.

2026-09-13 — Brighter dashboard charts

Dashboard charts across the main, audit and third-party risk dashboards use a brighter palette. Severity, status, remediation and maturity keep fixed colours everywhere they appear, and every chart still carries a legend or labels so colour never stands alone.