Operator Manual
GVS tools have no server, no accounts and no admin console — which removes most of what an operator normally manages, and introduces a small set of things you must own instead. This manual is about that trade: what you no longer have to do, and what becomes your responsibility because we deliberately cannot do it.
The deployment model
Read this first — it determines every other decision.
Static files, client-side execution
Each tool is a self-contained HTML file. All logic runs in the browser. Data is written to that browser's local storage on that device.
- No application server
- No database
- No API GVS operates
- No background processes
Most of your usual workload
There is no infrastructure to run, patch, scale or monitor, and no identity integration to build.
- No SSO or user provisioning
- No capacity planning
- No uptime to manage
- No vendor data-processing agreement needed
Endpoint responsibility
Because data lives on endpoints, your device policy becomes the data-protection control.
- Disk encryption matters
- Browser data-retention policy matters
- Backup discipline is user-side
- Device loss equals data loss
The single most important operator insight: there is no central copy. Standard assumptions — "IT can restore it", "we can revoke access", "we can export everyone's data on request" — do not hold. Plan for that before rollout rather than after an incident.
Deployment options
Four ways to put the tools in front of your people, in increasing order of control.
| Option | How | Best when | Operator considerations |
|---|---|---|---|
| Public hosted | Users open the GVS URL | Evaluation, individual use, no procurement involved | Page is fetched from a public CDN; data still stays local. Outbound access to the domain required |
| Internal hosting | Copy files to your own web server or intranet | You want the asset served from inside your perimeter | Static hosting only. Note that changing the URL creates a new storage origin — existing local data will not follow |
| Local file distribution | Distribute the HTML file directly to endpoints | Air-gapped or restricted environments | Works fully offline. Each file path is its own storage origin; version control becomes your responsibility |
| On-premises engagement | GVS installs and configures inside your perimeter | You need configuration to your model plus handover documentation | Scoped engagement with milestone acceptance — see the services page |
Origin changes destroy local data
Browser storage is bound to the exact origin — scheme, host and path. Moving users from the public URL to an internal one, or from a hosted page to a local file, means their existing data will not appear. It is not lost from the old origin, but it will not follow.
Before any migration: instruct users to Export from the old location and Import at the new one. Build that into the change plan, not the incident queue.
Data governance
The questions your DPO, risk function or auditor will ask, with the honest answer to each.
| Question | Answer | What it means for you |
|---|---|---|
| Where is data stored? | In the user's browser local storage, on their device | Data location follows device location, not a data-centre region |
| Does GVS process personal data? | No | No processor relationship arises from tool use alone. Confirm with your own counsel |
| Is there a cross-border transfer? | No, from tool use | Nothing is transmitted. The page itself is fetched from a CDN; content is not sent back |
| Can GVS access our data? | No | Technically impossible — there is no channel and no store |
| Can GVS recover deleted data? | No | User export is the only recovery. Make export a documented obligation |
| Can we centrally revoke access? | No | Removing a user's access means device management, not an admin console |
| Can we run an eDiscovery hold? | Not centrally | Data is on endpoints; use your existing endpoint collection process |
| What is the retention period? | Whatever the device retains | Retention is your browser and endpoint policy, not a product setting |
| Is there an audit log? | No central log | Tools record their own state; there is no server-side activity trail |
| What if a user leaves? | Their data is on their device | Include tool export in your offboarding checklist |
Four "no" answers above are structural, not gaps awaiting a roadmap item. If central revocation, central retention control or a central audit trail are hard requirements, the browser-native model is the wrong fit for that use case and we would rather you knew now.
Security posture
What the architecture protects against, and what it does not.
Whole classes of risk removed
- Server breach — no server holds data
- Credential stuffing — no accounts exist
- Cross-tenant leakage — no tenancy
- Vendor insider access — no access path
- Third-party subprocessor exposure — none in the data path
- Legal compulsion against the vendor — nothing to produce
Risks that move to the endpoint
- Device theft or loss with no disk encryption
- Malware or an infostealer on the endpoint
- Shared or unlocked workstations
- Shoulder surfing and screen exposure
- Users exporting to unmanaged storage
- Browser extensions with page access
Where to spend effort
- Full-disk encryption on all endpoints
- Screen lock policy and timeout
- Browser extension allow-listing
- Guidance on where exports may be stored
- Endpoint backup covering browser profiles
- Offboarding that includes export and wipe
IAS Vault deserves specific policy
Vault encrypts content on the device with a key the user controls. That means: if the user forgets the key, the data is unrecoverable by anyone, including you. There is no escrow, no admin override and no reset.
If your organisation requires key escrow or administrative recovery for stored credentials, do not deploy Vault as the system of record for organisational secrets. It is well suited to individual use and poorly suited to a control requiring recoverability.
Rollout
Five phases. The evaluation phase is where you decide whether the model fits at all.
Evaluate
Open the tools yourself. Test the governance answers above against your own requirements before involving users.
Decide policy
Export cadence, permitted backup locations, device requirements, which tools are approved for which data classes.
Pilot one team
One tool, one team, one cycle. Confirm the export habit forms — that is the real adoption test, not usage counts.
Configure and template
Seed role templates and rubrics to your model so users start from your context, not a generic one.
Roll out and hand over
Distribute with the user manual and your policy attached. Nominate an internal owner — GVS is not a support desk.
What the operator must own
Because GVS structurally cannot. Assign each of these to a named person before rollout.
| Responsibility | Why it is yours | Suggested control |
|---|---|---|
| Backup | No central copy exists to restore from | Mandated export cadence; endpoint backup covering browser profiles |
| Version control | Locally distributed files do not self-update | Track the version in use; redistribute deliberately |
| Access removal | No accounts exist to disable | Device management and offboarding wipe |
| Data classification | Only you know what may be entered | Written guidance on which tools may hold which data classes |
| User support | GVS has no support desk and promises no response time | Name an internal first-line owner; use the troubleshooting manual |
| AI key governance | Optional AI uses the user's own API key | Decide whether keys are permitted; if so, who issues them and what may be sent |
| Migration | Origin changes strand local data | Export/import step written into every change plan |
Answering audit
What to hand an auditor, and what not to claim on our behalf.
Accurate claims
- The vendor operates no server holding our data
- No personal data is transmitted to the vendor by tool use
- Data resides on managed endpoints under our device policy
- Source is inspectable — the file is readable
- No subprocessors are in the data path
Claims we cannot support
- "The vendor is SOC 2 / ISO 27001 certified" — GVS holds no such certification
- "The solution is GDPR compliant" — architecture reduces exposure; compliance is your assessment
- "Data is backed up centrally" — it is not
- "Access can be revoked centrally" — it cannot
- "There is an audit trail" — there is no server-side trail
What to gather
- The tool file itself, versioned
- Your written data-classification guidance
- Your export and backup policy
- Endpoint encryption and lock policy
- Named internal owner and support route
Nothing in this manual is legal advice. Regulatory obligations differ by jurisdiction and change; confirm your position with your own counsel. GVS makes no compliance guarantee and will not sign one.