IT Security in the Supplier Questionnaire: What Major Clients Check and What Documentation Matter

A client sends 90 questions with a two-week deadline—and no one in the company knows who’s supposed to fill it out

The file is titled “Supplier Security Assessment” or “Supplier Self-Assessment on Information Security.” It comes from a customer you’ve been working with for years, and the accompanying text includes a sentence that makes the matter serious: Without a complete response, the framework agreement will not be renewed. Attached is a table with questions about multi-factor authentication, patch statuses, encryption, retention periods for log data, and incident reporting deadlines.

For small and medium-sized businesses, this is the most unpleasant form of security requirement: it comes from outside the organization, is non-negotiable, has a deadline, and the answers have legal implications. This article explains where these questionnaires come from, how to answer them without leaving yourself vulnerable later on, which gaps can be closed with software, and which cannot.

Why are we suddenly receiving these questionnaires?

Because your customer has been mandated to do so and is passing that obligation down the chain. This isn’t a sign of mistrust toward you, but rather a chain reaction stemming from three sources.

In Switzerland, the federal government’s minimum ICT standard includes a separate section on the supply chain. It requires that suppliers and service providers be identified, prioritized, and assessed through a risk evaluation process; that contracts obligate them to take appropriate measures; and that compliance be regularly verified through audit reports. Anyone implementing this standard—and utilities, hospitals, government agencies, and their suppliers are increasingly doing so—cannot avoid conducting a supplier assessment.

In the European Union, Article 21(2)(d) of the NIS 2 Directive requires a supply chain security policy that governs relationships with direct suppliers and service providers, including criteria for their selection. Affected organizations pass these requirements on contractually to suppliers who are not themselves subject to the directive.

And in the automotive industry, TISAX—a dedicated audit system—has existed for years; it has replaced individual audits of manufacturers, and its requirements are passed down from manufacturers to second- and third-tier suppliers.

Do we even have to fill out the questionnaire?

A non-regulated supplier is generally not legally required to do so. Contractually, however, the situation is different: The customer may make the business relationship contingent on the provision of this information—and that is exactly what they do. The question is therefore not a legal one, but a business one.

What you can certainly negotiate, however, is the scope. Many questionnaires are standard documents that a large corporation sends to all suppliers—from the data center operator to the carpenter who built the reception desk. Questions about data center access or software development processes are simply not applicable to a company that doesn’t have its own development department. A straightforward “not applicable, as we don’t have our own software development” is a perfectly valid answer and better than a fabricated “yes.”

Also, ask which of the client’s data you actually process. This determines which part of the questionnaire is even relevant to you—and often, this can reduce the scope by half.

Are the answers legally binding?

As a general rule, yes, and that is the most important point of the entire issue. Completed questionnaires are usually attached as an appendix to the contract or referenced in the framework agreement as a warranted characteristic. This turns a checkmark in a table into a contractual assurance.

The practical implications only become apparent in the event of a security breach. If, following an incident, an investigation is conducted to determine how the attacker gained access and it turns out that the warranted multi-factor authentication for remote access was not active at all, the situation is entirely different from that of a company that had openly stated, “No, planned by the end of the quarter.” In the first case, it’s a matter of a false assurance; in the second, a known and accepted risk.

This leads to the only rule that really matters: No “yes” without proof. If you can’t answer a question with certainty, clarify it before checking the box. For extensive framework agreements, it’s worth having the completed questionnaire reviewed by legal counsel before submitting it, because it becomes part of the contract.

Which sections of questions appear almost every time?

The questionnaires vary in structure, but the same ten to twelve topics recur in terms of content. Once you’ve answered them thoroughly, you can reuse most of your responses for the next client.

Typical topics include: access management and multi-factor authentication, especially for remote access and administrator accounts; protection of end devices and servers; software update status and vulnerability management; encryption of laptops and removable storage devices; Data backup, including tested recovery. Logging and how long logs are retained. Incident detection and the reporting deadline to the client. Employee training. Handling of subcontractors. And finally, the location of data processing.

What’s striking is what’s rarely included in this list: certifications. Most questionnaires ask about implemented measures, not about paperwork. A certification helps reduce the effort involved, but it does not automatically replace the answers.

