Industrial Cybersecurity Questions German Buyers Ask Suppliers
German industrial buyers need to understand how a connected product or service affects operational risk. They ask about assets, access, updates, vulnerabilities, monitoring, incident response and lifecycle support, not only whether the supplier holds a certificate.
The exact questionnaire depends on the buyer, sector, system and contract. Suppliers should maintain one controlled answer source and tailor it to the installation.
What industrial cybersecurity questions do buyers ask suppliers?
Buyers ask what the product connects to, which data it handles, how identities and remote access work, how updates and vulnerabilities are managed, what logs are available, how incidents are reported and how long the product is supported.
Germany's Federal Office for Information Security, BSI, publishes industrial control system security guidance. Use the buyer's requirements and current applicable rules as the controlling source.
| Buyer question | Supplier evidence |
|---|---|
| What connects? | Architecture, protocols, ports and data flows |
| Who can access? | Roles, authentication and approval process |
| How is remote support controlled? | Time-limited access, logging and revocation |
| How are updates handled? | Signing, testing, deployment and rollback |
| What happens to a vulnerability? | Intake, assessment, notification and remediation |
| What can be monitored? | Logs, events, timestamps and retention |
| How is an incident handled? | Contacts, severity, evidence and communication |
| How long is support provided? | Versions, end-of-support policy and migration route |
Industrial cybersecurity supplier question map covering product, access, updates, monitoring, incident response and lifecycle.
Define the product boundary
List hardware, software, cloud services, mobile applications, gateways and third-party components included. State what the buyer must provide and secure.
Create a data-flow diagram showing zones, connections, trust boundaries, protocols and external services. Label optional remote access rather than drawing it as a permanent connection when it is not.
Explain identity and access
Document default accounts, initial setup, role model, password or key requirements, service accounts, emergency access and removal. State whether the product supports the buyer's identity systems.
For remote maintenance, answer:
- who approves a session
- how identity is verified
- whether access is time-limited
- what actions are logged
- how access is revoked
- what happens without connectivity
- which subcontractors may connect
Avoid saying "secure remote access" without this operating process.
Make update support specific
State how the supplier learns about vulnerabilities, tests updates, signs packages, informs customers, delivers the update and supports rollback. Explain the expected buyer action and operational downtime.
Provide support dates or a policy for each major version. Buyers need to know whether a system expected to operate for years will continue receiving fixes.
Prepare a vulnerability response
Give customers a reporting contact and required information. Define acknowledgement, assessment, severity communication, workaround, remediation and disclosure processes.
Do not promise universal resolution times without scope and severity. State the response framework and contract-specific service commitment.
Show logs and monitoring capability
List events generated by the product: sign-in, configuration change, update, remote session, alarm, service restart and security-relevant failure. State format, timestamp source, retention, export and integration options.
A screenshot is not enough. Give a sample event definition with fields and meaning.
Separate product and deployment responsibilities
Use a responsibility matrix for hardening, network placement, firewall rules, accounts, backups, time synchronisation, monitoring, patch approval, incident response and decommissioning.
The supplier should not claim to secure the buyer's whole OT environment. The buyer should not assume the supplier controls infrastructure outside the product boundary.
Prepare evidence for secure development
Buyers may ask how security requirements enter design, how third-party components are tracked, how code and releases are reviewed and how test findings are closed. State the process and product scope without publishing exploitable detail.
Maintain a component inventory or equivalent record appropriate to the product. Be ready to explain how the supplier learns that a dependency is affected, assesses exposure and communicates action to customers.
Address backup and recovery
State which configuration, logic, keys or data the buyer must back up, the supported restore method and how a replacement device is returned to service. Test the recovery procedure on the current product version.
For systems with safety or production consequences, describe the degraded operating mode and manual fallback. Cybersecurity readiness includes recovery, not only prevention.
Keep questionnaire answers current
Assign owners for architecture, product security, support, legal and commercial responses. Give answers a version and review trigger. A copied questionnaire can become inaccurate after a firmware, cloud service or support-policy change.
Supplier readiness checklist
- Product and service boundary documented
- Data flows, ports and protocols current
- Default and service accounts controlled
- Remote access has approval, logging and revocation
- Update process includes testing and rollback
- Vulnerability reporting contact published
- Logging fields and export options defined
- Incident roles and communication route agreed
- Support and end-of-life policy visible
- Deployment responsibilities assigned
Prepare a buyer response pack
Keep a controlled pack that answers repeat questions without sending the same oversized folder to every prospect. The index should identify the product and version, support period, update process, vulnerability contact, secure configuration guide, logging capability, backup assumptions and the split of responsibilities between supplier, integrator and operator.
For each item, mark whether it can be shared publicly, under a confidentiality agreement or only during a controlled review. Name an owner and review trigger. A new firmware branch, changed component, support policy or reported vulnerability should prompt a check. Test the pack with a sales engineer and a security reviewer: one should be able to assemble a relevant response quickly, and the other should be able to trace every claim to an approved source. Measure unanswered questions and repeated clarifications. They show where product documentation or the responsibility model is still unclear.
Creatif Work helps engineering suppliers explain technical systems without publishing sensitive configuration. Our website service can create a controlled public trust layer, while custom software can support approval and evidence workflows when access, updates and incidents need consistent records.