Features
When you move your compliance programme into a SaaS platform, you hand over genuinely sensitive material: your risk register, your incident records, your ICT provider contracts, your audit evidence, your gap assessments. It is the kind of data a regulator asks about and a competitor would like to read. So a fair question to put to any vendor is a simple one: who, on your side, can see my data, and when?
For most SaaS products the honest answer is "support and engineering can, whenever they decide they need to". Venvera works the other way round. By default, no Venvera engineer and no Venvera administrator can open your tenant. Access happens only when one of your own tenant admins approves a specific, time-boxed request. This article explains how that flow works, and why we built the product so that the starting position is closed.
The default is no access
Venvera is multi-tenant. Each tenant's data is isolated at the database level with row-level security, and the platform-staff side of Venvera has no standing route into your tenant. There is no support god mode, no shared admin login that reads every customer, no quiet background copy of your data sitting somewhere our team can browse.
The starting position is closed. If a Venvera engineer opens your tenant without a live, approved grant, they see nothing. Access is something you switch on, for a fixed window, not something we hold by default and ask you to trust us not to use.
That is the right default for a platform that holds compliance data, but it cannot be the whole story. Support work occasionally needs eyes on the real tenant.
How temporary access works
Some problems only reproduce with your actual data: a bug that depends on a specific configuration, a stuck import, a key risk indicator that computes a number which looks wrong. For those cases Venvera has a request-and-approve flow modelled on what cloud providers call a customer lockbox. It moves through four stages, and you control the gate at stage two.
Nothing in stages three and four can happen unless a tenant admin actively approves at stage two. There is no timeout that grants access on its own, no escalation path that bypasses you, and no Venvera-side override.
What the engineer has to ask for
An engineer cannot request access quietly, broadly, or in bulk. The request form makes them commit, in writing, to three specific things.
- An approver. One named tenant admin from your organisation. The engineer picks a real person who works for you, not a Venvera mailbox and not a generic support queue.
- A reason. Free text, stored exactly as typed. The approver sees it word for word, and it is written to your audit log, so a vague or copy-pasted reason stays visible to you and stays on the record.
- A duration. Measured in minutes and capped at 1440, which is 24 hours. If the work runs longer, the engineer has to submit a fresh request and you approve again.
When the request is submitted, the chosen approver is notified. Nobody else can approve in their place, and the engineer still has no access at this point.
Approving, from the dashboard or by email
The approver can act in two ways. Inside Venvera, the request appears on their dashboard and they approve or deny it directly. Away from the app, they receive an email with a signed link and a six-digit code. Opening the link is not enough on its own: the approver has to sign in as themselves and then enter the code. That two-part check means an auto-clicking mail scanner, or a link forwarded to the wrong inbox, cannot approve anything.
Why two channels? The dashboard channel is the fast path for admins already working in Venvera. The email channel exists so approval still works when the approver is not signed in, and it never weakens the check: clicking a link, by itself, grants nothing.
Time-boxed, and revocable at any moment
An approved grant is not an open door. It is bounded on both ends.
| Typical SaaS support access | Venvera engineer access |
|---|---|
| Support and engineering hold standing access to customer data. You are trusting a policy, and you usually cannot see when that access is used. | No standing access. Each grant is one approved request with a start, an expiry, and a named approver on your side. |
| Access, once given, tends to persist. Removing it is a manual housekeeping task that often does not happen. | Access ends on its own. The viewing session an engineer is issued is capped at the grant expiry, so it cannot be stretched past the window you approved. |
| Revoking access means filing a ticket with the vendor and waiting for someone to action it. | Any tenant admin, not only the original approver, can revoke a live grant immediately from the access dashboard. |
The maximum any single request can ask for is 24 hours. Shorter is normal: a one-hour grant for a quick reproduction is common. The point is that access has an end built in from the start, rather than relying on someone remembering to take it away.
Every step is in your audit log
You do not have to take any of this on trust, because the whole lifecycle is recorded in your own tenant audit log.
- The original request, including the reason and the duration that were asked for.
- The approval or denial, including which channel was used, in-app or email.
- Every action the engineer takes while the grant is live, tagged with the grant ID.
- The revocation, if there was one, including which tenant admin revoked it.
Because each engineer action carries the grant ID, you can filter the audit log to one grant and see precisely what was looked at during that session. The access dashboard at /tenant-access shows pending, active and finished requests in one place.
Why this matters for DORA and NIS2
If you run a compliance programme, third-party access to your data is not an abstract worry, it is something your own frameworks tell you to govern. Under DORA, your ICT third-party providers, and the access they hold, belong in your Register of Information and your oversight arrangements. Under NIS2, supply chain security is an explicit duty. ISO 27001 Annex A covers supplier relationships and privileged access in the same spirit.
Venvera is itself an ICT provider to its customers. The approval flow described here is part of what lets you answer the supplier-access questions in those frameworks with something concrete: access is denied by default, granted only per request, time-boxed, revocable, and fully logged on your side. That is a far stronger answer than a paragraph in a vendor policy document.
An auditor will ask. "How do you control your SaaS vendors' access to your regulated data?" is a normal question in a DORA or NIS2 assessment. Being able to show a per-request, time-boxed, audit-logged approval flow is a clean answer.
What this is, and what it is not
It is worth being precise about the boundary of this control. The approval flow is a procedural gate, not a cryptographic one. Venvera's application layer holds the keys needed to operate on your data, and a tenant admin's approval is what opens the path through that layer. The flow guarantees that the path is closed by default, opened only with your explicit and recorded consent, and closed again automatically when the window ends.
If your requirement is stronger, that even Venvera engineers should be unable to decrypt your data without you releasing a key, that is customer-managed encryption keys (BYOK). We offer that as a separate arrangement to enterprise customers. If you need it, get in touch and we will walk you through it.
For everyone else, the default stands: your tenant data stays yours, and Venvera staff get in only when you say so, for as long as you say, with every step on the record.
