NordivéSecurity / Technical documentation
See how
your data is protected.
Architecture, encryption, operations and the agreements behind Nordivé. Find our detailed security documentation here.
How your data is handled
Nordivé has no database for email content. The backend runs on Azure in Norway East and sends AI requests to language models in the EU — Azure OpenAI (EU data zone, resource in Sweden) and AWS Bedrock (Ireland). Email content passes through in transit only and is not stored by us. Analysis results are stored in the lawyer’s own OneDrive, in Nordivé’s app folder.
AI models and storage
Email is sorted and replies are drafted using the Terra and Sol language models in Microsoft Azure OpenAI, deployed in the EU data zone. Document analysis uses Anthropic’s Claude Sonnet 4.6 and Opus 4.6, delivered through AWS Bedrock in Ireland. This means:
- Nordivé does not store requests. Neither does AWS Bedrock; Microsoft may temporarily retain requests flagged by abuse monitoring within the EU.
- Correspondence and documents are never used to train AI models.
- Logs contain only technical metadata — never the content of client communications.
- All inference takes place in the EU — no transfer to the US.
Built on ISO 27001-certified infrastructure
Nordivé is not yet independently ISO 27001 or SOC 2 certified — as an early-stage company, we plan to begin SOC 2 Type I when we reach 50 paying customers. What we deliver today is built on infrastructure that is certified: Microsoft Azure (Norway East) for the backend, AWS Bedrock for AI inference and Vercel for the frontend. Client content is never stored by Nordivé. What we do store (operational data such as usage counters and support) is kept in the same certified Azure environments — never in a separate, uncertified storage solution. Full audit reports from our providers can be shared on request through their respective trust portals.
Access control and sign-in
Sign-in uses Single Sign-On with existing Microsoft 365 accounts. Your firm’s existing access control rules, multi-factor authentication and conditional access policies also apply to Nordivé. No new passwords or accounts.
OAuth follows the PKCE standard (without exposing passwords to us). Refresh tokens are encrypted locally using AES-GCM 256 and automatically deleted after 8 hours of inactivity or explicit sign-out.
Token revocation at sign-out — clarification: Microsoft Graph (our Outlook integration) does not support public refresh-token revocation for SPA applications. When you sign out, Nordivé immediately deletes the local copy, but the underlying refresh token at Microsoft remains until its natural expiry (typically 14–90 days) or until your IT administrator invalidates it through the Azure AD console (Sign-in > Revoke sessions, or a Conditional Access policy). For Google Gmail mode, we revoke the token at Google (oauth2.googleapis.com/revoke) at sign-out.
Browser security
The frontend is delivered with a strict Content Security Policy that blocks external scripts and iframes. X-Content-Type-Options: nosniff prevents MIME spoofing, and Permissions-Policy prohibits camera, microphone and location access (we do not need them). All AI output is rendered through React JSX, which automatically escapes content — no dangerouslySetInnerHTML in the codebase.
Data processing agreement
Before onboarding, a data processing agreement is signed in accordance with GDPR Article 28. The law firm is the data controller and Nordivé is the data processor. The agreement specifies what data is processed, for how long, by whom and how. A template can be shared on request.
How we approach AI errors
Nordivé generates drafts only. Nothing is sent, saved or archived without the lawyer’s explicit approval. Responsibility for legal assessments always remains with the lawyer — we are a tool, not a replacement for professional judgement.
Questions about security?
We welcome specific questions from IT security or compliance teams. Email kontakt@nordive.ai and we will connect you directly with the team.
Status and roadmap for compliance.
We take compliance seriously. Here is where we stand and what we are working towards.
Subprocessors
The following third parties process customer data on Nordivé’s behalf. The list is updated when changes occur, and customers are notified 30 days before new subprocessors are introduced (see section 6.2 of the data processing agreement).
| Subprocessor | Service | Data centre | Certification |
|---|---|---|---|
| Microsoft Corporation | Azure Functions, Azure OpenAI (Terra, Sol), Storage, Key Vault, Entra ID, Microsoft Graph (Outlook/OneDrive) | Norway East (Oslo); Azure OpenAI in the EU data zone (Sweden) | ISO 27001, ISO 27018, SOC 2 Type II |
| Amazon Web Services, Inc. | AWS Bedrock (AI inference through Claude) | eu-west-1 (Ireland), EU inference profile | ISO 27001, SOC 2 Type II |
| Anthropic PBC | Claude AI model (runs through AWS Bedrock, without request storage) | Through AWS — no direct data access | SOC 2 Type II |
| Vercel Inc. | Frontend hosting (static content for app.nordive.ai) | European nodes | SOC 2 Type II |
All data is processed in the EU/EEA. No transfers to third countries (the US, India or others) take place in normal operations. The full subprocessor list is available in the official document (Norwegian).
Encryption overview
All data is encrypted in transit and at rest. Storage keys are managed by Microsoft. For most files in OneDrive, Nordivé adds an encryption layer with a key derived from the user’s Microsoft ID; this layer is not end-to-end encryption.
| Data type | In transit | At rest | Key management |
|---|---|---|---|
| Email content (during analysis) | TLS 1.2+ (Microsoft Graph → Nordivé → EU language model) | Never stored by Nordivé | n/a |
| Chat history | TLS 1.2+ | AES-GCM 256-bit in the customer’s own OneDrive | Key derived from the user’s Microsoft OID (not end-to-end) |
| Vault documents | TLS 1.2+ | Remains in the customer’s OneDrive (AES-256, managed by Microsoft) | Microsoft tenant-keys |
| Matters, templates, workflows | TLS 1.2+ | JSON in the customer’s OneDrive AppFolder | Microsoft tenant-keys |
| OAuth tokens (refresh) | TLS 1.2+ (PKCE) | AES-GCM 256 in browser localStorage | User-derived key |
| Backend logs | TLS 1.2+ → Azure Monitor | AES-256, Azure Storage | Azure-managed (Microsoft-managed keys) |
Vulnerability scanning
Dependencies and code are continuously scanned for known vulnerabilities, and the build stops on high-severity findings.
- Dependabot — alerts on known vulnerabilities in JavaScript dependencies
- npm audit is run manually before release. It is not a CI gate that stops the build
- We do not have GitHub Advanced Security and do not run CodeQL. Source code is scanned for secrets using Gitleaks in the GitHub workflow, but this is not yet a requirement before merging
Nordivé is a small company. We describe our practices as they are, rather than as they might look at a larger organisation.
- Changes are committed directly to
main. We do not currently require pull requests with a reviewer - Type checks, unit tests and builds are run locally before each deployment, rather than as a CI gate. This means the gate is a person, not a machine
- Deployment is from a clean git worktree at an explicit commit, never from a working copy. Marker strings are counted in the published bundle before and after to confirm the correct version is live
- The desktop panel has a denylist that fails the build if the code uses an API capable of reading the screen, keystrokes or document content. This can be independently checked using
stringson the binary - Rollback is performed by redeploying the previous commit
- We plan to launch a public bug bounty programme through HackerOne or Intigriti when our user base warrants it
- Until then, responsible disclosure reports can be sent to kontakt@nordive.ai (subject: “Security report”)
- Researchers who report in good faith and keep findings confidential will be acknowledged in a hall of fame (when launched)
Incident response
In the event of a security breach, we follow a defined process for detection, notification and remediation. The timeframes below reflect what we can meet with our current staffing.
| Classification | Example | Initial response | Customer notification |
|---|---|---|---|
| P0 – Critical | Confirmed data loss, outage exceeding one hour | Same day | Without undue delay, within 24 hours if possible |
| P1 – High | Exploited vulnerability, authentication failure | Within one business day | Without undue delay, within 24 hours if possible |
| P2 – Medium | Degraded performance, non-critical misconfiguration | Within two business days | By email as needed |
| P3 – Low | Logging irregularities, cosmetic issues | At the next regular update | None |
For P0/P1 incidents that may affect personal data, we notify the data controller (the law firm) directly by email. The controller notifies the Norwegian Data Protection Authority within 72 hours under GDPR Article 33, and we assist with the required information. We do not have a dedicated status page.
Availability and uptime
The backend runs in Azure Norway East with automatic scaling. Uptime is a target, not a guarantee:
| Plan | Availability | Maintenance | Status notification |
|---|---|---|---|
| All plans | 99.5% target (best effort) | Advance notice where possible | |
| Separate agreement | Contractual service level by written agreement | As agreed | As agreed |
Recovery targets: RTO 24 hours (recovery time objective) and RPO 24 hours (recovery point objective) for configuration and code. Source code is held in GitHub. Operational data in Azure Storage is locally redundant in Norway East, without a separate backup. Client content is in the firm’s own OneDrive.
Compliance matrix
Requirements and frameworks addressed by Nordivé, and where to find documentation:
| Requirement / framework | What it covers | Status | Documentation |
|---|---|---|---|
| GDPR / Norwegian Personal Data Act | Privacy, data subject rights, data minimisation | Compliant (self-assessed) | Privacy policy (Norwegian) |
| Data processing agreement (GDPR Article 28) | Controller–processor relationship | Signed with each customer | Template on request |
| Lawyer’s duty of confidentiality | Client confidentiality | Built into the design | Security architecture document |
| Norwegian Bar Association AI guidelines | Use of AI in legal practice | Used as a basis | Self-assessment |
| NSM Basic Principles for ICT Security | Norwegian security baseline | Used as a reference (self-assessed) | Security architecture document |
| OWASP Top 10 / ASVS L2 | Web application security | Baseline | Internal review |
| SOC 2 Type I | Security controls (design) | Not started | Planned from 50 paying customers |
| SOC 2 Type II | Security controls (operational) | Not started | No earlier than 12 months after Type I |
| ISO 27001:2022 | Information security management | Not started | After SOC 2 Type II |
Official documents
The following documents describe Nordivé’s security and privacy practices in detail. They are updated when material changes occur; the current version is shown in the header.
Internal security
Security starts with the people building and operating Nordivé. We have the following internal controls:
- Two people currently have access to production. We state this plainly, because “least privilege” and “CTO approval” mean little with so few people
- Production access requires multi-factor authentication on the Microsoft account
- We have no database of client content. Email, documents and meeting notes are processed in memory and stored in the firm’s own OneDrive. The backend can still read and write to the app folder on the user’s behalf when background analysis is enabled, and you may choose to include client information in a support thread
- As the team grows, onboarding and offboarding procedures will be introduced and described here once they exist
- The computer used for development and operations has disk encryption (FileVault)
- We do not currently have MDM, centrally managed antivirus or remote device wiping
- We do not currently conduct background checks, regular security training or phishing exercises
- Confidentiality agreements and training procedures will be introduced before new people are given access
- API keys and credentials are stored as encrypted application settings in Azure or in Azure Key Vault — never in source code
- We do not currently have scheduled, automatic key rotation
- Secrets must not appear in logs or in code sent to the browser
- Source code is scanned for secrets using Gitleaks in the GitHub workflow
Report a security issue
Have you discovered a vulnerability or suspect a security issue? We acknowledge reports within 48 hours.
Send details to kontakt@nordive.ai with the subject “Security report”. Include:
- A description of the vulnerability and where it was observed
- Steps to reproduce the issue
- Potential impact if exploited
- Any proof-of-concept attachments
We commit not to take legal action against researchers who report in good faith and keep findings confidential until remediation. A bug bounty programme is under consideration for 2027.
Get to know Nordivé
See what you can capture.
And what you can make time for.
See how time tracking and email can fit
into your working day. We will show you the product.