Information Security

Last updated: 25 September 2026

This statement summarises the technical and organisational measures protecting the OZ Project Portal. It is written for clients, project partners and anyone carrying out a supplier assessment. It describes controls that are in place today, not intentions.

Contents

1. Where the Portal runs

The Portal runs on a dedicated server in a London data centre operated by DigitalOcean. The application, the database and all uploaded files are held there.

The database is not reachable from the internet — it accepts connections only from the application on the same machine. Administrative access to the server is limited to named individuals using cryptographic keys; password-based and root logins are disabled entirely. Database credentials are held outside the web directory so that they cannot be served even if a web server misconfiguration occurred.

2. Encryption in transit

All connections use HTTPS. The Portal sends HTTP Strict Transport Security, which instructs browsers to refuse any unencrypted connection to the domain, so a downgrade attack cannot be forced. Certificates are issued by Let's Encrypt and renew automatically.

3. Accounts and sessions

Access is by invitation only. There is no public sign-up. Invitations are single-use and expire after 48 hours.
Passwords are stored only as a bcrypt hash with a deliberately high work factor, which makes offline cracking expensive. The password itself is never stored, logged or recoverable.
Sign-in attempts are rate-limited per account and per address, and repeated failures from an address are blocked at the network layer.
The sign-in endpoint performs the same work whether or not the account exists, so response timing cannot be used to discover valid email addresses.
Sessions end after 30 minutes of inactivity, enforced on the server as well as in the browser.
Changing a password, resetting one, suspending an account or changing a person's permissions signs that person out on every device, and tells them why.
"Remember me" tokens are stored as hashes, replaced on every use, and if a superseded token is presented again the Portal treats it as theft and cancels every remembered sign-in for that account.
Password changes trigger a security notification to the account holder. These notifications deliberately contain no links.

Multi-factor authentication is not currently available. We state this plainly rather than leave it to inference. It is on our roadmap, beginning with privileged accounts.

4. Access control

Permissions are granular and default to closed. A new account is created with no permissions at all until an administrator grants them.

Around fifty individual capabilities are granted per person, several of which have an "own records only" setting as well as on and off.
Access is further scoped by which workspaces and projects a person has been assigned to.
Permissions reach down to individual folders, separately for viewing and for downloading, and restrictions cascade to sub-folders automatically.
Every permission is enforced on the server. The interface hides controls a person cannot use, but hiding is never the control itself.
External parties — anyone reached through a shared link, and anyone listed in a project directory — are denied by default. They see a folder only where access has been granted explicitly.
A share can never expose more than the person who created it can see themselves, and it cannot grant a download right that person does not have.

5. Handling of uploaded files

Uploaded files are not reachable directly from the web. The storage directory is blocked at the web server, and every file is served through the application after a permission check.
Files are stored under generated identifiers rather than their original names, so a file cannot be found by guessing a name.
Only an allow-list of document, drawing, image, archive and media formats may be uploaded. SVG is deliberately excluded because it can carry executable content.
Attachments added to comments on drawings and documents are always served as downloads, never rendered in the page, and are checked for their true content type rather than trusting the file extension.
Attachments added to Project Board comments are checked against a block-list that keeps executable content out, and their true content type is checked rather than trusting the file extension. Everything except images is always served as a download, never rendered in the page.
Images attached to Project Board comments are limited to JPG, PNG, GIF and WebP (never SVG), are checked for their true content type, and have embedded metadata — including any GPS location — removed when they are uploaded. They are the only attachments shown in the page, and then as images only, under a locked-down content policy that stops them running any code.
Deletion is two-stage: items move to an archive first, and permanent removal is a separate action restricted to the Portal owner.

Files are not scanned for malware. Format restrictions reduce the risk but do not eliminate it. Treat files downloaded from the Portal as you would any file received from a third party, and scan them with your own tooling.

6. Application security

