Blog
Governance and Assurance: What UK Buyers Actually Check
A practical checklist of the governance and assurance evidence UK procurement, IG and security reviewers ask policy-software suppliers to show.
Governance and assurance, in a UK buying meeting, is a request for evidence. Procurement wants to know what the supplier will operate. Information governance wants to know which data moves, who can see it, and how a record can be reconstructed. Security wants the failure cases written down: a leaver, a wrong tenant, a model that is unavailable. Assurance and governance is the same pair seen from the supplier’s side of the table: the control, and the proof the control happened.
The list below is for buyers and suppliers of policy software, including NHS information-governance leads, council governance teams and security reviewers. It is practical guidance, not legal advice. Where it describes PolicyOps, it describes a controlled library, source-backed answers, and a record of what a person did next.
How to use the list
Ask for one sample question your staff already ask. Who may approve a supplier exception, or which information-governance procedure is in force, is enough. Then ask the supplier to show six things against it:
- The named owner of the policy that answers it.
- The version that was in force, and the version before it.
- The audit record of the answer and of any review.
- Where the text and the question were processed.
- Who, in which organisation and workspace, was allowed to see them.
- If a model helped with wording, which model, what it was given, and who remains responsible for the result.
PolicyOps separates product behaviour from deployment evidence. Identity configuration, data residency, retention, backup and restore, monitoring, connector permissions, incident response, model-provider terms and any claimed certification sit in the second pile. Ask which pile a sentence belongs to before you score it.
Ownership
Reviewers ask who is accountable when a policy is wrong, late, or in conflict with another document. A useful answer names a post, a deputy, and the route by which a change is accepted. “The governance team” is a department. The software is a system. Neither is an owner. The name should appear on the current copy and on the review record.
In PolicyOps a policy carries an owner. Owners look after the metadata assigned to them and can upload a replacement draft. Publishing a current version, and retiring one, is an authorised governance action, and the product records it. The public review workflow pages state the matching boundary: authorised policy owners and reviewers remain responsible for approval, publication and organisational decisions.
PolicyOps can show the passages behind a possible conflict. An owner, reviewer or governance administrator records a clarification or dismisses it with a reason. That note stays with the version it was raised against.
Version history
Reviewers ask which copy staff were supposed to follow on a given date, and whether an older copy is still retrievable by someone who should only see the live rule.
For the sample policy, ask for the current version, the superseded version, the date the current version took effect, and confirmation that ordinary staff answers use the current copy.
PolicyOps treats Current as the version staff see in the library and in answers. Governance users can inspect Draft, Superseded and Retired history according to role. Publishing a replacement makes it Current and marks the previous version Superseded. Retiring a policy removes it from staff lists and staff answers, and keeps the versions and the audit history. A draft that has never been current can be deleted by an administrator, with a reason and an audit tombstone. A policy that has been current is retired or superseded. In the meeting, open a staff view and confirm the old text is absent, then open a governance view and confirm it is still there with the decision that changed its status.
Audit trails
The audit trail is the assurance half of the pair. Ownership and version history say what should have happened. The trail says what did happen, tied to a person and a time.
For a policy answer, ask to see the question, the saved answer, the policy version and the passages that supported it, whether a model-assisted wording route was used, any limitation (including where the library did not support an answer), and the person asked to review what happened next.
PolicyOps keeps that shape of record. A decision receipt summarises the question, the policy version and wording used, any limitation, and the person responsible for the follow-up. The answer record, decision note and audit history sit behind it. An evidence pack is the fuller export for an authorised user in that workspace. The receipt does not approve the decision, give legal advice or certify compliance. Direct policy evidence stays distinct from related context, so a neighbouring document is labelled as context.
Ask what stops someone editing the trail afterwards, who may export it, and whether another workspace can open it. PolicyOps describes integrity markers on new records, and database protections where the relevant migrations are deployed. The assurance page calls this tamper evidence, and it stops short of legal-grade immutability or external write-once storage. Retention and legal hold belong in the deployment evidence. The export should carry the cited passages, not entire unrelated files.
Data residency
Reviewers want the regions for the application, the database and any model, the subprocessors, and the terms that say whether prompts or documents are retained or used to train a model.
PolicyOps does not publish one residency badge for every customer. The assurance page lists data residency with the items that must be evidenced for the deployed environment. Ask for that pack against the environment you would use. A diagram of an intended region is a different document from the configuration you would switch on.
The web application is hosted on Azure Static Web Apps and the API on Azure App Service. The database, including the search index, is Supabase. Where a hosted model is used, it is Microsoft Azure OpenAI in Cloudable’s own Azure subscription. Public OpenAI and other third-party AI services are not used. The region and the processing terms for that subscription, and for the database, are still contract evidence. A local model endpoint, where a deployment uses one, changes who operates the model and where its logs sit. Ask for that in the same pack.
Access controls
Test least privilege rather than collecting a role matrix. Check sign-in and multi-factor authentication, what each role can read or change, whether one workspace can open another’s policies or audit records by guessing an identifier, what happens when someone leaves, and whether support access is logged.
PolicyOps resolves organisation and workspace on protected routes, applies role permissions, and denies cross-workspace access. Staff receive current policies. Drafts stay withheld, including by guessed identifier. Sign-in uses WorkOS, with enterprise single sign-on when that is configured for the organisation and the licensed plan. Ask to see a live cross-workspace denial. Identity mapping remains a deployment check.
SharePoint, Google Drive, Dropbox and Box can be connected as read-only sources. Ask which account the connector uses and what a missing source file does. In PolicyOps that raises an exception for a person and leaves the current policy in place until someone retires or replaces it.
How AI answers are sourced and reviewed
Reviewers want to know whether an answer comes from the organisation’s policy or from a model’s general knowledge.
The source is the current policy library. PolicyOps retrieves and classifies evidence first, and the position in the answer comes from that selected evidence. A wording step, where it is switched on, may make the answer easier to read. It has to keep the selected policy, the caveats, and the cases where the evidence is thin. Related policies can be shown beside the answer. They stay secondary unless the evidence path has identified them as the primary source.
Where the library does not support the question, PolicyOps says it cannot confirm an answer from the current library, and keeps that result visible as a governance signal. That signal is a gap for a person to review. The wording step does not fill the gap with a permission, an exception or an approval route.
A suggested link between policies waits until a person accepts or rejects it. Publishing, exceptions and operational decisions stay with that person.
Where PolicyOps uses a hosted model, that model is Microsoft Azure OpenAI in Cloudable’s own Azure subscription. Public OpenAI is not used. Fast Search still returns an evidence-led answer when the wording route is off, or when the model is unavailable. The model should receive the question and the selected evidence, not the whole library by default. Logging, retention and training settings belong in the provider terms. PolicyOps is not designed to train models on customer policies. The contract is what makes that true for a given deployment.
Test it on the sample. Ask a question the policy answers and read the citation. Ask one it does not answer and read how the gap is stated. Ask one that two documents both touch, and check that related context is labelled. Then open the audit record.
Certification, stated plainly
ISO 27001 and Cyber Essentials Plus are fair questions about a certified management system and assessed controls. PolicyOps makes no ISO 27001 claim, no Cyber Essentials Plus claim and no SOC 2 claim. If a certificate is offered, read the legal entity, the scope and the date, and score the six items in this list from evidence you have seen.
What to take from the meeting
Leave with one worked example: the question, the owner, the version, the audit record, the residency and processor note, the role allowed to see it, and the person who would review an unclear result. Anything promised for later is not yet evidenced.
PolicyOps can supply the product half: current and historical versions, source-backed answers, an audit record, organisation and workspace controls, and hosted wording through Cloudable’s own Azure OpenAI when that route is on. Residency, retention, identity mapping and any certification stay on the deployment pack.
Sources
- PolicyOps security and assurance: https://policyops.io/security-and-assurance/
- PolicyOps audit trails and evidence packs: https://policyops.io/policy-audit-trail-evidence-packs/
- PolicyOps policy governance: https://policyops.io/policy-governance-software/
- PolicyOps review workflows: https://policyops.io/policy-review-workflows/
- PolicyOps source-backed answer walkthrough: https://policyops.io/source-backed-policy-answer-demo/
- Product boundary checked in the PolicyOps repository: docs/runtime-architecture.md, docs/policy-lifecycle.md, docs/assurance-pack/buyer-security-faq.md, docs/assurance-pack/ai-assurance-statement.md, packages/ai/src/providerEndpoint.ts
Explore PolicyOps
See how this fits into your working day.
Keep your library organised, get help with policy questions and leave approvals with your people.