Security

Vandorisk is a compliance product, so a vague security page would be self-defeating. What follows describes the controls that are actually implemented in the running application, the third parties that process data on our behalf, and — in the same detail — the things we do not have yet.

Who you would be contracting with

Vandorisk is operated by its founder, and the operating company is being incorporated in the European Union. Until that completes the contracting party is the founder trading as Vandorisk, not a limited company. A security review usually asks this early, so it is here rather than buried in the terms.

When incorporation completes, the terms will name the entity, its registration number and registered address, and the member state whose law governs. If you need a named counterparty, a registration number or a specific governing law before you can proceed, write to hello@vandorisk.com and we will tell you exactly where that stands. See also the vulnerability disclosure policy for how to report a problem in this product.

Hosting and data location

The application runs on Vercel, and customer data is stored in a managed Neon PostgreSQL database. Traffic is served over TLS; the database is reached over a TLS-required connection.

Hosting region:the deployment region is a provisioning setting rather than something fixed in the product, so we do not assert a region on this page where we cannot point at the configuration that proves it. For the current region of the application and the database in writing — and for a Data Processing Agreement naming it — email hello@vandorisk.com. See also the Terms.

Subprocessors

These are all of them. Beyond Vercel’s cookieless web analytics below there is no third-party analytics, no session-replay tool, no chat widget and no advertising pixel anywhere in the product — which is also why Vandorisk shows no cookie banner: it sets no cookie that is not strictly necessary to run the service.

Encryption at rest for the database and its backups is provided by the platform operator. We rely on their controls for it and have not independently verified them.

Authentication and sessions

• Sign-in is email and password (bcrypt, TOTP two-factor optional) or OIDC single sign-on per organisation— an owner configures the issuer, client and permitted email domain at /sso, and accounts from that domain are provisioned on first sign-in with a default role. No SAML (see the gaps below).
• Sessions are signed HS256 JWTs in an httpOnly, SameSite=Lax, Secure (in production) cookie. The token is never readable by page scripts.
• A session lasts 24 hours and slides forward while in use (re-issued once a token passes 12 hours old), with a hard 7-day cap measured from first sign-in that no amount of activity extends. An idle or stolen cookie dies within 24 hours of its last issue regardless.
• Every session carries a token version that is checked against the database on every request. Logging out, changing your password, completing a password reset, or turning off two-factor authentication increments it, which revokes every outstanding session for that account immediately— including a cookie an attacker already copied. On a shared evaluation account this is visible as everyone being signed out when one person logs out; that is the design, not a fault.
• The session check fails closed but honestly: if the database is unreachable, the request is answered as a temporary server error to be retried, never as “your session is invalid” — so an infrastructure blip cannot masquerade as a revoked sign-in. A revoked or expired session is still refused outright.
• The organization and email a request runs under are re-read from the database on every request rather than trusted from the token, so an account change takes effect at once instead of persisting for the life of a session.
• A second, non-secret cookie carries the flag “a session exists” and nothing else — no token, no identity — so the header can render without a database read on anonymous traffic.
• The application refuses to start in production without a session signing secret of at least 32 characters that is not the development default.

Passwords

• Passwords are hashed with bcrypt at cost 12. Plaintext is never written to the database, to logs, or to the audit trail.
• New and changed passwords must be at least 10 characters, must not be a known common or breached-list password, and must not contain the local part of the account’s email address. The same policy applies to a reset and to a change; login stays permissive so accounts created under older rules are not stranded.
• Password-reset tokens are stored as SHA-256 hashes, expire, are single-use, and redeeming one invalidates every other outstanding token for the account.
• Sign-in returns the same message for an unknown email and a wrong password, and the two paths are deliberately equalised in wall-clock time so account existence cannot be inferred from response timing.

Two-factor authentication

• Available to every account today, self-service under Account settings. Standard TOTP (RFC 6238, SHA-1, 6 digits, 30-second period) with a ±30-second acceptance window, so any authenticator app works.
• The implementation is written against the RFC using the Node standard library only, with no third-party dependency in the authentication path, and is tested against the RFC’s own published test vectors.
• Enrolment is confirmed by a working code before the second factor is switched on, so a half-finished setup cannot lock anyone out.
• Ten single-use recovery codes are issued once, at enrolment, and stored only as SHA-256 hashes. A database dump does not yield usable codes; a spent code is removed from the account the moment it is used.
• The code is checked on the same requestthat verifies the password. There is no separate “complete MFA” endpoint and no intermediate token, so the password step cannot be skipped by calling something else.
• Turning the second factor off requires both the current password and a current code, so a stolen session alone cannot remove it.

Tenant isolation

Every product, assessment, response, evidence record and document export is owned by an organization, and every read and write is filtered by the organization on the caller’s verified session — never by an identifier supplied in the request. Asking for another organization’s record returns the same “not found” as asking for one that does not exist, so identifiers cannot be probed for existence. Cross-tenant access is covered by automated tests that attempt the access and assert it fails.

Abuse controls

