Compliance Evidence from Your Software Service Provider: What to Ask For

The short answer

Don’t ask whether they’re certified. Ask for what.

An ISO 27001 certificate is always valid only for a defined scope. That scope can cover the entire company, or just a single location, a single department, a single data center. So a provider can write "ISO 27001 certified" on its website with complete accuracy, and your project can still fall outside that scope. The scope is stated on the certificate. It’s the first line you should read, and most supplier questionnaires never ask for it.

The rest of this article goes through the eight pieces of evidence one by one, spells out for each what separates a useful document from a fig leaf, and ends with a look at which of these documents we disclose ourselves.

The eight pieces of evidence

‍

1. ISO 27001 certificate with scope

What you should get: the certificate as a PDF, issued by an accredited certification body, with a validity date and a fully spelled-out scope.

How to spot a weak document: the scope is worded so narrowly that it has nothing to do with your project, or the certificate has expired. ISO 27001 certificates are valid for three years, with annual surveillance audits in between. Ask for the most recent surveillance audit, not just the certificate.

What the certificate doesn’t do: it says nothing about how your specific project is actually run. It confirms that a management system exists and is being followed, not that it translates into good decisions on your project.

‍

2. Data processing agreement under Article 28 GDPR

If your service provider processes personal data on your behalf — and it does the moment it works on a system containing customer data, employee data, or test data drawn from live operations — you need a data processing agreement. Without one, the processing is unlawful, and that liability sits with you, not with them.

The agreement must specify the subject matter, duration, nature and purpose of the processing, the categories of data, and the categories of data subjects. A template agreement with blank annexes doesn’t meet that bar.

One point that regularly gets overlooked: the agreement must spell out what happens to the data once the contract ends. Delete it or return it, your choice, documented.

3. List of subprocessors, including AI tools

This is the piece of evidence that tells you the most today, and the one least often requested.

Every cloud service, every hosting provider, every ticketing system, and every AI tool your service provider uses is a subprocessor. You have a right to know which ones they are. With AI tools, the question gets concrete fast: a developer working with an AI assistant sends source code to that assistant’s provider. Your source code.

So ask in three parts:

• Which AI tools are in use, and who is the provider and where are they based?
• Is training on your input disabled, and where is that stated in the contract?
• What gets fed into the tool, and what explicitly doesn’t?

A service provider who can’t deliver this list within a day doesn’t have one. For what such a list looks like when it actually exists, see our own AI compliance and data protection page.

4. Technical and organizational measures

Article 32 GDPR requires them, and almost every service provider has a document for it. The difference lies in how concrete it is. "Access control" is not a measure; "two-factor authentication for all access to customer systems" is.

Pay particular attention to how test data is handled. Developing against original data from live operations is one of the most common quiet violations in day-to-day project work. The answer you want to hear: development uses anonymized or synthetic test data.

5. Standard contractual clauses and transfer impact assessment

The moment a provider outside the EU is involved — and with AI tools, that’s the norm — the data processing agreement alone isn’t enough. You also need the EU standard contractual clauses and a transfer impact assessment: a documented assessment of whether the destination country offers a comparable level of protection.

For US providers, there’s also certification under the EU-US Data Privacy Framework. It’s publicly searchable, so the provider doesn’t have to just claim it — they can prove it.

6. Data protection officer

Name and contact details, whether internal or external. An externally appointed data protection officer is not a shortcoming — quite the opposite: an external party reviews things without regard for internal hierarchies.

What you should also ask: is the data protection officer involved before new tools are introduced, or do they only find out about them during an audit?

7. Data breach reporting process

Article 33 GDPR gives you 72 hours to report a personal data breach to the supervisory authority. That clock starts running once you become aware of it. If your service provider only passes on an incident after four days, your deadline has already passed before you even know about it.

So have them tell you which address a breach gets reported to, within what deadline, and who on your side gets notified. That belongs in the data processing agreement, not in a letter of intent.

8. Statement on accessibility

Germany’s Accessibility Strengthening Act (BFSG) has been in force since June 28, 2025. If your application reaches end consumers, it must meet WCAG 2.1 at level AA. You’re responsible for that; your service provider implements it.

