Self-hosted internal audit software
Self-hosted internal audit software runs on infrastructure your organisation controls: your cloud account, your data centre, or a dedicated instance run on your behalf. It matters for internal audit because the system holds the most sensitive material an organisation produces about itself — findings, evidence and draft reports before management has seen them. AuditEase Pro ships as one container image with a PostgreSQL database, so it runs wherever you can run a container.
What you need to run it
The whole product is one container image: the audit application and its web interface together, plus a database. In practice a deployment needs:
- Somewhere to run a container: Docker, Docker Swarm, Kubernetes or a single virtual machine.
- A PostgreSQL database, either your own or one we deploy alongside it.
- A disk or file share for uploaded evidence, and a backup of it.
- Redis, for the background jobs that send notifications.
- A certificate and a hostname, so your users reach it over HTTPS.
Where the audit data lives
In your database and on your storage, in your jurisdiction. Nothing is written to a shared system somewhere else, because there is no shared system: your deployment is yours alone.
Email is the one thing that leaves, and only if you switch on notifications: the system then sends mail through the mail server you give it. The optional AI drafting also makes an outbound call, and that is the reason it can point at a model you host, so the text of a draft observation need not leave your network. Both are off unless you turn them on.
If you would rather not run it
Not every audit function has a platform team, and a system that nobody patches is a worse outcome than a hosted one. So the other option is a dedicated instance that Hikmah Technologies runs for you: still your own deployment and your own database, still your brand, but we keep it running and up to date.
The choice is not permanent. Because it is the same image and the same database either way, an instance we run can be handed over to your infrastructure later, and a deployment you run can be handed to us.
What upgrades look like
A new version is a new image. You pull it, restart the service, and the database migrations run at startup. There is no coordinated upgrade window across customers, because your instance is not shared with anyone: you take a version when it suits your audit calendar, not when a vendor's release schedule says so.
Common questions
- Does it need an internet connection?
- Not for the audit work itself. It needs outbound access only for the optional email notifications and the optional AI drafting, and the AI can point at a model you host.
- Which database does it use?
- PostgreSQL. Each deployment has its own database; nothing is shared between customers.
- Can it run in our own cloud account?
- Yes. Any environment that can run a container image and reach a PostgreSQL database will do, in your cloud account or your data centre.
- Who applies updates?
- You do, if you host it: pull the new image and restart. If we run your instance, we do it and tell you what changed.
See it working
The live demo is open, with a login for each role and a fictional organisation in it. No sign-up.