Security

How VBRI Group protects your organization's data — what happens when you sign in, how your records are kept separate from every other organization, and what is encrypted.

This page describes the controls that are live in the product today.

Connections are encrypted in transit

Every request between your browser and VBRI Group travels over HTTPS. Plain http:// requests are permanently redirected to https://.

Alongside HSTS, responses carry a set of browser-hardening headers: X-Frame-Options: DENY (VBRI Group cannot be embedded in another site's frame), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin (your CRM URLs are not leaked to third-party sites), and a Permissions-Policy that switches off camera, microphone, geolocation and payment APIs the CRM never uses.

Signing in

VBRI Group supports three ways to sign in, and you can use whichever your organization prefers.

• Email and password. Passwords are never stored. Each one is put through scrypt — a deliberately slow, memory-hard hashing function — with a unique random salt per user. Comparison is timing-safe, so the server's response time reveals nothing about how close a guess was.
• Google. A full OpenID Connect sign-in. Google verifies who you are and VBRI Group validates the signed identity token.
• GitHub. OAuth 2.0 sign-in.

Both social sign-ins use PKCE and a one-time state value, which prevents an attacker from replaying or injecting an authorization response.

One deliberate restriction: a social identity is never silently merged into an existing password account. If someone signs in with Google using an email address that already has a password account with VBRI Group, the sign-in is refused rather than joining the two. This closes a common account-takeover route.

Resetting a password

When you request a reset, the emailed link contains a single-use token. VBRI Group stores only a SHA-256 hash of that token, never the token itself — so the reset link cannot be recovered from the database. Tokens expire after one hour and are invalidated once used.

Your session

After signing in you receive a session cookie. It is:

• Encrypted, not merely signed — the contents are opaque to the browser and to anyone inspecting network traffic
• HttpOnly — unreadable by JavaScript, so a script cannot steal it
• Secure — never sent over a plain HTTP connection
• SameSite=Lax — not sent along with cross-site requests, which blocks cross-site request forgery
• Named with the __Host- and __Secure- prefixes, the strictest cookie protections browsers offer; they stop a subdomain from overwriting your session cookie

Keeping organizations separate

This is the most important control in a CRM that hosts many organizations, so it is worth explaining in full.

Every record in VBRI Group carries the id of the organization that owns it — every lead, contact, deal, invoice, email, call and workflow. Every query the application makes is filtered by that id.

The id itself is never taken from the browser. On every single request, VBRI Group looks up your membership in the database and derives your active organization from that record. A membership row is the only thing that can produce an organization id for a request.

That has three practical consequences:

1. You cannot ask for another organization's data by changing something in your browser. Your session does not carry an organization id that you control — it carries your identity, and the organization is resolved from the database each time.
2. Switching organizations is verified server-side. If you belong to more than one organization, the switcher re-checks your membership before the switch takes effect. Naming an organization you do not belong to simply does not switch you.
3. Revoking someone's access takes effect immediately. If a membership is removed while that person is signed in and viewing that organization, their next request finds no membership and falls back to one they still hold. There is no window where a removed member keeps reading data.

How support access works

When VBRI Group staff need to look at an organization to help with a support request, that access never runs through a normal user session. A staff request cannot simply "become" your organization: the organization is named explicitly, for one operation at a time, through a separate and narrow code path.

That path lives in a platform console that is entirely separate from the product you sign in to. What it shows is deliberately limited:

• Counts and directory information only — how many leads, deals and members an organization has, who its members are, when it was last active. It does not show your leads, contacts, email contents, documents, call transcripts or notes.
• Never your credentials. Integration settings — SMTP passwords, Meta tokens, API keys — are not readable through it at all.
• Read-only. No member of staff can change your data, your plan or your settings from it.

Opening an organization or a user record writes an audit entry recording who looked, at what, when, and from which address. That record is kept separately from your own organization's audit log, so deleting an organization cannot erase the evidence of what staff did with it.

Access is granted by naming a specific account in the server's configuration, is re-checked from the database on every request rather than carried in a sign-in token, and takes effect within a minute of being revoked. Staff accounts hold no membership in any customer organization, so even a complete failure of the platform check leaves them with no organization to read.

Two limits worth stating plainly: browsing the organization and user lists does not write an audit entry — only opening an individual record does — and the console does not yet require staff to record a reason for looking.

Enforced, not just intended

The rule that an organization id may only come from a verified membership is checked automatically. An automated guard runs against the codebase and fails the build if anyone changes the sign-in code in a way that would let a session carry an organization the user is not a member of — including subtler variants, such as removing the user filter from the membership lookup. The separation between organizations is therefore a property the build enforces, not a convention a future change could quietly undo.

Who can see what

Access inside an organization is controlled by two layers.

Access level — every member is an Administrator, a Member, or a Viewer.

Custom roles — you can define roles that match how your team actually works ("Sales Manager", "Marketing"), each mapped to one of those access levels, with per-area overrides.

Around three dozen individual permissions (leads, opportunities, billing, workflows, integrations, team management, AI features, and so on) are checked on the server for every request. Hiding a button in the interface is never the control: a request for something you lack permission for is refused by the server regardless of how it was sent.

One thing worth being clear about: permissions govern areas of the product, not individual records. A Member who can view leads can view all of that organization's leads. Per-record and per-field restrictions are not available today.

What gets recorded, and where you can read it

VBRI Group keeps an activity log for your organization, which any administrator can read under Settings → Activity Log. You do not have to ask us for it.

It records who did what and when: records created, changed and deleted, along with sign-ins and sign-outs. Each entry carries the person, the record, the action, the time, and the address and device the request came from.

Three details worth knowing:

• Automated actions are attributed too. When a workflow updates a lead, a drip campaign sends an email, or a scheduled job runs, the entry names the component that acted rather than leaving it blank, so an automated change is never mistaken for a person's.
• The log records what changed, not the contents. Entries hold identifiers and field names, never message bodies, transcripts or credentials.
• Sign-in history starts from 7 September 2026, when this was switched on. Earlier activity is not retrospectively available.

How AI features handle your data

VBRI Group's AI features — lead scoring and the Customer Brief, the Copilot, call and meeting notes, AI-written drip emails and generated landing pages — are powered by Mistral AI, which is therefore a sub-processor for that content.

What this means in practice:

• The text sent is the material the feature needs: for a lead brief, that lead's own emails, calls, meetings and notes; for the Copilot, your question and the records it looks up to answer.
• Content is sent for processing and a result is returned. How the provider may retain or use it is governed by their API terms, which you should read if this matters to you.
• The model used is chosen per organization in Settings → Organization → AI Configuration, and AI spend is metered per organization so you can see what is being consumed.
• If you self-host VBRI Group, the provider key is your own, so the data goes to your account under your own contract.

Data stored in VBRI Group

Integration credentials are encrypted at rest with AES-256-GCM — Meta access tokens and app secrets, SMTP passwords, DNS provider API keys, and Conversions API tokens. The encryption key lives in the server environment, never in the database, so database access alone does not reveal them.

Once saved, these credentials are shown back to you masked (•••• plus the last four characters). API keys you generate are displayed in full exactly once, at the moment of generation.

Your CRM content — leads, contacts, notes, transcripts and email bodies — is stored so that the application can search and display it, and is protected by the access controls above and by encryption of the underlying storage and backups at the infrastructure layer.

Connecting other systems safely

VBRI Group receives data from outside systems through several channels, each authenticated:

Website capture also silently discards submissions that fill a hidden honeypot field, which removes most automated form spam without adding a CAPTCHA.

Email, tracking and consent

Automated email from VBRI Group — drip campaigns, workflow emails and Copilot mail — includes a one-click unsubscribe link and the List-Unsubscribe headers that Gmail and Yahoo require of bulk senders.

Unsubscribes are honoured centrally. When someone opts out, the suppression is enforced in the single place all mail passes through, so every sending feature respects it — not just the one they unsubscribed from. Transactional messages that are not marketing, such as team invitations and password resets, are unaffected.

If you enable open and click tracking, VBRI Group records when a recipient opens a message or follows a link, and shows this on the lead's timeline. A per-organization daily send limit caps outbound volume to protect your sending domain's reputation.

Reporting a security issue

If you believe you have found a vulnerability in VBRI Group, please report it privately to [email protected] rather than raising it in a public channel.

Helpful things to include: what you observed, the steps to reproduce it, and the approximate time of your testing. Please do not access, modify or retain data belonging to other organizations while investigating — a description of the issue is enough for us to reproduce it ourselves. We will confirm receipt and keep you updated while we work on a fix.

Continuing work

Security is not a finished state. Areas actively being strengthened include multi-factor authentication, self-service tools for exporting and erasing personal data, a required reason on staff access to an organization, and per-record and per-field permissions. This page will be updated as those ship.

Recently added: a customer-readable activity log with sign-in history, and automated attribution for actions taken by workflows and scheduled jobs.