How to assess permissions and audit trails in compliance software

A compliance platform can hold every document you need and still make it difficult to answer two basic questions: who could change this record, and what changed? Those questions matter when a manager reviews a contractor approval, a training record is corrected or an inspector asks how a decision was made. A buyer should test permissions and traceability as a workflow, rather than accepting two ticks on a feature list.

This guide is for operations, compliance and information-governance teams choosing a system for UK work. It focuses on access and evidence of change. For a wider list of product categories, use the existing compliance software features checklist.

Start with the decisions that need protecting

List five or six records that carry real consequences: for example, a contractor's insurance evidence, a RAMS review, a worker's training record, an inspection finding and its closure evidence. For each, name the person who creates it, the person who decides whether it is acceptable and the people who only need to read it. This exercise prevents a vendor demo from drifting into a generic role-settings screen.

Then test the awkward cases. Can a site manager see another site's worker records without a work reason? Can the uploader approve their own evidence? Can a former worker still open a shared link? Can an administrator edit a closed record without leaving a visible trace? The right answer depends on your organisation's roles and policies, but the supplier should show how the proposed configuration would enforce them.

The ICO's accountability guidance expects organisations to take responsibility for personal-data processing and demonstrate what they have done. A system's settings can support that work; they do not make the buyer compliant by themselves. Decide what personal data is necessary for each role, who authorises access and how those decisions will be reviewed.

Ask for a live permission test

Give the supplier a small, realistic scenario and ask them to use separate test accounts. One person uploads a contractor document. Another reviews it. A third needs read-only access for an audit. Ask the supplier to show what each account sees on desktop and, if field use matters, on the device your team actually uses. Screenshots of a permission matrix are a starting point, not proof of the resulting experience.

Record the answer to these questions:

• Are permissions set by role, site, organisation, record type or a combination? Which controls are available in the product as sold today?
• Who can change permissions, and how is that change recorded?
• Can a user grant broader access than their own? What stops accidental disclosure across clients or sites?
• What happens when someone changes role, leaves or is suspended?
• Are attachments, comments, exports and shared links governed by the same access model as the main record?

If a vendor cannot demonstrate a needed boundary, log it as a gap. A promised future setting is not equivalent to a control you can configure and test during procurement.

Test the audit trail against a disputed record

An audit trail is useful only when it helps reconstruct a particular event. Ask the supplier to create a test record, change its status, replace an attachment, correct a date and reopen the item. Then ask a reviewer to reconstruct the sequence without help from the person who made the changes.

Look for the actor, action, timestamp, relevant before-and-after information, and any reason or approval attached to the change. Establish whether the history survives a file replacement or record deletion and whether administrators can alter it. Do not assume that every product logs every field or every read; ask what is recorded, what is not and who can retrieve the history. An export or audit report should be demonstrated if your evidence process depends on it.

The test should also cover time and identity. Agree which time zone timestamps use, how a named account maps to a real person, and what happens with shared or service accounts. A timestamp without reliable attribution may be of limited use in a disputed approval.

Turn the demo into acceptance evidence

Use a short acceptance sheet with a row for each control. Note the business risk, test steps, observed result, screenshot or recording reference, owner and disposition. Mark each requirement as demonstrated, configurable with agreed work, unavailable or still untested. Ask the supplier to confirm any contract or implementation commitment in writing. Retest material controls in the configured environment before rollout.

Keep the test proportional. A small contractor may need simple role separation and reliable status history. A multi-client operator may need stricter tenant and site boundaries. Do not pay for complexity that nobody will administer, but do not accept a broad “everyone can edit” arrangement where sensitive or safety-critical decisions rely on role separation.

Questions to close before signing

Who owns ongoing access reviews? How quickly can access be revoked? Which events form part of the retained audit record, and for how long? What happens to history when the contract ends? What can the buyer retrieve without the supplier's intervention? These questions connect product behaviour to your governance process and to contract terms; they cannot be settled from a marketing claim alone.

For a broader product comparison, see how Complys works and request a demonstration of the specific access and history tests above. Treat every claimed feature as unverified until you see it in the current product and confirm that it is included in the proposed arrangement.