How does Laveeka handle client data?

Client data stays in the client's own systems wherever possible, residency is decided deliberately at the start rather than by default, content is never used to train models, and the build lives in the client's repository with ownership transferring formally at handover.

What is decided about data governance before a build starts?

Five things: where the data lives, who can see what, which external services touch it, what is logged and cannot be edited, and which actions a person must approve. Settling these first is far cheaper than retrofitting them.

Does a person review what an automated system produces?

Yes. Anything that would reach a client, a candidate or a regulator is approved by a person before it goes, not reviewed afterwards. The value is in removing the work of assembling something, not the judgement about whether to send it.

Is Laveeka SOC 2 or ISO 27001 certified?

Both programmes are underway with Oneleet and neither is complete. Laveeka does not describe itself as certified in either until the report is issued. The current status of each is published on the security page.

Laveeka / Guides / Data governance

How we approach data governance and security

Most of this is decided before anything is built, because it is far cheaper to design than to retrofit.

The short answer

Your data stays yours and stays where you put it. Access is decided by the database on every request rather than by the interface asking politely. Anything a system does that touches a client or a candidate is written down and can be undone, and anything that reaches a person outside the business is approved by a person inside it.

We do not publish the specifics of any client's architecture, which is a security practice rather than a reluctance to answer. Our own posture, and the independent assessment of it, is published in full.

The assumption everything else follows from

Most data incidents are not sophisticated attacks. They are ordinary mistakes that a permissive system allowed to happen: a field visible to a role that should not have had it, an export nobody logged, a test account left with production access.

So the controls we put weight on are the ones a system enforces rather than the ones that depend on somebody remembering. A rule the database refuses to break holds on a Friday afternoon in month eleven. A rule in a handbook does not.

Whose data it is

Yours. That is not a courtesy, it is the design.

It stays in your tenancy wherever it can. We would rather build inside systems you already own and already have agreements for than move your data somewhere new because it is convenient for us.
Residency is decided deliberately, not by default. Where information physically sits is a question we ask in the first week, because it is a contractual matter for many clients and it is expensive to move later.
Content is not used to train models. What passes through a system to produce a result is used for that and nothing else.
You can leave. The build lives in your repository, ownership transfers formally at handover, and the documentation is written so another team could take it on. A system you cannot exit is a system that owns you.

The five questions we settle before building

Where does this live? Which country, which account, under whose agreement.
Who can see what? Roles first, and the narrowest set that lets the work happen. Widening later is easy. Narrowing later means finding out who has been relying on the extra.
What leaves the building? Every external service that touches the data, named, with what it handles and where it operates.
What is written down? Which actions are logged, who did them, what changed and whether that record can be edited by anybody.
What must a person approve? Named explicitly, before anything is built, rather than discovered when something goes out that should not have.

The gate that matters most

Anything a system produces that would reach a client, a candidate or a regulator is approved by a person before it goes. Not reviewed afterwards, approved before.

That is a deliberate constraint on how much can be automated, and it is the constraint we argue hardest for. The value is in removing the work of assembling a thing, not in removing the judgement about whether to send it. Firms that automate the judgement as well are the ones who end up explaining themselves.

What we do not publish, and why

We do not publish the architecture of any client's system, the specifics of how their keys are held or the shape of their access model. Not because those questions are unwelcome, but because a public description of how a system is defended is a useful document to the wrong reader.

Your own security team gets all of it, in writing, under whatever agreement you need. That is a different conversation from a page on a website, and it should be.

How to check us rather than take our word

Our own controls, the independent assessment of them and the current status of each programme are set out in full on our security, privacy and governance page, alongside the privacy policy and the sub-processor list naming every provider we rely on and the country it operates in. Those are published rather than held back for a questionnaire, which is the point of publishing them.

Where a programme is underway rather than complete, that page says so plainly and does not describe us as certified until a report is issued. If your procurement team needs evidence for a file, ask and we will send it.

None of the above is unusual. It is close to what any careful firm would tell you, which is rather the point: the difference is not the principles, it is whether they are settled before the build or argued about after it.