- Home
- Legal
- Security
Security
This platform holds site layouts, staffing patterns, vulnerabilities and protective measures. That is exactly the information an attacker would want, and it is protected accordingly.
Last updated: [DATE]
Before this site goes live
Publish only what is actually true on the day. Each control below should be confirmed against the deployed environment, and the bracketed items completed. A security page that overstates the position is worse than no security page.
In transit and at rest
- HTTPS throughout. All traffic to the website and the platform is encrypted in transit, with HTTP redirected to HTTPS and HSTS enabled.
- Encryption at rest for the database and uploaded files, where the hosting platform supports it.
- Secure file storage — uploaded documents are served only through an authenticated, access-controlled route, never from a publicly guessable location.
Accounts and access
- Password hashing using a modern algorithm. Passwords are never stored or logged in readable form, and we cannot tell you what yours is.
- Role-based access — Organisation Administrator, Responsible Person, Contributor and Read Only, so people get the least access that lets them do their job.
- Session management — secure, HTTP-only session cookies, session regeneration on sign-in, and idle timeout.
- Multi-factor authentication — [STATE CURRENT STATUS: available / in development / required for administrators].
- Administrative access is restricted to named individuals, protected by additional controls, and logged.
Uploads
- File type and size restrictions on everything uploaded.
- Uploads are stored outside the executable web path, and the server is configured not to execute anything in the upload directory.
- Malware scanning — [STATE CURRENT STATUS AND PROVIDER].
Monitoring and resilience
- Audit logging of significant events, including administrative actions and access to customer records.
- Logging and monitoring of the infrastructure, with alerting on anomalies.
- Backups taken [FREQUENCY], retained for [PERIOD], and restore-tested [FREQUENCY].
- Disaster recovery — [STATE RTO AND RPO].
How we build
- Parameterised database queries throughout, so user input is never concatenated into SQL.
- Output encoding on every page, and cross-site request forgery protection on every form.
- Security headers set at the server, including content type options, frame options and a referrer policy.
- Dependencies kept current, with vulnerability alerts monitored.
- Penetration testing — [STATE FREQUENCY AND WHO BY, OR SAY NOT YET CARRIED OUT].
Data protection
- Data is stored in the [UK / REGION].
- Retention controls, so information is not kept indefinitely by default.
- Processors engaged under written contracts meeting UK GDPR requirements.
- See our Privacy Policy for the detail.
What we ask of you
- Use a strong, unique password — a short phrase of three or four words is both stronger and easier than a mangled word.
- Give each person their own account rather than sharing a login.
- Remove users when they leave.
- Think about who needs to see the whole record and who only needs part of it.
- Do not email us the sensitive detail of your premises' vulnerabilities — ask us for a secure route.
Reporting a vulnerability
If you believe you have found a security problem, please tell us before telling anyone else. Email hello@martynslawworkbook.co.uk with enough detail to reproduce it. [CONSIDER A DEDICATED security@ ADDRESS AND A security.txt FILE.]
We will acknowledge your report within [PERIOD], keep you updated, and will not pursue anyone who reports a genuine issue in good faith and does not access, modify or retain other people's data in the process.
Please do not run automated scanning or load testing against the service without asking us first.