What is a single-tenant internal audit system, and when do you need one?
· single-tenant, internal-audit, software
A single-tenant internal audit system is one where your organisation gets its own running copy of the software and its own database. Nobody else's audit evidence sits in it, and nothing you do moves with a release schedule shared by other customers. The opposite, multi-tenant SaaS, runs one system for everybody and keeps customers apart with a column in the database.
Most business software has gone the other way for good reasons: one system is cheaper to run, quicker to fix and easier to improve. Internal audit is one of the places where the trade stops being obvious, because of what the system holds.
What internal audit systems actually hold
Think about what accumulates in an audit system over a year:
- The risk assessment: where management believes the organisation is weak.
- Work papers and evidence: bank reconciliations, access lists, contracts, screenshots.
- Draft observations, before management has responded and before the wording has been agreed.
- Action plans with named owners and dates, including the ones that are late.
That is a map of where an organisation is soft, written by the people paid to find out, and most of it exists in draft before anyone senior has seen it. Few systems in an organisation hold anything as concentrated.
What changes when the deployment is yours
Separation stops being a control you have to trust. In a shared system, your data is kept apart from other customers' by the software doing the right thing on every query. That is usually done well, and it is still something you cannot inspect, cannot test and cannot audit. With your own database, there is nothing to separate.
Data residency is settled by where you put it. No negotiation, no addendum, no "our subprocessor in another region". The deployment runs where you installed it.
You choose when to upgrade. A shared platform moves everyone at once, which now and then lands in the week before the audit committee meets. With your own deployment, a new version waits until it suits your calendar.
The system can follow your methodology. This is the one audit leads underrate. A shared platform can only offer settings that are safe for every customer at once, so adaptation stops where configuration stops. When the deployment is yours, the questionnaires, the risk weights, the workflow and the report template can be fitted to the audit manual you already have, and a change for you is not a change for everyone else.
What it costs
Be honest about the other side of the trade.
Someone has to run it. A shared platform includes an operations team you never see: patching, backups, monitoring. A single-tenant deployment needs a home and an owner. If your organisation has a platform team, this is routine. If it does not, a system nobody patches is worse than a hosted one, and the sensible answer is a dedicated instance run for you: still your own deployment and database, just not your pager.
It is also not instant. A shared platform can have you signed up this afternoon. Your own deployment means an environment, a database, a certificate and a brand, and usually a conversation about your methodology. That is days, not hours.
The three cases where it is worth it
A rule about where data lives. A regulator, a group policy or a customer contract says audit material stays in a jurisdiction or on your own infrastructure. This is not arguable, and it ends the SaaS conversation.
A methodology of your own. You have an audit manual, a risk model with your own weights, and a report format the audit committee expects. If a shared tool forces you to restate the methodology in its language, you will spend the first year arguing with the software.
Auditees outside the audit team. The moment business owners log in to answer questionnaires and update action plans, the system stops being an audit tool and becomes an internal process. Per-seat pricing turns that rollout into a budget decision, and a vendor's branding turns an internal process into a third party collecting answers.
If none of those apply, a shared platform is a reasonable choice, and anyone selling you the alternative should say so.
How AuditEase Pro does it
AuditEase Pro is single-tenant by design: one deployment and one PostgreSQL database per customer, carrying that customer's name and logo across the application and every PDF report. It ships as a single container image, so it runs in your cloud account, your data centre, or on a dedicated instance Hikmah Technologies runs for you. It is quoted per customer rather than per seat, so rolling it out to auditees does not change the price.
The live demo is the same image every customer runs, with a fictional organisation in it and the demo's own branding. That is the honest way to see what your own deployment would look like: whatever carries "Hikmah Technologies" there would carry your name instead.
Common questions
- Is single-tenant the same as on-premise?
- No. Single-tenant is about who shares the system: you alone. On-premise is about where it runs: your own hardware. A single-tenant system can run in your data centre, in your cloud account, or on a dedicated instance a vendor runs for you.
- Does single-tenant mean more work for our IT team?
- Only if you host it. Someone has to apply updates, and on a shared platform that someone is the vendor. If you would rather not, a vendor-run dedicated instance keeps the separation without the upkeep.
- Is a single-tenant system more secure?
- It removes one class of risk, that another customer's data and yours sit in the same tables. It does not make backups, access reviews or patching happen by themselves. Those are still your controls to run.
- Can we move from SaaS to single-tenant later?
- Usually, but it costs an export and a mapping exercise. If you already know your data cannot sit in a shared system, it is cheaper to start there.