Security and reliability
What protects your club's data.
Plain answers, without the badge wall. These are properties of how the platform is built rather than settings somebody has to remember to switch on.
In practice
Six things worth knowing.
Separation is enforced by the database
Each organisation’s records are filtered at the database level rather than by application code remembering to add a condition. A query that forgets its scope returns nothing at all instead of another club’s data — and an automated check proves that on every build by deliberately trying to read across the boundary.
Permissions are checked on the server
Hiding a button is not access control. Every action is authorised again in the service that performs it, so a page nobody can see is also a page nobody can reach by typing its address. Permissions can be limited to a single branch.
Sensitive actions must carry a reason
Refunds, discounts, stock adjustments, attendance overrides, role changes and payroll all record who acted, what changed, and why. The reason is required — the action is refused without one.
Nobody sets somebody else’s password
Staff are invited and choose their own password. Not even an administrator can set one for a colleague, because an audit trail is only worth having if nobody can act as another person.
Sessions can be ended immediately
Signing a device out takes effect on the next request rather than whenever a token happens to expire, and sign-in attempts are rate limited per account and per network.
Backups are verified, and restores are rehearsed
Every backup is read back and checked when it is written, and restoring one into a throwaway copy is a routine that has actually been run. A backup nobody has restored is not a backup.
Security and reliability
Built to be trusted with a club's money.
The protections below are structural — they are properties of how the platform is built, not settings somebody has to remember to switch on.
Organisation-level data isolation
Every club’s data is separated in the database itself, not only in application code, and the separation is tested on every build.
Role-based permissions
Over 100 permissions, grouped into roles you control, and scoped to a branch where that matters.
Audit history
Refunds, discounts, stock adjustments, role changes and payroll record who did it, what changed and why — a reason is required.
Secure authentication
Modern password hashing, rate-limited sign-in, and sessions that can be revoked immediately from the server.
Automated backups
Scheduled database dumps that are verified when written, with a restore drill that has been run rather than assumed.
Health monitoring
The platform checks its own database connection continuously, so a degraded service is visible before a customer finds it.
Controlled staff access
Nobody — including an administrator — can set another person’s password. Staff receive an invitation and choose their own.
Being straight with you
What we do not claim.
FrontCourt does not hold ISO 27001, SOC 2 or any other third-party security certification, and this page will not imply one. Nor do we operate a public bug bounty or publish an uptime guarantee we have not yet earned the operating history to stand behind.
What is described above is real, verifiable and part of how the software is built and tested. If your organisation needs a security questionnaire completed before you can proceed, write to sales@frontcourt.pro and it will be answered honestly, including where the answer is “not yet”.
Put your sports business in the front court.
Replace disconnected tools with one platform for bookings, memberships, payments and operations.
frontcourt.pro