Who Is Accountable When a Vendor Connects to Your Database?

A vendor consultant connects to your production database from their own laptop. The connection details were shared in an email two years ago. That consultant may no longer work for the vendor; you do not know, because the account is still open. This article is about the access type organisations have the least visibility into, and where the accountability actually sits.

The Third Party Share Keeps Growing

The share of third party access in data breach analyses has risen noticeably in recent years. Widely tracked industry reports put close to a third of breaches as involving access by a vendor, service provider or partner, roughly double the figure of a few years earlier. A single vendor being breached tends, on average, to affect more than one customer organisation at once.

What that means at the database layer is this: some of the people who can connect to the production database are not employees, are not managed in the organisation's identity system, do not go through its training and are not covered by its leaver process. The organisation is nonetheless accountable for the personal data in that database.

Accountability Cannot Be Outsourced

Data protection law is unambiguous here, and this is where organisations are most often mistaken. Even when the party processing the data is a vendor, the organisation that controls the data does not shed its accountability. Turkish data protection law makes the controller and the processor jointly responsible for obligations relating to data security.

The processing party has concrete obligations of its own: to process only on documented instructions, to apply appropriate security measures, to keep processing records, to work with no one outside the approved sub processors, to notify without undue delay when an incident occurs, and to delete or return the data when the contract ends. A processor is also answerable for the conduct of its own sub processors; a failure further down the chain creates liability further up.

The practical consequence is that "the vendor made that change" is not a defence in an audit. The question an auditor asks is not who made the change but how the organisation authorised it and how it knows what was done.

Five Ways a Vendor Reaches Your Database

Most of these were set up as a normal part of doing business rather than as a security exception. That is precisely why they are invisible.

What these five have in common is that none of them enters the organisation's change management process. The process was designed for internal teams; vendor access lives in a separate world, on the procurement and contract side. The two never touch.

What the Contract Promises and What the Environment Delivers

Data processing agreements contain a standard set of commitments. The table below asks whether each one is actually produced in the technical environment. This is the most useful exercise to run before an audit.

Most organisations that try to fill in the right hand column get stuck on the first row. When vendor work is not tied to a request record, none of the other four can be produced, because they all rest on it.

A Model That Works: Time Bound, Request Based, Recorded

The workable way to govern vendor access is to tie access to work rather than issuing a standing account. It has four components.

Time bound. Every vendor account has an expiry date and access closes on its own when that date arrives. An extension is a decision and that decision leaves a record too. An account without a date is a permanent account.

Request based. Instead of connecting to production directly, the vendor submits the work as a request. Someone inside the organisation approves it. The commitment to process only on documented instructions stops being a sentence and becomes a record.

Recorded. The text that ran, its timing, the rows affected and the outcome are all kept. Should a dispute arise later, this record protects both sides: the organisation can show what happened, and the vendor can show it did not do something attributed to it.

Masked. When the vendor needs to look at data to investigate a bug, sensitive columns are masked in what comes back. Debugging usually needs the shape and relationships of the data, not the customer's identity number.

SQL Change Guard produces all four inside one flow: the vendor opens a request, someone inside approves it, execution opens on the back of that approval, the text that ran and its outcome are recorded, and for data read requests sensitive columns are masked in the result set. There is no need to hand the vendor the production server password.

When the Contract Ends: The Most Skipped Step

When a vendor relationship ends, the closing checklist is usually full of financial items: the final invoice, releasing the guarantee, the handover record. Closing technical access is either absent from that list or sits at the bottom of it.

The result is the risk item organisations discuss least: an account left over from a project that ended years ago, still open and still privileged. Who it belongs to, who knows it and whether that firm still exists are all unknown. Abusing such an account requires an attacker to touch the organisation not at all; a breach on the vendor's side is sufficient.

The only reliable way to stop this step being skipped is to tie closure to a date rather than a reminder. Access closes by default; keeping it open requires a decision to be renewed. That way the consequence of forgetting is access closing rather than access staying open.

Frequently Asked Questions

We have a data processing agreement with the vendor. Is that not enough?

The agreement is necessary and gives legal protection, but it is not a control. It states what the vendor will do; it does not show what the vendor did. What an audit asks for is not the contract text but the record showing the commitments were met. Responsibility for personal data security is also joint; a shortfall on the vendor's side does not remove the organisation's accountability.

Can we cut vendor access entirely?

In most cases no, and forcing it makes things worse. Supporting a product requires being able to look at its database; cutting access entirely lengthens support times and raises the cost of an outage. Worse still, when the official route closes an unofficial one opens: an employee shares their screen, logs in with their own account and types what the vendor dictates. The record then gets worse, because the action is now attributed to an employee. The goal is not to cut access but to make it time bound, request based and recorded.

The product's own updater changes the schema. How do we govern that?

Preventing the tool from running is usually not an option, but its result does not have to be invisible. There are two practical steps. First, open the upgrade as a change record: which version, when and on whose approval. Second, compare object definitions before and after. Changes not mentioned in the release note then become visible, and when something breaks you know what changed. This does not control the tool but it puts its result on the record.

How are we supposed to track the vendor's own staff?

You cannot follow the vendor's HR processes and you do not need to. What you need is to tie access to work rather than to a person. Even when the people on the vendor's side change, the chain holds as long as every action is tied to a request and to the employee who approved it. Issue a standing account and the chain becomes entirely dependent on the vendor's internal discipline, and your visibility drops to zero.

Where should we start?

With one list: every account able to reach production databases that does not belong to an employee. Write three facts on each row: which vendor, under which project, and what the expiry date is. The third column coming out largely empty is the expected result and it starts the discussion on its own. Then rather than closing the undated accounts outright, give them a date first and take the closure decision together with their owner.