For security officers, DPOs and compliance#
Your questions#
| Question | Answer and where |
|---|---|
| What are the threats and controls? | Threat model |
| What is the overall status? | Status summary, findings register |
| What testing has been done, and what does it prove? | Test suite summary, automated suite, plan, manual checklist |
| How are identity and access handled? | Authentication and authorization; applications: API clients (scopes, deny by default, same 404 for "not there" and "not yours") |
| How are secrets protected? | Encryption, secrets and keys, credentials stay on the server |
| Which personal data, where, how long, which third parties? | Data protection; AI providers see only what a person sends: AI features |
| What is exposed to the Internet? | The public surface is read-only and published-only: architecture, section 5, draft is never public |
| What goes into the software? | Supply chain: SBOM, licences, provenance |
| What happens to our logs and audit trail? | Observability and logging: no administrative audit log |
| Can we run it in our environment? | One workspace per organisation: design decision |
Known gaps to put in your risk assessment#
No single sign-on, no mandatory second factor, no audit log of administrative actions, no per-website roles, no full Content-Security-Policy on the admin applications, no malware scanning, no automated retention or data-subject tooling, no third-party certification, throttling counted in memory per process (shared counters with the optional Valkey), a stolen client token valid until it expires. The evidence is the project's own; nobody outside the team has audited it. See the overview, chapter 4 and 8.
Reading path#
Threat model, status summary, findings, data protection, encryption, supply chain, then the design decisions.
Last updated