You are handing us the system your residents pay through.
That deserves a straight answer about how we look after it. This page is what we actually do — not a list of badges. If anything here matters to your committee or your auditors, ask us and we will show you.
Your data sits in its own database
Every client we host runs on a separate database with its own address. Your records are not sitting in a shared table alongside another organisation’s, kept apart by a filter that someone could get wrong. There is no query anyone could write, by accident or otherwise, that returns your data and somebody else’s together.
Nobody can quietly change a bill
Billing records and the formulas behind them are written once and never edited. Not by your staff, not by an administrator, not by us. If a charge needs correcting, the correction is a new entry and the original stays visible. When a resident disputes a bill months later, there is a complete history showing exactly what was calculated, when, and under which rules.
People see only what their job needs
Access is granted by role rather than person, so a meter reader, an accounts clerk and a manager each see a different system. The roles are named after real jobs, not technical groups. When a combination of roles would give one person too much control on their own — raising a charge and approving it, for instance — the system flags it rather than letting it pass unnoticed.
If something goes wrong, your data comes back
Backups are encrypted, taken every few hours and before every change we deploy, and stored separately from the system itself. More importantly, we have practised restoring them — most organisations discover their backups are unusable during the emergency, not before it. You also hold a recovery key that we do not have a copy of. If this company disappeared tomorrow, your data would still be yours.
The system is not left open to the internet
The application is not directly reachable from the public internet; traffic reaches it through a controlled path only. Administrative access requires a cryptographic key rather than a password, repeated failed attempts are blocked automatically, and security updates are applied without waiting for someone to remember.
What we don't claim
We do not hold ISO 27001, SOC 2 or any equivalent certification, and we will not imply otherwise. We have not commissioned an external penetration test. If either becomes a requirement for your organisation, tell us early — both are things we can pursue, and we would rather say so now than be vague about it later.
The same answers, in more detail
We describe properties rather than product names. Publishing our exact stack would tell anyone hostile where to start, and it would go out of date the moment we changed a tool. Under NDA we will go through the specifics with your team.
Tenancy
Database-per-tenant, not row-level multi-tenancy. Each tenant has a dedicated database and hostname, routed at the application layer. Per-client configuration — branding, tariffs, property types, calculation pipelines — is data, not code, so no client runs a private fork.
Immutability
Billing and formula audit records are create-only, enforced in the ORM rather than by convention or database grants. Calculation logic is version-locked, so a historical bill can be re-derived under the exact rules in force when it was issued. A dedicated read-only auditor role exists specifically for reviewing these logs.
Authorisation
Role-based access composed over the framework’s native permission primitives rather than reimplemented alongside them — one security engine, one place to reason about it. Roles are combinable and business-named. Constraints the native model cannot express are enforced by an additional guard layer. Segregation-of-duties conflicts are surfaced as advisories at assignment time.
Analytics access
Where reporting is exposed, row-level scoping is enforced in the semantic layer rather than in dashboard queries, so a restricted user cannot widen their own scope by crafting a request.
Backup and restore
Encrypted incremental snapshots on a multiple-times-daily schedule plus a pre-deploy snapshot, written off-box to storage separate from the application host. Retention is enforced, restores are drilled rather than assumed, and the encryption key is held by the client.
Infrastructure
Application components run isolated with no direct public exposure; ingress is via a controlled tunnel. Host and network firewalls, key-only SSH, automated intrusion blocking on repeated failures, and unattended security patching.
Questions we haven't answered here?
Send them over. We would rather answer them before you sign than after.