Which questions can be answered with software, and which cannot?

The following overview categorizes the most common areas based on whether a product provides the answer or whether organizational work is required. This distinction is crucial when filling out the questionnaire: For the first group, purchasing a solution is sufficient; for the second, a documented process is needed—one that no one can buy.

Question Category	Can be addressed with software	What else is required
Multi-factor authentication	✓	List of covered access points
Endpoint and server protection	✓	Proof of completeness
Update status	✓	Deadlines for Critical Vulnerabilities
Encryption of Laptops	✓	Procedure in Case of Key Loss
Logging and Retention	Partial	Specified retention period
Data Backup	Partially	Rollback Test Log
Incident Detection	Partially	Designated Responsibility
Deadline for Notifying the Customer	✕	Rehearsed reporting chain
Staff Training	✓	Proof of Participation
Subcontractors	✕	Current list and contracts
Location of data processing	✕	Provider Information

Regarding the three points marked “Partially”: A product can generate logs, but it cannot determine how long you want to retain them—the retention period is a decision you must make and document in writing. Backup software backs up data but does not replace the documented restore test, which is explicitly asked about in the questionnaire. And a detection solution issues alerts but does not replace the person who responds to the alert.

What should I answer if we do not meet a requirement?

“No”—along with an explanation, an alternative measure, and a deadline. This three-part response is almost always accepted in practice and is in any case better than a whitewashed “yes.”

An example of a sound response: “Not currently implemented. Remote access is currently limited to three specifically named administrator accounts and is logged. Implementation of multi-factor authentication is scheduled for the third quarter.” This shows the customer three things: You’re aware of the gap, it’s not left unprotected, and there’s a timeline. This is exactly what a buyer who must be accountable to their own superiors is looking for.

On the other hand, avoid two common pitfalls. First, a blank “yes” that you cannot substantiate when it really matters. Second, the vague reference to the future without a date—“is in the planning stages” reads to the recipient as “will never happen” and regularly leads to follow-up questions that take more time than simply providing an honest deadline.

What counts as proof?

Evidence that comes directly from the system itself, is dated, and shows the scope. A screenshot of a settings page proves that a feature is enabled—not that it works on all devices. But that’s exactly what’s being asked for.

Reports from the central management console are therefore useful: the list of all managed devices with their protection status, the encryption status for each device, the report on open vulnerabilities with their age, the log of the last rollback test, and the training attendance list. All of these reports include a date and a scope, and both of these are what truly matter.

This is also where a central console makes all the difference. A company that has installed security software individually on each device cannot provide a reliable answer to the question of coverage—it can only count what it thinks it knows. A company with centralized management exports a report.

Which products close the most common gaps?

Four areas consistently fall short in surveys, and for all four, there’s an immediately available solution.

Multi-factor authentication. This is the most frequently criticized issue of all, because it directly addresses the most likely point of entry. ESET Secure Authentication ⧉ covers the second factor for remote access and logins. When filling out the questionnaire, be sure to specify which access points you’re marking “Yes” for—questionnaires distinguish between remote access, administrator accounts, and regular logins.

Laptop encryption. What matters here is not so much the encryption itself as the centralized verification that it is active everywhere, along with a procedure for handling lost keys. ESET Full Disk Encryption ⧉ and SOPHOS Central Device Encryption ⧉ manage both from the console. If removable media are also required, ESET Endpoint Encryption Pro ⧉ covers this aspect as well.

Encrypting Laptops: What Matters in Centralized Management
Explains pre-boot authentication, centralized key management, and recovery in the event of a lost password.

Update status and vulnerabilities. The question isn’t whether you update, but within what timeframe critical vulnerabilities are patched and how you can prove it. Bitdefender GravityZone Patch Management ⧉ and Kaspersky Vulnerability and Patch Management ⧉ provide the reports needed to document this timeframe—including third-party applications, which are explicitly mentioned in the questionnaires.

Employee training. Proof of participation is required, not a one-time presentation. Kaspersky Automated Security Awareness Platform ⧉ generates exactly this type of report for each individual and time period.

Patch Management and Proof to Third Parties
Shows how the update status can be documented so that it stands up to audits and customer questionnaires.

