VerifyWise 2.6: risk inheritance, evidence retention, and access hardening

The same risk tends to get written down more than once. A model that was never validated against production data is a model risk. The team shipping it logs a project risk. The vendor supplying it carries a vendor risk. Three entries, each individually correct, each owned by a different person. Nothing in the register says they describe one problem. Close the project risk and the other two sit there unchanged.

VerifyWise 2.6 is about the relationships between those entries. Where 2.5 made the platform something you could operate over a long stretch, this release works on the register itself: linking risks that belong together, deciding how long evidence stays and narrowing who can hand out access.

What is new in 2.6

Three changes carry the release:

• Risk inheritance. Link project, vendor and model risks as related, or as parent and child, with suggested links to review and a page for exploring the result.
• Evidence hub retention. Set a retention policy and an expiry date on evidence, from 30 days to indefinite.
• Access and deployment hardening. Admin-only LLM keys, organization-scoped role assignment and health probes that stop an AI Gateway outage from restarting the backend.

Behind those sit a set of smaller fixes from release testing: the dashboard's activity rows now open the record they describe, dates follow your format preference across the app, and failures in LLM Evals and the integrations now report a reason instead of a bare error.

Risk inheritance

A risk register is a flat list, and flat lists lose the structure that matters. 2.6 adds links between risks, across the three places VerifyWise tracks them: project risks, vendor risks and model risks.

Links come in two kinds, and the distinction is the useful part:

• Related to says two risks concern the same subject without either governing the other. Useful for the pair of entries that should move together.
• Inherits from sets a parent and a child. The child takes its context from the parent, so a vendor-level risk can sit above the project risks that exist because of it.

You can create a link yourself, and the platform also proposes them. A suggested link arrives with a score and the signals behind it, so you can review the reasoning instead of accepting it on faith. You confirm it or dismiss it, and when you dismiss it you can say why: not related, too weak, a duplicate, the wrong direction, the wrong parent or not hierarchical at all. Those reasons are recorded, which keeps a rejected suggestion from reading as an unanswered question later.

The parent-child relationship does its work when something changes. If a parent risk's level moves, the link records when that happened, so a child's inherited context can be checked against an assessment that may no longer hold.

A new Risk inheritance page shows the links as a graph and carries two reports:

• Duplicate candidates lists pairs of risks that look like the same risk entered twice, ranked by how much their names and descriptions overlap. It returns the closest candidates, not every pair.
• Control coverage lists active risks that no control mitigates, and separates those from risks whose project has no framework attached, which is a different problem with a different fix.

Evidence hub retention

Evidence accumulates. A control needs a screenshot, an approval needs an email, a validation needs its dataset. Each one is small enough that nobody considers the total. Several years in, the evidence store holds material that no longer supports any live obligation and still carries whatever was in it when you uploaded it.

2.6 lets you set a retention policy on evidence, chosen from 30 days, 90 days, 6 months, 1 year, 3 years, 5 years, 7 years or indefinite, alongside an explicit expiry date. The range is deliberate: a short window suits an operational artifact that gets superseded every quarter, and the long end covers the record you keep because a regulator or a contract says to.

This is a policy you set, not a cleanup that runs behind you. The point is that the retention decision gets made once, at the point where somebody knows what the evidence is for, instead of being deferred until the store is too large to review.

Access and deployment hardening

The security work in 2.6 is mostly about who can grant access and who can hold credentials. Individually these are small changes; together they close the gaps where an account could reach past its own organization.

• LLM keys are admin-only. Creating, editing and deleting them is restricted to admins, so a provider credential with real spend attached is not editable by every user who can see the page.
• Roles are organization-scoped. A role can only be assigned within the caller's own organization, and only up to the caller's own level of access, which rules out a self-promotion to a higher role, or a sideways reach into another tenant.
• Every organization keeps at least one admin. The last admin cannot be removed or demoted into an org that nobody can administer.
• Other organizations' user records stay hidden. User identifiers from a different tenant are no longer exposed, including on the profile-photo endpoints.
• Signing out clears cached data. The client query cache is emptied on logout, so it is not left for whoever uses the browser next.
• Invitations last 30 days, and only admins can send them, into their own organization only.

On the deployment side, the backend now has separate liveness and readiness probes. Previously a dependency problem could read as the backend itself being unhealthy, so an AI Gateway outage could get the backend restarted by the orchestrator while nothing was wrong with it. Splitting the probes means readiness reports "not currently able to serve" without liveness reporting "kill this container".

Credentials also stop leaking into error messages. When an LLM Evals experiment fails, it now shows why, with credentials stripped out of the error text first. The same applies to MLflow and Azure AI Foundry, where a sync failure now reports its reason. MLflow also respects the request timeout you configured instead of hanging on an unreachable host.

The supporting changes

The rest of the release is the kind of work that is invisible until it is missing:

• Dashboard activity rows are links. Each recent-activity entry opens the use case, risk, task or record it describes, instead of telling you something changed and leaving you to find it.
• An LLM API key prompt on first setup. When no key is configured, Start here offers to add one and takes admins to the key form, since the AI Advisor and reporting both need it before they do anything useful.
• Your date format, everywhere. The dashboard, tables, AI Gateway, inventory and monitoring all follow your date format preference. Mixed formats in one interface are a small thing that quietly costs trust in the numbers beside them.
• Fixes from release testing, including the ISO 27001 clauses overview, Annex chart control counts, adding a risk from a use case, translated table pagination, form validation on incidents and training, bias audit dataset uploads and the Colorado AI Act citation, which is SB 24-205.

What this covers for compliance

Retention is the piece with the clearest regulatory hook. Article 5(1)(e) of the GDPR sets storage limitation: personal data is kept in identifiable form no longer than is necessary for the purposes it is processed for. Governance evidence is an awkward fit for that principle, because it often contains personal data incidentally (a screenshot with a name in it, an approval thread, a dataset sample) while being retained for a purpose nobody revisits. A retention policy and an expiry date per item are what turn "we keep evidence" into a decision you can show someone.

ISO 42001 approaches the same material from the management-system side. Its clause 7.5 requires documented information to be controlled: created and updated, available where needed and protected. Retention is where that control meets the storage-limitation question above, and setting it at upload is one way to evidence both without a separate records exercise.

Risk inheritance is about risk management, not records. Article 9 of the EU AI Act will require a continuous, iterative risk management system run across a high-risk system's whole lifecycle, including the risks that emerge when it is used as intended. Those obligations apply from December 2027 for Annex III systems and August 2028 for Annex I. Links between a vendor risk and the project risks downstream of it are a reasonable way to keep that iteration honest, because the register shows which assessments depend on an assumption that has since changed.

Worth being precise about the limit: linking risks does not assess them, and a control coverage report tells you a risk has no control attached, not whether the controls you do have are effective. Both reports are a prompt for review.

How to upgrade

2.6 is available now. The release notes on GitHub list every change, including the dependency updates and CI work left out here.

Self-hosted deployments upgrade as previous releases did, and the user guide covers environment and database setup. Two things to check on the way: the evidence retention and risk link features add database migrations, and if you run the backend under an orchestrator, point your liveness check at /health/live and your readiness check at /health/ready to get the restart behaviour described above, while /health keeps reporting the AI Gateway for monitoring. If you drive VerifyWise over its API, the developer portal has the endpoint reference.