Security and personal data
What the tool does by default: hashing, attempt limits, encryption at rest, privileges, an audit log, and retention periods the code enforces.
A site, once delivered, becomes the responsibility of whoever runs it. So what follows is not a list of options to switch on: it is what the tool does by default, with no setting to find.
Accounts, access, data
- Passwords are hashed with whatever algorithm the framework considers best at the moment they are set, not with a choice frozen in a file that ages.
- Five failed sign-ins per quarter of an hour, on the admin as on the public site's own member area.
- An email address gets verified; a password is reset through a link that expires.
- Privileges per screen and per action: the side menu only shows what the account is allowed.
- One hundred and twenty-seven actions logged across the eight modules: who did what, to which object, and when.
- Notes and the drawn signature of a contract are encrypted at rest, not merely kept behind a password.
- Rich content is sanitised on save, then a second time before it reaches the browser.
- Ten form submissions per hour per address: a public form is not an open door.
- Deleting a publication goes through the bin, and the bin purges itself on a schedule.
What is written out plainly
- The page that collects says what it collects, on which legal basis, for how long, and who answers for it.
- Retention periods are settings the code enforces: an elapsed period permits a deletion, it does not trigger one.
- Outside services are connected with the customer's own account, never mine, and are off by default.
- The data stays with the customer: their server, their domain name, their accounts.
None of this replaces a backup. That is the first thing put in place before a site goes live, and the only one that counts on the day everything else has failed.