1. Roles and an audit trail you can read
Who may create, approve or change a record is decided per role. Every change leaves a trace, and repeated failed sign-ins are blocked.
On screen: our design, with invented sample data.
2. The controls we design in
Scope-dependent controls are marked as such in every proposal
Sign-in
Individual accounts, strong password rules and lock-out after repeated failures. Two-factor sign-in where the project scopes it.
Roles and permissions
Each role sees and changes only what its work needs. Designed with you before the first release.
Approvals
A second person checks sensitive actions, such as loans, refunds or record changes, where the project scopes maker-checker.
Audit trail
Who created, changed or approved a record, and when, kept where the people it records cannot edit it.
Encryption in transit
HTTPS for every connection between users, the system and its database.
Backups
Automated backups on an agreed schedule, and a restore tested before launch.
Least privilege
Database and hosting accounts limited to what each part of the system needs.
Secrets
Passwords and keys kept in server configuration, never in code or in the browser.
Safe demonstrations
Demos and training use invented data, never real patients, members or students.
What we do not claim
We make no claim to ISO, SOC or similar certifications. Regulatory compliance depends on your obligations; we help you document how the system supports them. Security is shared: we build and host as agreed, and you manage who gets an account and the devices they use.
Handling sensitive data?
Tell us what the system will hold and who will use it. We will propose controls to match, and say which ones are optional.
Discuss security needs