Help Centre
/
Help Centre
Getting started

Invite your team and assign owners

Add colleagues, pick from six roles with every access control in the role editor, keep the org profile that feeds your documents, and assign obligation owners so work is accountable.

Updated Veritome documentation

Veritome is multi-tenant: everything you create lives inside your organisation and is never visible to another. Organisation (under Configure) is where you manage who is in your workspace, what each person can do, and the organisation-level details that flow onto your regulatory documents.

Who can change these settings? Organisation profile, members, roles, billing, security and integrations are Org admin capabilities. Keep at least two Org admins so you are never locked out.

Organisation profile

Go to Organisation → Organisation profile. This is not just housekeeping — the fields here are pulled straight into your paperwork:

  1. Enter your legal entity name, country, registered address and contact email exactly as they appear on official filings. The contact email and country are what mark the profile complete on the first-run checklist.
  2. Add your identifiers (registration number, legal form, organisation type, website) and your size band (EU Recommendation 2003/361).
  3. Save. From now on these values pre-fill the provider identity block on the EU declaration of conformity (Art. 47) and the Annex VIII / Art. 49 EU-database registration sheet.

The built-in roles

Veritome ships six system roles. Access is the organisation admin's call. The ultimate control over who may see and do what sits with your Org admin, in Organisation → Members & roles, not with Veritome: a switch the admin turns off is refused by the application for the work it names. Two qualifications, so nobody is surprised: a few view and download switches (PDF, evidence and report downloads, analytics, certificates, the full obligations list) are not yet enforced, so turning them off changes nothing until they are; and the administrator-only switches (members, roles, security, billing, API keys, webhooks, integrations, organisation data) only ever take effect on an administrator role, so leaving one on for a working role grants nothing.

The three working roles below start broad on purpose, broader than some organisations will want. Many of the companies the EU AI Act reaches are small: a compliance lead, a product owner and a founder, with ten systems between them. A default that split the work across people who do not exist would stop them doing it at all. So the defaults assume a small team where the same people register, work on and sign off their systems, and leave it to the admin to narrow a role as the team grows. Nothing in the product narrows a role on its own.

RoleStarts withTypical holder
Org adminEverything — billing, members, security, integrations, and all compliance work. Cannot be edited; always holds every permission.Owner / DPO / compliance lead
Compliance managerEvery access control except the administrator-only ones, across every system.Compliance manager
Compliance officerThe same broad default as Compliance manager — the admin narrows it.Day-to-day operator
System ownerThe same broad default too, seeing every system: the person who knows one system best, in a small company, usually works on the others as well.Product / system owner
Legal counselRead access across all systems and documents; can review forms before approval. Cannot edit operational data.In-house / external counsel
AuditorRead-only everywhere; can export reports and download approved PDFs.Internal audit / external reviewer

Compliance manager, Compliance officer and System owner ship identical access on day one — three names for the same broad template. They do not differ out of the box: the admin narrows each one in Organisation → Members & roles to match how the organisation works, or leaves all three as they are.

Four eyes is yours to switch on. Someone whose role can send obligations for review but not approve obligations submits an obligation for review, and only someone whose role can approve marks it Done — never without evidence attached. The requests waiting appear on the Dashboard. All four working roles can approve out of the box, deliberately: a two-person organisation has nobody to hand the second pair of eyes to. When you do have the people, take Approve obligations (and the other Approve switches: records, policies, dossier entries, incidents) away from the roles that should ask, and the review step is required from then on. A programme step is approved by the approver assigned to it, whose role must hold Approve evidence, programme steps and risk-plan sign-off.

The role editor

A role's detail in Organisation → Members & roles shows every access control Veritome has, grouped by area (AI systems, Obligations and tasks, Evidence, Policies, Dossier, Suppliers, GDPR, Reports, Team, Organisation and more), each with up to five switches — View, Edit, Approve, Delete, Manage. A switch you turn off takes effect: the change it names is refused for that role, and the button for it is not offered. The viewing switches are the exception for now: what a role can see is still decided by the system switches below. A role marked Administrator role has its administrator-only switches (billing, security, inviting and removing members, managing roles, API keys, webhooks, organisation data) unlocked; every other role keeps those switches locked off, whatever else it holds. Org admin and roles descended from it are marked this way; unmarking the last administrator role an organisation has is refused.

In the Roles view each system role has an Active toggle on Manage and above — deactivate a role you do not use to keep the invite list tidy (Org admin is always active). Editing a built-in role's permissions saves in place: your organisation gets its own version of that role, under the same name, which replaces the shared built-in for you everywhere roles are listed or assigned — other organisations keep the original untouched. Press Clone role instead when you want a separate copy alongside the original. Build custom roles from scratch with Create custom role. A member's edit screen also offers Systems they work on — which systems a role that sees only assigned systems actually covers for that person; leave it empty and they cover the systems they own. Such a member sees only those systems: in the register, on each system's pages and in what they can change.

App roles vs. operator roles — do not confuse them

  • App roles (above) control who can click what inside Veritome.
  • Operator roles — Provider / Deployer / Importer / Distributor — are what the EU AI Act assigns to your organisation for a given system, and they decide which legal obligations apply. You set the operator role in the classification flow, not here.

One person can be an Org admin in the app while your organisation is a Deployer under the Act. Keep the two mental models separate. A third thing, your position (compliance, engineering, DPO …), is what the first-run wizard asked; it tunes defaults and nothing else.

Inviting a teammate

  1. In the Members view, press Invite member.
  2. Enter their email (required) and, optionally, their name.
  3. Pick a role. New invitees default to Compliance officer — change it if they need more or less.
  4. Send. They receive an email link to set a password and join.

At your seat limit? The invite is blocked and the banner explains it — the plan caps members (fifteen during the public beta). Remove someone first, or wait for paid plans to open (see Plans, billing and upgrades).

Use Edit to change a member's name or role, or Reset password → to email them a secure set-a-new-password link. Remove revokes access immediately — reassign any obligations they owned first. Under Organisation → Security an admin can require two-factor authentication for every member; each person enrols from the first-run checklist or their own settings. If a member loses their phone, an admin resets their two-factor authentication there too: the old codes stop working, the member is signed out and emailed, and they set up a new authenticator at their next sign-in.

Assigning obligation owners

Roles are also how you make accountability explicit. On an obligation's record — from a system's Obligations tab or the Obligations register — Edit owner & target assigns an owner to each duty. Owners get the reminders (upcoming due dates, expiring evidence) and show up on the dossier as the responsible person, turning "someone should do this" into "this person owns it". The Dashboard treats an unowned duty as a gate: until every duty has an owner, the work beneath it is shown locked, without dates.

Audit trail and data isolation

Every meaningful action — a classification confirmed, an obligation updated, a dossier sealed, a review completed, a member invited — is written to the Audit trail (under Prove it). It is the hash-chained, daily-anchored record of who did what and when, which is evidence of your governance decisions for an auditor. It is not the AI system's own Art. 12 logs, which stay with the system. Because Veritome often holds data about AI systems that themselves process personal data, it is org-isolated by default and access is enforced on every request — evidence files, dossiers and reports never leave your organisation's scope.

Still stuck? Open a support request in your workspace, and a person will answer there and by email.