Who may do what, and the proof of it.
Roles, permissions, segregation of duties, and an audit trail that nobody — including an agent — can edit after the fact.
Segregation of duties·Immutable trail·Access review
The controls, and the evidence for them.
Most systems have the first three. The fourth — being able to hand an auditor evidence without a project — is where they usually fall down.
Roles and permissions
What a person or an agent may reach.
Role-based, not per-user
Permissions attach to roles; people hold roles. A leaver is handled by removing a role rather than auditing a person.
Row-level rules
Restrict by company, cost centre, warehouse, territory, or any field, so 'their own region only' is a rule rather than a convention.
Field-level permissions
A role can open a record without seeing every field on it — salary on an employee, cost on a sales order.
Document-state permissions
Who may create, who may submit, who may cancel, and who may amend, granted separately.
One model everywhere
The interface, the API, the mobile apps, and every agent sit in the same permission model. There is no privileged path.
Segregation of duties
The control an auditor opens with.
Raiser cannot approve
Enforced at the transition, not advised in a policy document.
Conflicting-role detection
Combinations that would break segregation are flagged when the role is assigned, rather than found in an audit.
Applies to agents
An agent cannot approve what it raised, and a chain of agents cannot compose an approval between them.
Documented exceptions
Where a small team genuinely cannot segregate, the exception is recorded with an owner and a compensating control instead of being silently configured away.
The audit trail
What happened, who did it, and when.
Immutable
Postings are never edited. A correction is its own reversing entry, so the trail shows the change of mind rather than hiding it.
Full version history
Every version of every document with the field-level difference between them.
Agent actions attributed
Every posting shows whether a person or a named agent made it, and under which limit it was permitted.
Reasoning attached
An agent's steps and the records it read, written to the document rather than to a log with a retention policy.
Not editable by anyone
There is no administrative role that can rewrite the trail. That is the property that makes it evidence.
Review and evidence
Handing an auditor what they asked for, without a project.
Access review
Who holds which roles, what changed since the last review, and a record of the sign-off.
Privileged access log
Every use of an elevated permission, listed, so 'who could have done this' is answerable.
Change history on rules
Permissions, workflows, and limits are versioned records, so a control change is as traceable as a transaction.
Evidence packs
Because controls and transactions are both documents, an audit request is a report rather than a fortnight of extraction.
Answering 'who approved this, and could they?'
The point of the design is that this takes four clicks rather than four days, and produces evidence rather than an assurance.
- 01
The document
Open the transaction and read its full version history, including who moved it between states and when.
- 02
The authority
See the role and the limit that permitted the approval at the moment it happened, not as configured today.
- 03
The rule
Open the permission and workflow versions that were live on that date, with their own change history.
- 04
The pattern
Run the same question across the period as a report, to show it was not an isolated case.
The specification.
The control statements a SOC 2 or ISO reviewer will map against.
- Model
- Role-based, with row- and field-level rules
- Coverage
- Interface, API, mobile, and agents — one model
- Segregation
- Enforced at transition, including across agent chains
- Trail
- Immutable; no role can edit or delete it
- Versioning
- Field-level history on documents, permissions, and workflows
- Attribution
- Person or named agent, plus governing limit
- Access review
- Role holdings, deltas, and recorded sign-off
- Retention
- Configurable, with legal hold
What governance cannot do for you.
The system enforces the rules you give it. It has no opinion about whether they are the right ones.
- It will not design your control framework
- We can implement segregation, thresholds, and review cycles. Deciding what your controls should be is your risk function's job, not a product feature.
- It cannot segregate a team of two
- Where there are not enough people, no configuration creates them. The honest answer is a documented exception with a compensating control.
- A permission model reflects your org
- If reporting lines are wrong in the employee records, derived approvers will be wrong too. Governance surfaces that rather than fixing it.
- Certifications are not controls
- Our SOC 2 covers how we run the service. It says nothing about whether your approval limits are sensible, and no auditor will accept it as though it did.
Next step