How do I answer questions about data backup and logging?

When it comes to data backup, the question is almost never about the backup itself, but rather about recovery. The typical wording is something like: When was the last time a full recovery was tested and documented? If you cannot provide a date, you have not answered the question, no matter how well the backup is running. Acronis Cyber Protect Advanced Server ⧉ handles the backup—you must maintain the log of the restore test, including the date, scope, and the name of the person who performed it.

Logging involves two key details: what is recorded and how long it remains available. Those who rely solely on traditional antivirus protection can answer the first question briefly—and the second not at all. A solution with continuous logging, such as Bitdefender GravityZone Business Security Enterprise ⧉, provides both, because retention periods can be explicitly defined there.

If there are additional requirements for email retention—which is common among customers in regulated industries—this should be handled by a separate system. MailStore Server ⧉ archives emails independently of the mailbox, thereby making the retention period verifiable.

Who should fill out and sign the questionnaire?

It should be filled out by someone familiar with the systems. It should be signed by someone authorized to represent the organization. These are rarely the same people, and this distinction is important because the signature constitutes a formal assurance.

In practice, a three-step process has proven effective: The IT manager or the service provider in charge fills out the form and files supporting documentation for each answer. Management reviews the “no” answers and the committed deadlines, as they will ultimately be responsible for funding these deadlines. Only then is the document sent out.

If an external IT service provider fills out the form, clarify in advance who is responsible for its accuracy. The service provider knows the technical answers but cannot make a commitment on behalf of your company.

How do I prevent every client from starting from scratch?

By maintaining your own database of responses instead of processing each questionnaire individually. For each recurring topic, create a response in two lengths: two sentences for table fields, one paragraph for free-text fields. Include the corresponding supporting document with the date for each.

Three things ensure this database remains up-to-date. First, include a revision date for each response so you can see what’s out of date. Second, conduct a regular review—ideally once a year and additionally after any major changes. Third, the distinction between documented responses and statements of intent—as soon as a promised deadline passes without the action being implemented, the response must be updated before it is sent out again.

The effort required for the first questionnaire is thus significantly higher, while that for the second and third is significantly lower. Companies that regularly receive such inquiries save themselves the bulk of the work this way.

Is certification worth it instead of individual questionnaires?

Yes, once you reach a certain number of inquiries, and the math is simple: as soon as you spend more time on questionnaires than certification would require, the balance shifts. The three approaches differ significantly in scope and effort.

Criterion	ISO/IEC 27001	TISAX	Swiss SME Label
Who requires it	Across all industries	Automotive industry	Swiss customers
Basis	Management system	VDA-ISA Catalog	Tailored to SMEs
Result	Certificate	Label, not a certificate	Label
Validity period	See note	Three years	See note
Results can be reused multiple times	✓	✓	✓
Completely replaces individual questionnaires	✕	In the industry	✕
Cost for a small business	High	High	Medium

Regarding the open fields: The validity period of an ISO 27001 certificate and the Swiss SME labels depends on the respective certification body and the frequency of surveillance audits and is therefore not specified here in general terms—the only reliable information is for TISAX, where the label is valid for three years. The most common Swiss SME labels are Cyber-Safe and, for IT service providers, CyberSeal; they are specifically aimed at companies that do not seek ISO certification.

What exactly is TISAX, and when do we need it?

TISAX is the automotive industry’s audit and exchange system, operated by the ENX Association on behalf of the German Association of the Automotive Industry (VDA). It is based on the VDA-ISA questionnaire, which largely overlaps with ISO 27001 in terms of content but supplements it with industry-specific topics such as prototype protection.

The practical advantage is right there in the name: The result is determined once by an accredited audit service provider and then shared specifically with multiple clients via the ENX platform. Instead of undergoing a separate audit for each manufacturer, you share a single result. The label is valid for three years, after which a reassessment is required. Formally, it is not a certificate but a label—a distinction that occasionally causes confusion in request for proposal documents.

You’ll need it if you work as a supplier, development partner, or IT service provider for automotive manufacturers. This requirement is increasingly being extended to second- and third-tier suppliers as well. For all other industries, TISAX is not the right approach.