So ask about the process: is accessibility actually tested, with which tools, and is manual testing part of it too? Automated checks only catch a fraction of the problems. A service provider who only thinks about accessibility when asked isn’t building it in.

The uncomfortable part

Most supplier questionnaires we fill out and send back ask about point 1 and skip point 3 entirely.

That’s the wrong order of priority. The certificate tells you about a management system; the list of subprocessors tells you where your data actually ends up. The second one is the riskier one for you, and it changes faster: a certificate is valid for three years, a new AI tool can be rolled out in an afternoon.

If you take away a single question from this article, make it this one: Which AI tools inside your organization get to see our source code, and what does the contract say about it?

The answer tells you more about a service provider than any certificate. Not because the answer should be "none" — that would be out of touch with reality in 2026. But because a service provider who can answer it precisely has already taken the question seriously.

Frequently asked questions

Do we need a data processing agreement with our software developer?

Yes, as soon as they have access to systems containing personal data. That includes maintenance, support, and troubleshooting on the production system, even if nobody deliberately looks at the data. The mere possibility of access is enough.

Is it enough if the service provider is ISO 27001 certified?

No. The certification is evidence of information security management; it replaces neither the data processing agreement nor the review of subprocessors. And it only applies within its documented scope.

How do we check whether a certificate is genuine and valid?

The certificate states the certification body and a registration number. Accredited bodies maintain public registers where you can look up both. Also check the issue date and the cycle of surveillance audits.

What is a transfer impact assessment?

A documented assessment of whether the data will find a level of protection in the destination country outside the EU that’s comparable to the European standard, and what additional measures are needed. It’s prepared per provider, not as a blanket statement.

Who classifies our application under the EU AI Act?

The roles are assigned by law and aren’t up for negotiation: whoever develops an AI system and puts it on the market under their own name is the "provider." Whoever operates it within their own organization is the "deployer." In custom development projects, you’re usually the provider and your service provider delivers the technical work. That said, the risk classification should still be worked out jointly, because it requires technical knowledge of the system.

What happens to our software if the service provider becomes insolvent?

That’s what source code escrow with a trustee is for, with contractually defined release conditions. Sort this out before the project starts, not after, and make sure not just the source code is deposited but also the build instructions and dependencies. Code without a description of how to build it is worth little when it actually matters.

What evidence applies to the cloud our application runs on?

The same points apply to the cloud provider, who is a subprocessor of your service provider. Get the region and data center location in writing. "In the EU" is not a location.

What we disclose ourselves

We think this is an area where you shouldn’t ask for trust — you should show documents. That’s why the following is public on our site, instead of only surfacing in a supplier questionnaire:

• Certifications: ISO/IEC 27001:2024 for information security and ISO 9001:2015 for quality management.
• Data protection officer: externally appointed, heyData GmbH.
• AI tools in use: each one listed individually, with provider, location, purpose, and the status of its data processing agreement, standard contractual clauses, transfer impact assessment, Data Privacy Framework certification, and training settings. Five tools, one table, no blanket statements.
• What gets fed in and what doesn’t: broken down on the same page, right down to passwords, credentials, and real data from production systems.

You’ll find the table under AI compliance and data protection. It’s deliberately public, so you can read it before you ever talk to us. Compare it with what other providers send on request, and you’ve got the benchmark for this entire article.

For when this evidence is needed over the course of a project, and why it’s so often gathered too late, see Why AI projects fail.

‍

Note: This article is a professional perspective from a software developer’s point of view, not legal advice.

On how this was written: Our content is created with the help of AI, but every piece of text goes through two rounds of human review before it’s published.

‍

Sources

• Regulation (EU) 2016/679, General Data Protection Regulation, in particular Articles 28, 30, 32, 33, and 44 to 49.
• Regulation (EU) 2024/1689, Artificial Intelligence Act (EU AI Act).
• Accessibility Strengthening Act (BFSG), in force since June 28, 2025.
• DIN EN ISO/IEC 27001:2024, Information Security Management Systems.
• Web Content Accessibility Guidelines (WCAG) 2.1, W3C.
• EU-US Data Privacy Framework, public participant list of the U.S. Department of Commerce.