# Compliance: what your customers' auditors ask about us

When your customer sells into insurance, banking, healthcare or government, their compliance team does not stop at your software. Once they learn that VSHN's engineers can reach their production system, the audit extends to us. This page answers the questions that follow, so you can forward it instead of writing the answers yourself.

## What your customers ask about the people who touch production

The questions are specific, and they are not about your code:

- Who at VSHN can reach our production system, and under what controls?
- How is that access logged, and can we see the log?
- What separates our environment from another customer's?
- Which access model applies?
- What happens to an engineer's access when they leave VSHN?

Those are answered by VSHN's own access-management model and the ISAE 3402 Type II report, not by [where the data is hosted](/sovereignty/). A customer satisfied on jurisdiction still has these five questions open.

## Each customer's environment is separate

VSHN operates your application for each of your customers as that customer's own deployment: separate environment, separate credentials, separate access grants. Application Operations does not pool customers onto shared infrastructure the way a multi-tenant platform does, so a breach of one customer's access grant has no path into another's.

## The access-management model

VSHN's administrative access is unattended-access-only by design, which rules out the methods an auditor most often asks about:

- No personal VPN clients, remote-desktop jump hosts, hardware tokens or customer-issued notebooks carry standing access to your production system.
- VSHN provides its own SSH and VPN jump hosts, under VSHN's own control, not the customer's.
- Every employee and service account is managed exclusively through VSHN Configuration Management, so access is granted and revoked from one declarative source rather than by hand on each system.
- Changes to the running platform are not made by hand. Four-eyes review is enforced at the source: a change ships as a merge request that a second engineer approves, before it reaches production, not as a checkbox on the platform itself.

When an engineer leaves VSHN, their access is removed the same way it was granted: through Configuration Management, not through a list of systems someone has to remember to visit.

## What the ISAE 3402 Type II report already evidences

Most of what an auditor asks for is satisfied by evidence that exists before anyone asks. VSHN is [ISO 27001 certified](https://www.vshn.ch/en/about/awards-certifications/) and produces an ISAE 3402 Type II report: an independent auditor's opinion on whether VSHN's controls were designed properly and actually operated, over a defined period. Type II is the distinction that matters here, because it covers a period of real operation rather than a snapshot taken on one day. In practice, the report closes most of a due-diligence questionnaire on access control, change management and logging without a site visit.

## Where a contractual clause is still needed

Two things the ISAE 3402 report and the access model above do not settle on their own:

- **Contractual audit rights** for you, or for your customer, including an on-site audit. These are negotiated, not pre-approved: written into the contract for the specific engagement. VSHN has granted on-site audit rights to FINMA-supervised customers before.
- **A customer-specific confidentiality or liability clause** your customer's legal team drafts. VSHN is happy to review it once drafted, rather than promise in advance that it fits: a provider who promises that in a first email is telling you what you want to hear, not what has been reviewed.

VSHN is happy to review your customer's specific requirements and work out a solution, once VSHN's legal team has read your customer's actual contract language.

[Book a call](#contact) if you want these answers checked against your customer's own questionnaire.