Where Is Your Data, Who Can Read It, and How Do You Get It Back?
Where your data lives is a set of written answers, not a feeling. KodDelta deploys to infrastructure you own or rent in your own name, hands over the database schema and the backup procedure, and puts the hosting location, the access log, the restore test and the exit terms into the contract rather than the sales conversation.
The question usually arrives late, and it is rarely phrased as a security question. Somebody in finance asks where the customer list actually is. Somebody in legal asks whether the supplier can see the payroll table. Then a supplier relationship ends, and everyone discovers that the cloud account is registered to the developer's email address and the last full backup nobody has ever restored is eleven months old. None of that is a hacking story. It is a documentation story, and it is preventable with five written answers.
The five questions that should have written answers
- Where is it hosted? Named provider, named region, and the same for the backups — a database in one country with backups mirrored to another is two answers, not one.
- Whose name is on the account? Not who administers it. Whose company name and billing details are on the cloud account, the domain registration and the DNS.
- How are backups taken and when were they last restored? Frequency, retention, and the date of the last successful test restore.
- Who can read what? The roles, what each role can see, and whether reading is logged as well as writing.
- How do we leave? What we receive, in which formats, within how many days, at what cost, and without needing anyone's permission.
If your current supplier cannot answer all five without checking, that is the finding.
Three hosting models and what each one costs you
| Model | Who holds the account | What you can prove | Difficulty of leaving |
|---|---|---|---|
| Your own servers | You | Physical location, everything on it | Low — the files are already yours |
| Cloud account in your name | You, with the supplier granted access | Region, snapshots, provider access log | Low — revoke the access, keep the system |
| Cloud account in the supplier's name | The supplier | Only what they tell you | High — you are negotiating for your own data |
| Shared multi-tenant product | The vendor | What the vendor documents publicly | Depends entirely on the export they offer |
The third row is the one that catches people, because on a day-to-day basis it looks exactly like the second. Everything works, the system is fast, the bills are paid. The difference only appears on the day you want to change supplier, which is precisely the day you have the least bargaining power. Running your own servers is not automatically safer either — a machine in your own building with no tested restore is worse than a cloud account with one.
Owning the data and owning the account are different things
A contract can assign you full ownership of the data and still leave you unable to reach it. The practical checklist is short and worth walking through this week:
-
1. The domain and DNS
Registered to your company, renewing on your card, with a login your own staff hold. A domain that lapses because it was on a former supplier's card takes your email down along with the system.
-
2. The cloud or hosting account
Opened in your company name. Your supplier gets a user account with the permissions they need, which you can revoke in a minute without touching anything else.
-
3. The database credentials
An administrator credential held by someone inside your company, stored where it survives a person leaving. If only the supplier can connect to the database, the data is theirs in every sense that matters operationally.
-
4. The code repository
Access from the first commit rather than at handover, so the working copy of the system exists somewhere you can reach today. This is covered further in what source code delivery actually includes.
Backups: the only backup that counts is a restored one
A green tick on a backup job means a file was written. It does not mean the file is complete, that it can be decrypted, or that a working system can be rebuilt from it. Specify four things and require evidence for each:
- Frequency and retention. How often, kept for how long, and whether older copies thin out over time.
- At least two locations. A backup on the same machine as the database protects against a bad deployment, not against losing the machine.
- A scheduled restore test. Into a separate environment, with the elapsed time and the timestamp of the restored data written down. Agree the interval and hold to it.
- Two agreed numbers. How long a restore is allowed to take, and how much recent data you accept losing. These decide the backup design and the cost; deciding them after an incident is not a decision, it is an outcome.
One more rule from experience: never leave a database dump inside a public web directory. Archives placed there for convenience during a migration are found and downloaded, and no firewall protects a file the web server is happy to serve.
The access log is what you will be asked for
When something goes wrong, the question is never "was the system secure". It is "who opened that record on the 14th". A log that can answer that has four properties: it records reads as well as writes; it stores the previous value alongside the new one; it names the user rather than a shared account; and the people it records cannot edit it. Roles matter as much as the log itself — a technician who can see one region, a manager who can see the branch, an administrator who can see everything and knows the log will show it. Shared logins undo all of this in a single step, because after that the log names a role, not a person.
Changing provider: test the exit while things are going well
The exit is testable, and the test is cheap compared with discovering the answer under pressure. Ask for the four artefacts below, then have someone who did not build the system stand it up in an empty environment.
| What you ask for | A workable answer | A warning sign |
|---|---|---|
| The data | A full database dump in a standard format, with the schema and the relationships intact | A set of flat CSV exports or PDF reports with the links between records lost |
| The files | The document and image store as a downloadable archive, with the paths the database refers to | Attachments retrievable only one at a time through the interface |
| The code | The repository with its history, readable and buildable | A compiled package, or a promise to send it later |
| The instructions | A written procedure for a fresh install: dependencies, environment settings, first-run steps | "It is straightforward, we will walk you through it" |
The moment to run that test is when the relationship is healthy. Every custom system we deliver is meant to pass it, which is why the schema and the deployment procedure are handed over as part of the work rather than sold back later.
What the contract should say
- The hosting provider, the region, and the region for backups, named explicitly.
- That all accounts — cloud, domain, DNS, repository — are registered to the client.
- Backup frequency, retention, the restore test interval, and who performs it.
- Ownership of the data, and a statement that the supplier keeps no copy after handover.
- A data processing agreement covering what the supplier may access, for what purpose, and for how long.
- Exit terms: what is delivered, in what format, within how many days, at what cost.
- A notification duty and a timeframe if the supplier becomes aware of a breach.
None of these clauses are unusual and none of them are expensive to agree in advance. They are only expensive to negotiate afterwards.
Where the legal responsibility sits
Under GDPR and the Turkish KVKK, the company that decides why and how personal data is processed is the controller, and that is you. The developer or hosting provider processes it on your instructions. This matters practically: you are the one who must be able to say where the data is, who has touched it, and how quickly it could be deleted or exported on request. A supplier can help you answer those questions and can be liable to you under the contract, but the obligation towards the people in your database does not move.
If you cannot answer the five questions at the top of this page about a system you are running today, that is the first piece of work. We do that review as part of scoping. Request a quote, read how to evaluate a software supplier, or see the delivery bands on the pricing page.
Frequently asked questions
Where is our database stored when KodDelta builds a system?
In infrastructure you control: your own servers, or a cloud account opened in your company name. The account, the domain and the database credentials belong to you from the first day. We do not keep a copy of your operational data after handover, and the hosting location is written into the contract rather than agreed verbally.
Who owns the data, and who owns the hosting account?
These are two different questions and only one of them is usually asked. You can own the data outright and still be unable to reach it if the cloud account, the domain or the DNS is registered to your supplier. Insist that every account is in your company name with your billing details and an administrator login you hold.
How do we know our backups actually work?
Only by restoring one. A backup job that reports success proves that a file was written, not that the file can rebuild a working system. Ask for a documented restore test on a schedule you agree, performed into a separate environment, with the elapsed time and the date of the restored data recorded each time.
What should an access log record?
Who logged in and from where, which records they opened, and every change with the previous and new value, the user and the timestamp. Deletions should be recorded rather than silent. The log should be readable by your own administrator without asking the supplier, and it should not be editable by the people it is recording.
How do we test whether we could change provider?
Run the exit while the relationship is good. Ask for a full database dump, the file storage, the source code and the deployment instructions, then have someone outside the project stand the system up in a separate environment. If that succeeds, you are portable. If it needs the original developer to be reachable, you are not.
Does hosting with a supplier move the legal responsibility to them?
No. Under GDPR and the Turkish KVKK your company remains the data controller and carries the obligations towards the people whose data you hold. The hosting provider or developer acts as a processor under a written agreement. Outsourcing the servers outsources the operation, not the accountability.
Let's talk about what you need.
The 30-minute discovery call is free and carries no commitment.