Everything on this page was either measured on the live service, read from the deployed code (including the signed-in register, which is provided to an organisation when it is set up on the service), or is a written operator commitment, and each statement says which. We hold no security certification and claim none.
At a glance
- Deterministic governance. The assessment is evaluated by the published pack's fixed rules. Since 3 November 2026 no artificial-intelligence or large-language-model service takes any part in the assessment path.
- Data minimisation. A staff-facing service: no pupil accounts, no pupil data requested, no MIS or SIS integration; people are recorded by role.
- Least privilege and tenant isolation. The application uses a database role confined by row-level security; every register request is authorised on the server, and one organisation never reaches another's records.
- Human review and a bound verification record. Every result is held for a person to release; a Passport becomes publicly verifiable only through a release that matches its recorded result exactly.
- Stated plainly. Encryption in transit everywhere; no analytics and no tracking; no penetration test and no certification yet (see "What is not in place").
Security governance
The service is run by a single operator, who holds administrative access to the hosting and deployment accounts (measured: single-member hosting organisation and personal deployment scope). The written policies are the Security and Assurance Schedule, the incident policy, the personal-data-breach playbook and the retention procedure; they are available to any engaged school on request.
Access control, authentication and authorisation
- For the assessment (in force): one engagement code per assessment, generated by a tested generator (12 characters from a 32-character alphabet). No accounts, no passwords, nothing to phish. Codes can be revoked.
- For the signed-in register (built; enabled only when an organisation is set up on it): people sign in by an e-mailed link through our authentication provider; ANAX never sees or stores a password. Our server exchanges the link for a one-time code and then keeps its own session cookie, signed by our server, HttpOnly, sent only to our site, and limited to 12 hours. Every page and every change is checked on the server, in this order: who is signed in, which organisation they belong to, and what their role allows. A person reaches only the organisations they are a member of — a trust administrator reaches the trust and its schools; a school's administrators and members reach that school and nothing else; a school never sees a sibling school and a trust never sees another trust. A request for someone else's school, record or action is answered as if it did not exist. Measured in the register's own tests: 16 attempts by a signed-in user of one trust to reach another trust's records all refused with no data returned.
- Invitations: joining is by invitation link only. The link is shown once to the person who creates it, works once, expires after 7 days, is bound to one organisation and one role, and only a hash of it is stored; it cannot be used to join a different organisation or to obtain a higher role.
- Inside the service: the form, the review queue and the register connect to the database as a least-privilege role confined by row-level security, with no grants outside that schema (verified in production for the assessment tables, 7 of 7 checks, 11 October 2026; the register's tables, applied to the production database on 3 November 2026, use the same model and have no delete right). Internal routes between services require a service token or master key and return 401 without one (measured).
- Public verification: the verification page reads read-only database views with an anonymous key; base tables are closed and the two functions that mint identifiers are executable by the service role only (closed 11 October 2026 and probed from outside).
Encryption
Every connection to the service and between its components uses TLS; the assessment page sends HTTP Strict Transport Security. The database connection requires TLS.
Data isolation and minimisation
Each school's answers are reachable only with that school's code; cross-school read attempts are refused by the database. In the register, each school's AI tool records — the tool's name, provider and website as the school entered them — belong to that school alone, and the database refuses to link one school's register entry to another's tool record. No pupil data is requested, and the register's pages say so wherever text is typed. No model provider takes part in a run: the governance engine calls no artificial-intelligence or large-language-model service.
Auditable governance history
In the register, nothing is overwritten by the service: every assessment attempt, every decision, every change to an action's owner or due date, every completion and every review obligation is kept as its own record with its date. The current state is derived from that history and shown as plain words. The one exception is deliberate and narrow: if pupil data or other personal data is typed into a free-text field by mistake, our operator can replace that text with a fixed marker through a redaction route that only the database owner can use (applied to the production database on 3 November 2026). The record keeps everything else, and a redaction record notes which record and field, when and why, never the removed text.
Browser-side protection
A strict Content Security Policy (default-src 'none', the page's single script pinned by hash, connections only to our own origin, no framing), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict referrer policy, and a permissions policy denying camera, microphone, geolocation and payment. The legal pages and the register pages carry no script at all. No analytics. The public pages set no cookies; the register sets the two strictly necessary cookies described on the cookies page, and a change submitted from another website is refused.
Secure development and release
- Dependencies are installed from a lockfile; the assessment pack is vendored as an immutable, tagged release and the container build refuses to start if any of its 41 content hashes differ from the manifest (measured in build logs). The register adds no new dependency.
- Every production release is verified by an independent script run from a fresh checkout before it is deployed; each deployment records the authorising decision, the image deployed and the rollback image.
- Database changes are ledgered migrations with verification scripts, applied from a generated, guarded bundle and verified against the live schema afterwards (the register's migrations were applied to production this way on 3 November 2026).
npm auditis reviewed before each deploy (operator commitment).
Rate limiting and abuse protection
Code lookups are limited to 10 per address per 10 minutes on each of our two machines, and writes to 600 per address per 10 minutes on each; a code cannot be guessed at that rate. The register's changes share the same write limit. The proxy-trust depth is verified against the live hosting topology so that a client cannot spoof its address.
Incident response
Platform health checks on every application and a worker heartbeat; reports from schools by email. Severities, communication targets and templates are written down; a personal data breach affecting a school's content is notified to that school within 24 hours of our awareness, so that the school, as controller, can decide on its own notifications. Where we are the controller, a personal data breach that must be reported is reported to the Information Commission without undue delay and within 72 hours of our awareness. Not every security incident is a personal data breach, and not every breach has to be reported; we record every breach either way. See the status page for how we communicate.
Backups and recovery
Applications are stateless images; redeploying or rolling back takes minutes (measured 3 to 6 minutes per application on 11 October 2026). The database provider takes daily backups and keeps each for 7 days on our current plan. A record deleted or redacted in the live database remains in the backups taken before, until they rotate out.
Deterministic governance and the Passport record
The 34 control results, the outcome and the required actions are computed deterministically by the published pack: fixed rules, so the same answers always produce the same result. Since 3 November 2026 the production assessment path calls no artificial-intelligence or large-language-model service at all, and the service refuses to record any result that does not come from that deterministic engine with a verified binding to the submission (measured in the deployed configuration and its tests). Every result is held for a person to review; a Passport becomes publicly verifiable only after that release, and only when the published identity — the submission, the answers, the input and the result digests — matches the recorded result exactly. A Passport withdrawn after release is shown as withdrawn on the verification page. See the sub-processor page.
Sub-processor management
Every provider that processes data is listed on the sub-processor page with its location and the terms in force, and we give 30 days' notice of changes. The page shows the status of each provider's agreement.
What is not in place
Stated so that a school can judge: no independent penetration test; no ISO 27001, SOC 2 or Cyber Essentials certification; deletion is a written manual procedure, not an automated purge; a signed-in session cannot be revoked by us before it expires (signing out removes it; a session lasts at most 12 hours); the multi-factor-authentication status of the operator's provider consoles has not yet been recorded.
Reporting a vulnerability
Email contact@viccaone.com with "SECURITY" in the subject. Helpful: the page or endpoint, what you did, what you saw, and how we can reproduce it. We acknowledge within 2 working days and tell you what we did when it is fixed. We do not run a bounty programme and do not promise payment. Good-faith research within the limits in our acceptable use policy will not be pursued. If you believe personal data has been exposed, put "BREACH" in the subject and we treat it as an incident from the moment we read it.
Version history: 1.0 (12 October 2026); 1.1 (26 October 2026) — the signed-in register's controls (sign-in without passwords, server-side authorisation, tenant isolation, hashed invitations, session cookie, auditable history) and what is not in place. 1.2 (1 November 2026) — the narrow redaction exception to the unchanged history; tool records per school; breach notification as processor and as controller; backup period. 1.3 (3 November 2026) — at a glance; deterministic governance and the bound Passport record (no model provider since 3 November 2026); the register's tables and the redaction route applied to production.