Data security and access control in the VIMS platform

A VIMS user account on its own grants access to no operational data at all. Access follows from membership in an organisation. A request to join lands in a pending state and must be reviewed by that organisation's owner or administrator. Until approval the user sees not a single record — there is no scenario where simply registering with a company email address unlocks the registers.

Within an organisation, roles carry different scope: owner, administrator and member. The owner governs the whole space, including data export and archiving. The administrator handles day-to-day user management and configuration. A member works with operational data within the scope their role allows. A separate platform-level permission layer exists purely for technical and administrative support of the service itself.

Permissions live in their own table and are evaluated by a dedicated database function running with elevated rights, outside the ordinary read path. This is a deliberate architectural choice: it removes the most common design flaw in multi-tenant applications, where a user can edit their own profile record and promote themselves in the process.

Every membership and approval-status change is written to the security event log. During an internal audit or a dispute about who authorised what, it is possible to reconstruct who granted access to organisation data and when.

VIMS is a multi-tenant platform: independent organisations work side by side in the same instance, and in the external safety-consultancy model a single adviser may run more than a dozen client companies. Security in that arrangement cannot rest on the interface showing a suitably filtered list. An interface filter protects against mistakes, not against deliberate circumvention.

Separation is therefore enforced directly in the database, at the level of the individual row. Every significant dataset has that protection switched on, and access rules describe who may read, insert, modify and delete each record. A query issued by a user outside the organisation is not answered with a permission error — it simply returns nothing, because in that context the record does not exist.

Files are protected the same way. Photographs documenting incidents land in a space with no public path: they cannot be reached by direct address, and access runs exclusively through a controlled server layer that checks permissions. That matters, because a photograph from an accident scene is often more sensitive than the report describing it.

Revealing specially protected data in the administrative interface is recorded as its own event. We do not block people who legitimately need to see such data — we document the fact that they saw it.

The security event log is written server-side, independently of anything the user does in the browser. Each entry holds an organisation identifier, a user identifier, an event name, a timestamp and a set of contextual data. Recorded events include login code delivery and successful verification, failed code delivery, enabling and disabling two-factor authentication, organisation creation, membership changes, data exports and sensitive-data reveals.

Beyond that log, the process modules keep their own history. An incident retains the trace of each investigation stage, a root cause analysis stores successive versions of its findings, and module configuration changes are recorded together with their author. During an external audit the conversation therefore moves past whether something was done, to when and by whom.

Business continuity rests on two independent layers. The first consists of automated backups of the whole data layer taken by the cloud infrastructure provider; they exist to rebuild the environment after a technical failure. The second, implemented inside the platform itself, works per organisation: every night the system prepares a separate archive for each company using VIMS and stores it in a private, non-indexed space inside the European Union region.

Each archive covers the organisation's operational data — the incident and accident register, concern reports, the chemical substances register with safety data sheets (SDS), root cause analyses, module configuration and the list of users with their roles. Archives are kept for fourteen days and are then deleted automatically, together with their registry entry. Outside the nightly schedule a backup can be taken on demand, for instance before a large configuration change or a data import.

Restoring is deliberately constrained. Only the highest technical role on the provider side can run it, after confirming identity with a one-time code sent by email and explicitly confirming the scope. Before the restore the system displays the archive contents with a record count per section and allows selecting only the areas to be recovered — no need to roll back a whole organisation to recover a single register. Immediately before data is overwritten an automatic safety copy of the current state is created, so the restore itself can be reversed. Every restore and every nightly run is written to the security event log.

We do not publish a contractual restoration time as a commercial standard — specific continuity parameters, including availability levels, are agreed individually in the contract where an organisation requires them.

Acceptances of legal documents — terms of service and the data processing policy — are stored together with the document version and date. When wording changes, it stays visible who accepted which version, which is often the first question during an inspection.

In the customer relationship VIMS acts as a processor on behalf of the controller, which remains the organisation using the system. Cooperation requires a data processing agreement; we prepare it alongside the main contract and attach it to tender documentation whenever the buyer expects it.

The scope of personal data processed depends on which processes the organisation chooses to run. Launching an incident register requires a narrower scope than maintaining medical examination records or a training register. We recommend consciously limiting collected fields at implementation time to those genuinely needed — both good practice under the minimisation principle and simpler to maintain.

Customers retain ownership of their data throughout the relationship and after it ends. The organisation archive can be downloaded directly from the system, with no request form and no waiting on support. The action is available to the owner and administrator, and its execution is recorded.

Deletion of data after the relationship ends is performed on the controller's written instruction, within the mode and timeframe agreed in the processing agreement. We do not hold data hostage as leverage during subscription renewals.

Single sign-on against a corporate identity provider, and a public documented API for integration with HR and maintenance systems, sit on the product roadmap and are not available today as features you can switch on. We keep them off the capability list because for an IT department this is decisive information, not a nice-to-have.

We hold no information security management certification of our own. The infrastructure the platform runs on is maintained by an external cloud provider with its own certifications, but we do not treat that as our certification and do not present it that way.

Nor do we publish a guaranteed availability level as a marketing figure. If your organisation requires a contractual commitment on that point, it is a matter for individual negotiation rather than a claim on a website.

This approach occasionally lengthens the sales conversation and consistently shortens the implementation. An IT department handed an honest list with clearly marked gaps decides faster than one that has to verify promises.