Cybersecurity BlogProof of IT security for customers: what to do when a client asks about your security

• Why the request arrives: Under NIS2, DORA, ISO 27001 or TISAX®, your customer has to document that they assess their suppliers. They pass that requirement on to you.
• What counts as proof: a certificate, a self-assessment or an external technical review. The completed questionnaire alone is accepted less and less often.
• What to expect: Some customers run the check themselves without asking. Whatever is visible from the outside can be queried by anyone.
• Open findings: don’t need to be hidden. A consciously accepted residual risk with justification, compensating control and deadline is a valid audit result.

Germany’s NIS2 implementation has been in force since 6 December 2025, and in Austria the NISG 2026 takes effect on 1 October 2026. Around 4,000 Austrian companies fall directly under it. All of them have to assess the security of their supply chain and document that assessment. It can’t be delegated, and it can’t be guessed. So they ask their suppliers. The same is happening under DORA in the financial sector, in every ISO 27001 certification with its supplier assessment, and under TISAX® in automotive supply.

There is a simple reason why the request often sounds so unspecific: the procurement checklist says „obtain proof of cyber security“, not „obtain a report on the externally reachable attack surface“. Whoever sends something usable first often sets the standard for that supply chain.

Three types are accepted: a certificate, a self-assessment and an external technical review. They prove very different things. Which one is required depends mainly on how critical the customer considers the supplier relationship.

Usually yes, it is the strongest of the three. The certificate proves a working information security management system, including technical obligations: vulnerability management under Annex A 8.8, hardening, security testing and, depending on the risk assessment, regular penetration tests. The premier discipline, in other words.

But no one will ask a supplier for it at short notice, because certification is a process that runs for months. It is required where it has been contractually agreed, for example for service providers with access to customer systems or in automotive supply. If the customer needs something within four weeks, a certification project won’t help. And it isn’t mandatory for suppliers anyway: NIS2 requires the customer to assess you, not you to be certified.

Often yes, but less and less. The completed questionnaire mainly covers organisational topics: responsibilities, backup concept, contingency plans, training, reporting lines. That isn’t worthless, but it remains a statement about your own company, made by your own company.

The usual approach today is a combination of questionnaire and technical proof. For critical suppliers, meaning those where an outage or a data leak hits the customer directly, the requirement sometimes goes as far as a penetration test with a report.

It answers the question the auditor asks: what does an attacker see today when they enter your domain into a tool? The externally reachable systems are reviewed, at CheckFix for example in five categories:

• mail security, meaning SPF, DKIM and DMARC for the domain
• TLS/SSL encryption of the reachable services
• known vulnerabilities (CVEs) in the versions in use
• security headers of the web services
• open ports and services reachable from the internet

Serious reviews don’t work arbitrarily, they follow documented methodologies: NIST SP 800-115 for the approach, the Qualys SSL Labs SSL Server Rating Guide for TLS, the Mozilla HTTP Observatory rating for security headers, the BSI guideline TR-03182 for email authentication, CVSS for vulnerabilities. Where no standard exists, experience from penetration testing fills the gap. That is why such a report holds up in an audit: the assessment is traceable and repeatable.

This kind of analysis is non-invasive. Nothing is exploited and nothing is broken into. It therefore does not replace a penetration test.

Yes, and some do exactly that. They run the review themselves and then put the result on the table.

Querying what a server answers publicly is not an intrusion. An expired certificate, a missing DMARC record, a reachable database: that is the outside view anyone can see, including people who don’t mean well. Actively exploiting vulnerabilities is a different matter and requires written authorisation.

And that outside view is the point. The most common entry paths are not sophisticated zero-days, they are reachable services with known gaps, weak encryption and access routes nobody remembers any more. Attackers scan automatically for these patterns and take whatever is quick. That is why auditors and procurement departments accept an external technical review as proof, usually alongside the organisational questionnaire.

Two questions in return save a lot of work:

1. What is the proof needed for, and which requirement is behind it?
2. In what form, and by when?

If a concrete answer comes back, it is clear what to deliver. If none comes back, that is information too: the request is a formality, and a solid external security report satisfies it.

The process differs from tool to tool. Many solutions need to be set up first: define targets, choose scan profiles, sometimes provide credentials or agents. With CheckFix, a business email address is enough. The system determines the rest by itself, meaning subdomains, IP addresses, reachable services and certificates. The result is an overall rating from A to F plus a grade per category. The overall grade equals the worst category, so a critical gap cannot be offset by good results elsewhere.

More interesting than the grade is what comes next. A report that only says „security headers missing“ doesn’t help the IT team. A useful result delivers four things:

• a prioritised task list naming affected hosts, IPs and ports instead of a plain list of findings
• an urgency level based on exploitability rather than an abstract risk value
• the option to re-check after remediation
• a report that holds up in an audit, even when not every gap could be closed straight away

The genuinely strong proof is the re-check. It doesn’t show a state, it shows a development: on 3 March twelve items were open, on 14 April there are two. That is the documentation the auditor wants to see at your customer, and it is worth more than a single good score.

The CheckFix security check with an A to F rating is free, the full ToDo CheckList including report and re-check starts at 490 euros per year. Typical findings can be cleared in a few hours: a certificate issued for the wrong hostname, DMARC set to none instead of an effective policy, a missing redirect from HTTP to HTTPS, a remote access route left over from an old project that nobody has switched off in years.

Document them instead of hiding them. Not every finding can be closed, and that is not automatically a problem.

Your hosting provider runs a server where known vulnerabilities haven’t been patched. You can’t intervene there yourself, you can only insist and, if nothing happens, change provider. Or a port has to stay open because a customer collects data through it. Then it stays open, but the conditions around it have to be right: encrypted transport instead of plaintext FTP, an IP whitelist instead of „reachable from anywhere“, a separate account per partner, logging. The same applies to the old machine controller that only speaks TLS 1.0. If it has to stay, it belongs in its own segment and not directly on the internet.

What disqualifies you is not the open gap. It is keeping quiet about it.

Every open item therefore needs a short statement: why it stays open, which compensating control is in place, when a solution will arrive, who is responsible, and when the decision will be reviewed again. With CheckFix this document is generated straight from the dashboard, with a management response and action plan for every open finding. It is available to every CheckFix customer, not only to suppliers invited through a client’s Risk Manager.

A question that comes up more and more often: where does the data from such a review actually go? The result is a list of your reachable systems along with their weaknesses, and many people don’t want that list sitting with a provider outside the EU.

CheckFix runs on European infrastructure, hosted at Hetzner. The scan works rule-based along the methodologies named above, no AI is involved unless an AI penetration test is explicitly commissioned, and no scan data goes to any external AI service. With a customer who is subject to NIS2 themselves, this question will come up sooner or later.

An external analysis shows the outside view. It says nothing about your internal network, your backups, your contingency plans or your process documentation. It replaces neither an ISMS nor a penetration test.

And its significance is asymmetric: a poor result is a reliable warning signal, a good result is necessary but not sufficient. Anyone selling you more than that is selling you too much. Which is why most customers ask for both, the technical proof and the organisational questionnaire.

A security request from procurement feels like extra work with no return. But it is the only moment when a customer raises cyber security on their own initiative. Whoever answers with a report and an action plan, rather than a hastily filled questionnaire, stops being a risk in the eyes of procurement and becomes a supplier you can plan with.

And the next customer who asks receives the same documents within five minutes.