Who Owns Your Data: What to Require From a Software Vendor
Data and licences in the client's name, testing on a copy and exit without lock-in: IT governance criteria for choosing and changing a software provider.
An organisation's data, and the licences behind its systems, belong to the organisation. This seems obvious, yet many organisations discover it is not so at exactly the moment they want to change provider. This article proposes IT governance criteria to avoid that.
- Licences, accounts and data should be in the client's name from the first day.
- Every solution is tested on a copy before it is bought or put into production.
- A good provider relationship includes, from the start, the ability to leave without dependency.
Where dependency begins
Dependency on a provider is rarely agreed explicitly. It builds up in details: an administrator account created in the provider's name, a licence bought with its details, a server only the provider can reach, a configuration nobody else knows. Each decision looks reasonable alone; together, they make changing provider costly or simply unworkable.
IT governance consists, to a large extent, of preventing that build-up in time.
Licences and data in the client's name
The simplest criterion is the most effective: everything purchased, registered or stored for the organisation is held in its name. Software licences, domains, cloud platform accounts and databases have the organisation as holder, and the provider works with delegated permissions that can be withdrawn.
This has an important practical consequence: if the relationship ends, the organisation keeps everything it needs to carry on, without negotiating the handover of what was already its own.
Test on a copy before buying
Before acquiring a licence or changing a system in use, it is wise to test on a copy. A copy lets you confirm the solution does what is expected, with sample data and no risk to operations. It also shows early how much the solution depends on elements specific to the provider. A well-run test avoids premature commitments and clarifies what is actually being contracted. For the care of data in these tests, see Synthetic test data.
Separate environments
When a provider serves several clients, each should run in its own environment. Separation stops an error or incident at one client from reaching another, and it simplifies handover: taking one client out of its environment does not affect the rest. It is a valid criterion for small systems and for portals with sensitive information alike, such as the one described in Virtual data room for investors.
A counterpart with the same access
A healthy arrangement includes a person at the client organisation with the same access as the provider, able to step in during an emergency without waiting. This is not distrust; it is a form of continuity. If the provider is unavailable, or a second pair of eyes is simply needed, the organisation can act. At IT Lab we operate on this principle, and we regard it as part of a transparent service.
Document in order to leave
Exit without dependency rests on two things: everything is in the client's name, and the essentials are documented. A good provider delivers, besides the system, a description of how it works, where each component sits and how it is restored. Backups play a central role: a copy that has been successfully restored is the best proof that data can be moved. On this point, see Backup 3-2-1.
Practical checklist
- Review in whose name licences, domains and administrator accounts are held.
- Ask for data and its ownership to be recorded in writing in the organisation's name.
- Test every new solution on a copy before buying.
- Require separate environments per client when the provider serves several.
- Appoint an internal counterpart with the same access as the provider.
- Request architecture and restoration documentation.
- Rehearse the recovery of a backup at least once.
Frequently asked questions
Does changing provider always mean a difficult migration? It depends on how much has built up. With licences, data and documentation in the client's hands, migration is a bounded project rather than a negotiation.
Why should the client have the same access as the provider? To be able to act in an emergency and to exercise real control. It is compatible with a relationship of trust.
Does this apply to small systems? Yes. A website, corporate email or a CRM can have the wrong holder just as easily.
Who defines the provider's permissions? The client organisation, which grants them and can withdraw them.
General guidance; contracts and their legal scope should be reviewed with legal counsel.
At IT Lab we care about our clients' data as much as they do, which is why we work with licences and data in the client's name, testing on copies and an exit that is always available. For a case where these criteria meet requirements from another country, see Chilean IT provider for clients in the United States.
If you would like to review your own agreements with providers, Let's talk.
Do you need someone to take care of your technology?
Tell us what you need to organize, protect or solve. The first conversation has no cost: we assess whether our model fits you and what the next steps would be.
Let's talk about your business