An agent that reads your documents is only as safe as the machine it runs on. The usual way to put an application online is to open a port and defend it. We do not open the port.
App, data and agents on a server with no public ports.
Direct attempts stop at the wall. The server accepts nothing inbound.
The server reaches out and opens the tunnel, from the inside.
Visitors reach the edge, and come in only down the tunnel.
Engineers manage it over a private mesh. Nobody else.
Every night, copied off-site, then again, encrypted, into a separate account.
Visitors reach the edge. The edge reaches your server only down the tunnel the server opened. Everything else stops at the wall.
Public traffic arrives through an outbound tunnel and administration runs over an encrypted private mesh. Database and admin ports cannot be reached from the internet.
Health, disk space, memory, certificates and uptime are monitored day and night, and alerts go straight to our phones. A second machine checks that the monitoring itself is still running.
Every night each database is copied off-site, then copied again, encrypted, into a separate account. One stolen login cannot delete both.
Once a month an automatic test restores the latest backup of each database into a throwaway machine and checks it.
Every week we check the software on our servers for known security holes. Every day we check every WordPress site we host.
An AI assistant reads the monitoring, updates and backup logs for our engineer, and every answer says where it looked.
Instead of logging into each dashboard, our engineer asks. The operator checks the machines, reads the logs and replies with what it found and where it found it.
It can propose a fix, and a person decides whether it runs.
Illustrative exchange. Host names and figures removed.
We wrote our own security standard and mapped every rule to the frameworks an auditor or a procurement team will ask about. The table shows where we are against each one today. Where it says in progress, the work is still under way.
| Standard | What it asks for | Where we are | Status |
|---|---|---|---|
| CIS Controls v8Implementation Group 1 | Basic security hygiene: know your machines, patch them, back them up, configure them safely. | The basics are part of how every server is run: an inventory, patch reports, tested backups and closed networks. | In place |
| NIST CSF 2.0Self-assessment | A way to measure maturity across identify, protect, detect, respond and recover. | Used as our yardstick between formal audits. Every function has controls in our standard. | In use |
| OWASP ASVS 4.0.3Levels 1 and 2 | How applications handle login, sessions, input, access control and secrets. | Most of it comes built into every app we make. The remaining items are being closed app by app. | In progress |
| GDPREU 2016/679 | The law on personal data: purpose, minimisation, retention, rights, breach notification. | The technical controls are in place. The documents behind them (data maps, processor agreements, retention schedules, a breach procedure) are being written now. | In progress |
| ISO/IEC 27001:2022Certification | A certified management system for information security, audited every year. | Most technical controls are already covered by our standard. The management system around them comes next, starting when a client needs the certificate. | Planned |
| BIO2Dutch government baseline | Yearly proof that a supplier to Dutch public bodies meets the government security baseline. | ISO 27001 is the usual way to show it, and that is the route we plan to take. | Planned |
| SOC 2 Type IIUS attestation | A US auditor's report that controls ran every day over a period of months. | Not pursued unless a US client requires it. Clients in the Caribbean and Europe usually ask for ISO 27001. | Not planned |
Our standard covers eleven areas, and each rule is linked to the clause an auditor will ask about. When your procurement team sends a security questionnaire, the answers already exist.
The assessment covers where your data lives.