When an auditor, regulator or internal risk team asks how a decision was made, the honest answer in many organisations is "it is somewhere in a spreadsheet and an email thread". Reconstructing that story takes days and rarely convinces anyone. An audit trail in business applications solves the problem at the source: if the system records who did what, when, and with what permission, the evidence exists before anyone asks for it. This article explains what that evidence looks like, where home-made tools fall short, and what a no-code platform should give you by default.
What auditors and reviewers actually ask for
The specific rules differ by industry and by country, and your compliance, legal or risk colleagues are the right people to interpret them. But the questions a reviewer asks about a business process tend to fall into a few recurring groups:
- Who can do this? Which people or roles are allowed to create, approve, change or delete a given record, and how is that enforced?
- Who did do this? For a specific record, who created it, who changed it, and when?
- What did it look like before? If a value changed, what was the previous value, and was the change authorised?
- How was the system itself changed? When a rule or screen changed, who changed it, and can you show the version in force at the time?
- Can you recover? If data were lost or corrupted, could you restore it, and have you tested that?
A process that runs on spreadsheets and shared inboxes struggles with every one of these. Permissions are usually "anyone with the link". Change history is partial at best. And the logic of the process lives in people's heads, so there is no version to show.
Why spreadsheets and home-made tools make compliance expensive
The cost of compliance is not only the risk of a finding. It is the time spent producing evidence. Say a finance operations team runs supplier onboarding in a spreadsheet with a column for "approved by". To show that every supplier was approved by someone with authority, the team has to cross-check initials against a list of approvers, hunt for the emails that back them up, and explain the rows where someone typed over a value.
Home-made applications can be better, but only if someone built the logging and access control carefully and kept them working through every change. That is a lot to ask of a tool that was built quickly by one person who has since moved on. Our article on spreadsheet sprawl and shadow IT looks at how these tools accumulate and why they are hard to govern.
Evidence by default: the controls a platform should provide
The better approach is for the evidence to be a side effect of normal work. Nobody should have to remember to log an approval; approving it should log it. Every Vibe application inherits the following, rather than each application having to build them:
- Role-based access on every entity and action. You define who can view, create, change or approve each kind of record, and the platform enforces it. This answers "who can do this?" with configuration you can show, not a policy document you hope people follow.
- Audit logging. Data changes and administrative actions are recorded, answering "who did this, and when?" for any record.
- Versioned change history for the application. Every change to the application itself is versioned and reversible, so you can show what the rules and screens were at a point in the past and who changed them.
- Single sign-on over SAML and OIDC. People sign in with their organisational identity, so joiners and leavers are handled in one place and there are no shared or orphaned accounts.
- Encryption in transit and at rest.
- Point-in-time backups with tested restores, run by bizapps.io, which answers "can you recover?" with a practice rather than a promise.
The platform controls page describes these in more detail, and the FAQ on whether it can pass your security review covers the evidence reviewers tend to request.
What a platform does not do for you
It is worth being precise here. No software makes an organisation compliant on its own, and Vibe does not claim to. Compliance depends on your policies, how you assign roles, how you review access, how you train people and how you respond to what the logs show. A platform gives you controls and evidence; your organisation still decides how to use them.
In practice that means a few responsibilities stay with you:
- Deciding which roles exist and who belongs in each, and reviewing that regularly.
- Designing approvals so that the same person cannot both request and approve where your rules forbid it.
- Deciding how long records should be kept, and who is responsible for reviewing the audit log.
- Involving your compliance or risk team when a new process is built, not after it is live.
Designing an auditable process from the start
Because a Vibe application can be ready in hours, it is tempting to go straight to building. For any process that will face scrutiny, spend the first half hour on a few questions instead:
- List the decisions. Which steps in this process are decisions someone could later question? Each is a candidate for an explicit approval action with its own permission.
- Name the roles. Write down who does each step today. Map them to roles, not individuals.
- Separate duties where needed. If the requester must not be the approver, make that a rule rather than an expectation.
- Decide what must never be edited. Some values, once approved, should be locked or only changeable through a further approval.
- Plan the evidence request. Imagine the reviewer's first question and check the application can answer it in a few clicks.
AI can help here too. While building, it proposes the schema, screens and rules and explains what a change will do, which makes it easier for a compliance colleague to review the design without reading anything technical. Our guide to automating business processes without code covers approvals and escalations in more depth.
Make the next audit a query, not a project
When evidence is produced by the system as people work, an audit request becomes a matter of filtering the log and exporting what was asked for. That saves time, and it also changes the conversation with reviewers, because you are showing records rather than reconstructing them.
If you have a process that currently depends on spreadsheets and goodwill, read how Vibe handles security or talk to us about the process you would like to put on a firmer footing.