All database access uses parameterised queries; user input is never concatenated into SQL.
Every state-changing request requires a cross-site request forgery token.
A strict Content Security Policy is applied, built on per-request nonces. Inline event handlers cannot execute, and the policy does not permit dynamic code evaluation.
No content delivery networks and no third-party scripts. Fonts, icons and libraries are served from our own server, so using the Portal does not disclose visitors to any third party and removes an entire class of supply-chain risk.
Security headers are applied consistently: content type sniffing is disabled, framing is refused, referrer information is minimised, and unnecessary browser features are switched off.
Error messages returned to users are generic. Database and system detail goes to server logs only.
Internal record identifiers are never exposed; the Portal uses opaque identifiers in addresses and requests.
Request rate limits are applied at both the application and the web server layer, including a separate, tighter limit on the unauthenticated shared-link surface.

Links that give access without a login are constrained by design:

Every link carries at least 130 bits of cryptographically secure randomness, far more than can practically be guessed.
No link can outlive twelve months, and permanent links cannot be created. The limit is applied when the link is used, not only when it is created, so it cannot be circumvented.
A link stops working immediately when revoked, when the project or workspace is archived, or when the person who created it loses their own access to the project.
Access through a link is recorded, and bulk downloads through a link are rate-limited.

A shared link authenticates the link, not the person holding it. Anyone with a valid link can open the content it points to. We ask recipients not to forward links, and set short expiry periods, but this is the inherent property of a login-free share and clients should factor it into what they ask us to share. Our Shared Link Terms set out recipients' obligations.

8. Logging and monitoring

An activity record captures sign-ins, uploads, edits, moves, archiving, deletions, permission changes, comments, and the creation, use and revocation of shared links.
Records are attributed to the account that performed the action, and are retained for 12 months. Shared-link access records are retained for 90 days.
Automated pruning leaves its own trace, so a gap in the record is identifiable as retention policy rather than tampering.
An automated daily health check reports on disk usage, certificate expiry, service status, error rates and blocked addresses.
Operating system security updates are applied automatically.

9. Third parties

The Portal depends on two providers that handle data: DigitalOcean for hosting in the United Kingdom, and Resend for delivering service emails. Both are engaged under written contracts meeting Article 28 of the UK GDPR. No other third party receives Portal data, and no analytics or advertising services are used.

Details are in the Privacy Notice.

10. Availability and your own records

The Portal is monitored daily and is designed to be resilient to ordinary faults. It is not, however, an archive of record.

Keep your own copies of anything you could not reproduce. Issued drawings, signed approvals and records you may need years from now should also exist in your own systems. This is the position stated in our Terms of Use, and we would rather say it clearly than have you assume otherwise.

11. Testing and assurance

The Portal is covered by an automated test suite of several hundred checks, including tests written specifically to verify permission boundaries, session handling and the limits applied to shared links. These are run before changes are released.

The application has been through repeated structured security reviews, each documented with the findings and how they were resolved. We have not yet commissioned an independent penetration test; we state that rather than imply otherwise.

12. Security incidents

We investigate suspected incidents immediately and can revoke links, suspend accounts and terminate sessions across all devices within minutes.

Where an incident involves personal data and is likely to result in a risk to people's rights and freedoms, we report it to the Information Commissioner's Office within 72 hours and inform affected individuals directly where the risk to them is high. Where an incident affects a client's project material, we tell that client promptly regardless of whether it is reportable.

13. Reporting a vulnerability

If you believe you have found a security weakness in the Portal, please tell us at {{SECURITY_EMAIL}}. Include enough detail to reproduce it.

We ask that you give us a reasonable opportunity to fix the issue before disclosing it, that you do not access, modify or delete data belonging to anyone else, and that you do not degrade the service for other users. We will not pursue action against anyone who reports a genuine issue in good faith and within those limits.

14. Contact

For supplier assessments, security questionnaires or a written confirmation of any control described here, contact {{SECURITY_EMAIL}}. For data protection matters, contact {{DP_EMAIL}}.