The Software Vendor Touching a Customer's Production: Where Should the Evidence Live?

Unlike most articles on this subject, this one is written from the supplier's point of view, not the customer's. You build banking software. Or you run an organisation's databases as a managed service. Or you are a systems integrator going live in the customer's environment. Whichever it is, someone on your team now and then touches the customer's production database: a fix, a data migration, an investigation, a release installation. One day the customer's auditor or a regulator asks: "Who did what to the database on that date?" Who holds the answer?

September's Picture: Breaches at the Data Processor

In September 2026 the Turkish data protection authority announced 44 data breach notifications. In all 28 notifications of the first wave the breach occurred not in the data controller's own systems but at a data processor it used. Most stemmed from a software vulnerability in a shared e-commerce infrastructure. The legal framework is also clear: Article 12 of Law No. 6698 holds the controller and the person processing data on its behalf jointly responsible for taking data security measures.

So a supplier touching a customer's production database can legally be a party to a breach. And the sentence "it was not our team" can only be proven by a record.

The Supplier's Two Risks

1. No evidence. When a problem arises and there is no record to say "our team did not do this" or "they did it but it was an approved job", the burden of proof falls on the supplier.
2. Access creep. Over the years a supplier's staff accumulate permanent accounts in the customer's environment. A leaver's account is not closed, a project's access continues after the project ends. This is a risk for both customer and supplier.

One case shows the danger of these two risks: at a crypto exchange, an external supplier's support staff were bribed and gave access to the exchange's internal support tools. The data of about 70,000 customers was affected. The company estimated the cost at up to USD 400 million and a regulatory review was opened. The door for the attack was the supplier's access.

Where Should the Evidence Live?

The right answer is the same for both sides: the evidence should live on the customer's own network under the customer's control, but the supplier must be able to reach it.

• Why with the customer? Auditors and regulators come to the customer; if the evidence is there the answer is fast. A record in the supplier's own system is not neutral evidence, because a supplier can change its own record. Customer data does not leave the customer's network.
• Why must the supplier be able to reach it? The supplier has to be able to defend itself: "this request, with this approval, with this text." The supplier's own internal audit and quality process want this too.

How Is It Set Up?

SQL Change Guard is installed on the customer's own network. This is how supplier staff touch the customer's production:

• Every person is a user by name. There is no shared account. Whoever performed an operation, it is recorded under their name.
• Roles and permissions are defined at the customer. Whether a supplier employee has been given approval authority is the customer's decision and shows in the user and role list.
• Every job is a request. The reason, risk band, approvals, digest of the text that ran and the result sit in one record.
• Segregation of duties rules are switched on at the customer. Rules that stop the requester from approving and executing their own request are an organisation setting. The customer switches them on; whether they are on is visible on the Governance Setup Check screen and in the evidence file. When they are off the audit file shows it as an exception. When on, this is internal control on the supplier side as well.
• Evidence is packaged in a single file. The customer's auditor can verify the file outside the product too; the supplier uses the same file in its own defence.
• Access creep is visible. The user and role list and permission changes are reported. Closing access when a project ends becomes a report line, not an oversight.

A Commercial Advantage for the Supplier

This is not only a defence. For a supplier whose customers are regulated, "we touch the customer's production with evidence" is a sales argument. One of the questions asked often in supplier assessments by banks and regulated institutions is: "How are the staff who touch our environment supervised?" A supplier whose answer is a policy document and a supplier whose answer is an evidence file are not in the same place. The same logic holds for managed service providers: a separate installation for each customer and a separate set of evidence. Customer A's record never mixes with customer B's.

The Honest Limits

• The product runs on the customer's network. It is not a multi tenant service managing all of a supplier's customers from one cloud panel. Each customer has its own installation.
• It does not prevent a supplier connecting directly to the customer's database. If a person can connect with their own account, detecting it is the job of the customer's database activity monitoring and SIEM. The right design: one channel, the request, and an alarm for access outside it.
• The supplier's own development environment is out of scope. The product governs the route to the customer's production.

Five Questions to Ask Yourself as a Supplier

1. Did someone on your team touch a customer's production database last month? How many times, for what work?
2. Is the record of each of these somewhere the customer can also reach?
3. If a customer's auditor asked "what was done that day", how many minutes would it take you to answer?
4. Have the accounts and access for finished projects been closed?
5. When a staff member leaves, which customer environments are their accounts closed in, and who checks?

Frequently Asked Questions

Can a supplier touching a customer's production be legally liable?

Yes. Article 12 of Law No. 6698 holds the controller and the person processing data on its behalf jointly responsible for taking data security measures. "It was not our team" can only be proven by a record.

Should the evidence live with the supplier or the customer?

On the customer's own network under the customer's control, with the supplier able to reach it. A record in the supplier's own system is not neutral evidence, and customer data does not leave the customer's network.

Is segregation of duties mandatory for supplier staff?

Segregation of duties rules are an organisation setting; they become mandatory when the customer switches them on. Whether they are on is visible on the Governance Setup Check screen and in the evidence file; when off, the audit file shows it as an exception.

Does SQL Change Guard manage several customers from one panel?

No. The product is installed on the customer's own network and is not a multi tenant cloud service. Each customer has its own installation and its own set of evidence.