Product roadmap
The order we intend to build in, and an honest list of what is not coming. If something here is a gate for you, tell us — at this stage the order is set by what customers actually need.
There are no dates on this page, deliberately. We would rather tell you the order and be right than tell you a quarter and miss it. If you need a date for a procurement process, ask us and we will give you one for the specific thing you need — with the reasoning behind it.
Available today
Everything below is built, tested and running. It is worth reading before the roadmap, because the roadmap is short by comparison and that is the point.
In order
Single sign-on, access reviews, separation of duties, monitoring and incident response are built. What is left is the console itself first, then the remaining control workflows.
Easier orientation and quicker routes to the things you do daily: where you are, what needs you, and how to get back. Every screen reviewed for flow, then fixed.
Tickets that move on by themselves when the pull or merge request merges, and screens to manage how scanner findings are routed.
Raising a ticket by email, and replying to one, is built. It is switched on for the cloud service once its mail domain is in place; until then requests come in through the portal or the API.
Onboarding assessment and periodic review, with suppliers linked to the systems that depend on them, and a warning when a supplier's own attestation is about to lapse.
The ISO 27001 workflow for the findings your scanners already send, in the same shape as clause 10.2.
Agents that propose the steps to onboard a person in Okta, Entra ID or Google Workspace. Two people approve and nothing runs until they do.
Verify a domain you own and send notifications from it.
A drafted summary of what changed since the last review. Drafted, never certified.
Entitlements tied to your plan, once the licensing platform is ready for it.
Built when somebody needs it, using a maintained library.
Being straight with you
Listed because finding this out during a procurement review is worse for both of us than reading it here. If one of these is what you need, say so — it is a conversation, not a closed door.
Not planned, and it is not a small addition. It would need protected health information handling, a breach-notification workflow, and a considered answer about ticket content reaching a model provider. We would want to plan it properly rather than claim it.
Available self-hosted only, and deliberately. If we hold your SOX-relevant controls, this platform sits inside your audit scope and your auditor needs assurance over us. Self-hosted keeps the controls yours.
A single search box across every record is not built. Finding answers is what the Knowledge add-on below is for, and it searches by meaning rather than by keyword.
Add-ons · 2027
Each add-on is switched on per organisation and licensed on its own, on top of the platform. None of them is in the product yet. Pricing is announced when each one is released.
A knowledge base that answers requests by meaning, not keywords. An AI agent answers routine tickets from your published articles, the person who raised the ticket confirms it solved their problem, and a person on your desk is brought in when the rules say so.
Code hosting and CI/CD tied to tickets. AI agents develop against a ticket, a person reviews the code, and two people approve the merge.
Secrets, dependency, licence and code scanning on every change, with findings on the development ticket and the severities that block a merge chosen by you. Requires Development.
Read-only scanning of your cloud accounts for security and configuration issues, raised as tickets on the team that owns them and closed when a rescan passes.
Change this page
At this stage the order is set by what customers actually need, not by a committee. A requirement that blocks a deal is the strongest possible argument for moving something up, and we would rather hear it now than read it in a procurement questionnaire.
Tell us what you need