AutoServa/Security
Data and access

Written for the person who has to sign this off.

Governance covers what the operator is allowed to do. This page covers what happens to your data: where it lives, who can reach it, how long it is kept, what happens if something goes wrong, and what you are left holding when the engagement ends. If your compliance lead has a question that is not answered here, it is a fair question and we would like to hear it.

A hardware security module seated in a server chassis under blue rim light
Your material stays inside the boundary you chose, encrypted at rest and in transit.
An abstract data lifecycle pipeline with four stage chambers

The data lifecycle, end to end.

Five stages, each with a rule that is set during the engagement rather than assumed. The recurring principle is that scope is decided deliberately and written down before anything moves.

01

Collected

Only the material the workflow in scope actually needs. We do not take a copy of a whole system because it was easier than scoping the extract, and the scope is written down before anything moves.

02

Stored

Inside the infrastructure boundary you chose, cloud tenancy or your own server. Encrypted at rest. Never pooled with another client and never used to improve a shared model.

03

Used

To tune the operator on your decision framework, and at run time as the context for a specific case. Access is logged at the level of which records were read for which case.

04

Retained

For as long as your own retention policy says, not ours. The evidence trail is normally kept longer than the working data, because that is what an auditor will ask for.

05

Deleted

On the schedule your policy sets, or on request. Deletion covers the working copies and the tuning material, and is confirmed back to you in writing.

Who can reach what.

The operator is treated as a member of staff for access purposes, because that is the model your organisation already knows how to govern.

The operator has its own identity

It is provisioned like a new employee: a named account, its own credentials, and permissions scoped to the queue in scope. It never shares a human colleague's login, which is what keeps your audit log honest.

Least privilege, widened slowly

Read-only through Observe, Capture and Codify. Write access only at the supervised live run, and only to the specific systems and record types that queue touches. Nothing is granted "to make setup easier".

Every access is logged

Which system, which record, at what time, for which case. This is the same trail that supports the evidence attached to each decision, so there is one record rather than two that can disagree.

Our own access is scoped and time-boxed

VYROX engineers get the access needed to deliver the engagement, for the duration of the engagement, logged the same way. It is reduced when a workflow goes stable and removed when the engagement ends.

If something goes wrong.

Any system that makes judgement calls will eventually make one you disagree with, and any system connected to production systems can eventually be part of an incident. What matters is that containment is in your hands and the investigation material already exists.

  1. 01

    Contain

    The operator can be paused immediately, by your team, without waiting for us. Pausing returns the queue to exactly how it ran before, because that path was never removed.

  2. 02

    Assess

    The evidence trail is the investigation material. Because every action records what was read, which rule applied and what was written, the blast radius can be established from the record rather than estimated.

  3. 03

    Notify

    You are told what happened, what was affected and what we know, in plain language, on the timeline your policy or your regulator requires. We would rather report early with an incomplete picture than late with a tidy one.

  4. 04

    Remediate

    Reversible actions are reversed under the same audit trail. The framework rule that permitted the problem is corrected, not just the individual case.

  5. 05

    Review

    A written account of cause, impact and the change made, for your risk file. If the cause was ours, we say so in that document.

The pause is yours. Containment does not depend on reaching us, on a support ticket, or on a business-hours response. Your team holds the switch from the first supervised run onward.

What happens when it ends.

Worth settling before it starts. An arrangement you cannot leave cleanly is a risk in itself, so these are the exit terms we would rather agree at the beginning.

You keep the framework

The decision framework, the precedent library and the full evidence trail are exported to you in an open format. They are the durable asset from the engagement and they do not depend on us.

Nothing switches off on our say-so

A local deployment keeps running on your hardware. A cloud deployment keeps running against your own provider account if you hold it. Ending a support arrangement is not a kill switch.

Our access is revoked

Engineer access is removed and confirmed. The operator's own credentials are yours to rotate or retire as you choose.

Deletion is confirmed in writing

Any working copies of your material held for delivery are deleted on the schedule agreed, and you get written confirmation of what was deleted and when.

Send us your security questionnaire.

Most organisations have one, and most vendors treat it as an obstacle. We would rather work through it in the first session than at contract stage, because the answers usually shape whether the deployment should be cloud or local in the first place.