Security
Every control published, every provider named.
Generation runs at Mistral in France, a company with no parent outside the European Economic Area. Documents are stored in Ireland by a US-incorporated provider. Our sub-processor register lists every provider, its country of incorporation and its parent.
Tenant isolation
Row-level security in PostgreSQL limits every signed-in request to the user's own data and the workspaces they belong to. Background jobs run with a service role that bypasses these policies, so their queries are scoped in code.
Role-based access control
Workspace roles decide who can view the audit trail, manage members, write or delete documents, and manage billing.
Append-only audit trail
Questions, document views, downloads and administrative actions are recorded with who acted, their IP address and the time. The address is encrypted when it is recorded, shown only as its network, and unreadable by anyone after 30 days, when its key is destroyed; until then only the workspace owner can reveal it in full, and each reveal is itself recorded. The database refuses edits to recorded entries, and a hash chain shows whether a row was changed.
Data protection
What your data is used for
Your documents, questions and answers are processed to provide the service to you and for no other purpose. We never sell them, and every provider that processes them is named in our sub-processor register.
Where it runs, and who can reach it
Jurisdiction and region
Residency says where data sits. Jurisdiction says who can compel access to it. Generation and embeddings run at Mistral, a company incorporated in France with no parent outside the European Economic Area. The database and file storage that hold your documents in Ireland, our request path, cache and error monitoring run on US-incorporated providers while we migrate to our own EU infrastructure. Our sub-processor register marks each one.
Documents stored in the EU
Generation and embeddings run in France. Documents are stored in Ireland. Some of our providers are incorporated outside the European Economic Area, so their remote access counts as a transfer under GDPR Chapter V. Our sub-processor register names every provider and the transfer basis that applies to it.
Who at Nordvec can see your data
The product has no impersonation and no support login: there is no path for us to open your documents or conversations through the application. We run an internal operations console so we can operate the service: it shows counts, quotas, subscription state and system health. The console cannot read your documents, conversations, messages or connector credentials, because the database role it runs as holds no privilege on those tables, and a database control verifies that against the live database before every release. Our operator console can place a hold on a workspace or reveal its name, and each such action records a typed reason and is copied into your audit trail. Our two founders hold infrastructure-level database access. That is standing access we cannot remove while we run on managed infrastructure, and it does not appear in your audit trail. You can export the trail as CSV or JSON, filtered by date and action.
How it is protected, and what that covers
Encrypted at rest and in transit
The database and file storage are encrypted at rest with AES-256, and connections use TLS. OAuth tokens are also encrypted by the application before they are stored.
Key custody
Our platform provider holds the encryption keys today, not us and not you. That decides what encryption at rest is worth: it protects a decommissioned or stolen disk, not a compromised credential on a running system. We do not offer customer-managed keys. Key custody becomes ours when we move to EU hardware, with an EU-resident key and a stated rotation policy.
Why the search index is not separately encrypted
Encrypting the text and vector columns individually would break the index that makes vector search possible, and on managed infrastructure the key would still sit with the provider. These columns are covered by the database's encryption at rest and by row-level security.
Backup scope
There is no backup of the database today: the provider plan the service runs on takes none, so a deletion is final and no restore can bring back data you asked us to delete. When we introduce our own backups they keep at most eight days of history, and any restore replays recorded erasures before the service returns.
How the code is tested
Before code reaches the main branch, local gates run static analysis (semgrep) on the changed files, dependency vulnerability, malware and licence audits, and secret scanning on every commit. A release cooldown keeps newly published package versions out of the build. We do not hold an independent penetration test.
What we do with it
No AI training on your data
Nordvec never uses your data to train, fine-tune or improve an AI model. To answer a question, the model receives the passages search selected and any document the assistant opens in full.
No sale of your data
We never sell your data or share it for anyone else's purposes. Every provider that processes it on our behalf is named in our sub-processor register.
Deletion when you disconnect
Disconnecting a connector queues a deletion job. It removes the connector's file references, then deletes each document that no other source still references, with its embeddings and stored files. These documents do not pass through the trash.
Infrastructure
Access control from the proxy to the database
A token check in the proxy, row-level security in the database, and an append-only audit trail.
Sign-in and multi-factor authentication
Nordvec has no second factor of its own yet. A sign-in through Google or Microsoft carries whatever multi-factor authentication the Google or Microsoft account used requires; a sign-in with an email and password is one factor, and any account can set a password through a reset email, so a workspace cannot yet require its members to sign in through a provider. Sensitive actions, such as deleting an account or creating an API key, require a sign-in within the last five minutes.
Token check in the proxy
The proxy verifies each session token's signature and checks that the session has not been revoked before a request reaches a route handler.
Database-level access control
Row-level security (RLS) policies are the access check inside PostgreSQL, and a test suite runs each table's policies against a real database.
What the audit trail leaves out
A question is recorded with the number of sources it used, never the text of the question or the answer. That record is written after the answer, and a failed write is logged instead of blocking you. Entries older than the retention period are deleted on a schedule.
Rate limiting and abuse prevention
API endpoints are rate-limited per user and per IP address, and sign-in attempts per address, to slow credential stuffing and account enumeration.
Certifications and standards
What we hold, and what we do not.
GDPR
A regulation, not a certificate: the controls behind it are published on the trust board. They include self-service access and portability (Art. 15, 20), account erasure after a waiting period you can cancel (Art. 17), and security of processing (Art. 32).
EU AI Act
We assess Nordvec as a limited-risk AI system, so the transparency duties of Article 50 apply. Each AI Act obligation we track, including the risk classification itself, is published on the trust board with its status.
SOC 2 Type II
Not held. Our status against each SOC 2 criterion is published on the trust board, and the OSCAL export lists the evidence. An external audit is a funding decision, and we will not describe it as scheduled until it is booked.
ISO 27001
Not held. Our information-security controls are published with their evidence and exported as OSCAL, which you can load into your own tooling.
Responsible disclosure
Report a vulnerability to security@nordvec.com. We acknowledge within 72 hours, give you a triage severity within 5 business days, and keep you updated until it is resolved.
Safe harbour
We will not pursue or support legal action against researchers who act in good faith, follow this policy, avoid privacy violations and service degradation, and give us a reasonable opportunity to remediate before disclosure. If you are unsure whether an action is authorised, ask us first.
Before you test
Only interact with accounts you own or have permission to use. Do not access other tenants' data, run scanning that degrades the service, or disclose an unfixed issue publicly. We ask for a coordination window of up to 90 days before public disclosure, and we credit reporters who want to be named. If you used a generative AI tool at any stage, tell us how; it helps us triage and does not count against your report.
Our process follows ISO/IEC 29147 (disclosure) and ISO/IEC 30111 (handling), and the coordinated-disclosure duty of the EU Cyber Resilience Act (Regulation (EU) 2024/2847, Art. 13). Ask security@nordvec.com for our remediation targets. This contact and policy are also published in our security.txt file (RFC 9116).
We do not run a paid bug-bounty programme. We recognise good-faith reports with public credit, not payment.
Get in touch.
Security contact
security@nordvec.comSecurity inquiries
Questions about our security architecture, data handling or compliance. We send documentation on request.