• Sliding-window rate limits on every authentication and mutation route, keyed on the caller’s IP, with a second per-account limit on the sensitive ones so rotating IPs does not evade them. Sign-in allows 20 attempts per 15 minutes per IP; password reset, 10; changing a password, 5 per account per 15 minutes.
• After 10 failed sign-ins an account is flagged for 15 minutes. The flag is recorded and audited but is deliberately non-blocking: the correct password is always honoured and clears it, so an attacker cannot use failed guesses to lock a customer out of their own account. A failed second-factor code counts toward the same accounting.
• CSRF defence is SameSite=Lax session cookies plus an origin check on every mutating route.
• Security headers on every response: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a Content-Security-Policy that restricts scripts, styles, images and network connections to the application’s own origin and forbids framing (see the caveat under What is not in place), a strict referrer policy, and a permissions policy denying camera, microphone and geolocation. HSTS is applied where the deployment enables it, and deliberately never in local development so a developer machine cannot be pinned to HTTPS.

Honest limitation: rate-limit counters live in the application instance’s memory. On a multi-instance deployment the effective limit is per instance rather than global. Moving the counters to a shared store is on the roadmap; the per-account limits and the durable failed-login accounting in the database are not affected.

Audit trail

Security and data events are appended to a per-organization audit log with a timestamp, the acting account, the action, and the affected record. It covers sign-in, failed sign-in, sign-out, rate-limit denials, password reset and change, two-factor enrolment, use of a recovery code and removal of the second factor, and creation, modification and deletion of products and assessments.

Passwords, session tokens, TOTP secrets and recovery codes are never written to it. The log is readable by the owning organization and is included in the data export.

Data export and deletion

• Export at any time, without asking us: the technical documentation, Annex II and Declaration of Conformity drafts as Word documents, plus a complete machine-readable JSON export of the whole workspace — products, assessments, responses, evidence items and the audit log.
• Delete in-product: deleting a product removes its assessment and every response with it, in one transaction, so a half-deleted product cannot be left behind.
• Full account and organization deletionremoves everything the organization owns — including the audit log — in a single transaction. It is restricted to the workspace owner and requires the workspace name to be typed to confirm. Export first: it is not reversible and we do not keep a copy. If you cannot reach it, email hello@vandorisk.com.
• Retention after termination follows section 7 of the Terms. Note the obligation that sits on you rather than on us: the CRA requires the manufacturer to keep technical documentation for 10 years, so export before your term ends.

The rule pack is public

Vandorisk’s central claim — deterministic evaluation, nothing generated at answer time — is only worth something if you can check it. So the rule pack the product evaluates is published: every requirement with its citation, the conformity-route verdicts, the classification scoping and a versioned changelog are at /pack, rendered from the same file the engine reads, with the raw JSON at /api/packfor diffing between versions. If your counsel reviews one thing before trusting the product’s output, it is that page.

What is not in place

Stated plainly, because you will ask and because a page that omits this is not worth reading:

• No SOC 2 report and no ISO 27001 certificate. Neither is in progress at the time of writing.
• No third-party penetration test report. Security work to date is design review, threat modelling and automated tests by the engineering team.
• No SAML and no SCIM provisioning. Single sign-on exists as OIDC per organisation (Okta, Entra ID, Google Workspace — configured at /sso with a per-org email-domain gate); SAML-only identity providers are not supported, and users are provisioned on first sign-in rather than synced by SCIM.
• No customer-managed encryption keys and no bring-your-own-key option.
• No contractual uptime SLA except where one is agreed in an order form, and no 24/7 on-call rotation. Support is by email during business hours.
• No hardware-key (WebAuthn/passkey) second factoryet — TOTP only.
• The Content-Security-Policy still permits inline and evaluated scripts, which the framework requires until a nonce pipeline is in place. It is a real weakening of the XSS defence and we would rather name it than quietly ship a policy that reads stricter than it is.
• The incident-response plan is written but thinly exercised.There is a real one — severities, containment steps, the notification clocks and what we would actually do in the first hour — and we will send it to you on request. What it does not have is depth of practice: one drill has been run, and it found that our own alerting channel was unconfigured. That finding is in the plan’s register rather than tidied away, because a first drill that finds nothing is a first drill that was not honest.
• No business-continuity policy, no on-call rotation, and no tested restore. One person, working hours, best effort. Backups exist for the self-hosted path but a restore has not been rehearsed on the live platform. We would rather say that than imply a recovery time we have never measured.

Report a vulnerability

If you have found a security issue in Vandorisk, please tell us before you tell anyone else. Email hello@vandorisk.com with “security” in the subject line and enough detail to reproduce it: the affected URL or endpoint, the steps, and what you were able to access or change.

We do not currently run a paid bug bounty. In return for reporting in good faith — testing only against your own account, not accessing or modifying other customers’ data, not degrading the service, and giving us a reasonable window before disclosure — we will not pursue legal action over your research. That good-faith window is the exception to the “no security testing without our written permission” line in section 4 of the Terms.

Questions

Security questionnaires, a Data Processing Agreement, the current hosting region in writing, or anything else a review needs: hello@vandorisk.com. If something on this page is out of date or wrong, telling us counts as a security report.