How does this relate to the Swiss ICT Minimum Standard?

The federal government’s ICT Minimum Standard is the most common source of such questionnaires in Switzerland. It is structured around the five functions of identify, protect, detect, respond, and recover; it is primarily aimed at operators of critical infrastructure and their suppliers; and it serves as a set of recommendations.

It is of interest to suppliers for two reasons. First, its section on the supply chain explains why the questions are being asked and in what form the customer expects evidence—namely, on a regular basis and in report form. Second, it serves as a useful self-assessment tool: it evaluates each measure on a maturity scale rather than simply requiring a “yes” or “no” answer. Anyone who works through it once for their own organization will already have most of the questionnaire answers ready and will also have a clear understanding of their gaps in order of priority.

What it is not: a certificate. You cannot rely on it as such; you can only use it to demonstrate implementation.

What does the NIS 2 Directive require of us if we are not directly affected?

Nothing directly, but quite a bit indirectly. The directive requires affected organizations to establish a supply chain security policy that governs their relationships with direct suppliers and sets criteria for selecting them. These organizations fulfill their obligation by passing the requirements on contractually—to you.

For you as a supplier, this means: You are not subject to any registration or reporting requirements with a government agency, but you are bound by contractual commitments to your customer. Reporting deadlines are particularly common—the customer must report incidents within short timeframes and therefore needs your information sooner. Examine such clauses carefully: A commitment to report an incident within twelve hours assumes that you will even notice it within twelve hours.

Whether your own business might be affected due to its sector and size is a separate assessment that is not covered here.

What obligations apply, and at what company size?
Determine at what point reporting obligations, customer requirements, and documentation requirements actually take effect for a business.

What applies to customers in the financial sector?

The requirements there are significantly more precise. The European Regulation on Digital Operational Resilience requires financial firms to maintain a complete register of all contractual relationships with information and communication technology providers and to include certain minimum provisions in these contracts.

Specifically, this means for you as a provider: Expect clauses regarding inspection and audit rights, the obligation to disclose subcontractors, and defined termination scenarios. This goes beyond the usual questionnaire and pertains to the contract itself. If a financial client presents you with a contract containing such clauses, this is not a matter of negotiation but rather their own legal obligation.

Those who serve both Swiss and European clients regularly face two sets of regulations side by side. A detailed comparison is beyond the scope of this article.

A Comparison of Cybersecurity Obligations in Switzerland and the EU
It compares the Swiss reporting requirement with the requirements of the NIS 2 Directive and highlights where they differ.

How can I protect myself when responding?

By being precise about the scope. Most disputes arise not because someone lied, but because an answer was interpreted more broadly than intended.

Four habits can help with this. In each answer, specify exactly what it refers to—“all Windows laptops,” not simply “yes.” Date the questionnaire and note which version it refers to, so that information from two years ago isn’t treated as a current assurance. Do not make commitments on behalf of third parties over whom you have no control; regarding subcontractors, state what is contractually agreed upon, not what you assume. And keep a record of who provided which answer internally so that the basis for a statement can be traced later.

One final point that’s often overlooked: Promised deadlines must be tracked. A questionnaire with three open-ended actions and three deadlines creates three commitments—if you don’t include them in a follow-up report, you’ll face the same gaps and an unfulfilled commitment at the next audit. That’s worse than the original gap.

How do I actually get started?

Not by filling it out. First, go through the entire questionnaire and mark each question with one of four colors: definite “Yes” with supporting documentation, definite “No,” unclear, or not applicable. This sorting process takes an hour and immediately shows where the real work lies.

Then work through two piles. Clarify the “unclear” questions from a technical standpoint before checking any boxes. Sort the “No” answers based on what can be obtained and documented in the short term—multi-factor authentication, encryption, patch management, and training certificates usually fall into this group—and what requires an organizational process, such as the reporting chain or the playback test. For the first group, a purchase order is sufficient; for the second, you’ll need a designated person and a deadline.

And keep the goal in mind: The customer doesn’t want to see a flawless operation, but one that understands their situation. An honest questionnaire with four “no” answers and four scheduled dates builds significantly more trust than a column full of checkmarks that falls apart at the first follow-up.

 

---