Six frameworks that matter for plating shops

Automotive OEM customers increasingly ask their suppliers for evidence of data security. In Germany, the NIS2UmsuCG has been in force since December 2025; in Austria, the NISG (Austria's implementation of NIS2) takes effect in October 2026; Switzerland handles reporting obligations on its own through its Information Security Act. This page shows which frameworks were addressed for the Site Assessment, the Feasibility Project and a later live system, and what the implementation looks like in practice.

Compliance is not an end in itself. When your major customers audit you or the authorities make inquiries, you need to be able to show that your software suppliers also meet the requirements. The overview below is written so that you can pass this page around internally or go through it together in the intro call.

EU AI Act

Regulation (EU) 2024/1689 · applies in stages from 2025/2026

The EU sorts AI systems into four risk classes. The anomaly detection is designed as an advisory system: unusual patterns are flagged, and a trained specialist always decides how to respond. Based on our own assessment, it is not a high-risk use case under Annex III; the classification should be confirmed case by case with your compliance team. For every flagged anomaly you can trace which sensors and which data patterns caused it (explainable AI). No automatic intervention in the line.

NIS2 / NISG 2026

Directive (EU) 2022/2555 · NISG implementation in Austria from October 2026

The NIS2 Directive requires larger industrial companies to carry out cybersecurity risk analysis, incident reporting and supply chain security. Smaller shops are not covered directly — but major customers subject to NIS2 pass the requirements on to their suppliers. The methodology is documented so that it can serve as evidence for customers who audit you: patch processes, logging, procedures for security incidents.

EU Cyber Resilience Act (Regulation (EU) 2024/2847)

Reporting obligations from September 11, 2026 · full application December 11, 2027

The Cyber Resilience Act focuses on secure development processes and supply chain security. Every code change goes through seven automated checks (including static code analysis, dependency checks and a license check), releases are cryptographically signed with a hardware token, and every change can be traced with author and time across the entire history. The response time for critical security updates is agreed in the maintenance contract.

GDPR

Regulation (EU) 2016/679 · Art. 32 security of processing

Only machine data is processed — sensor values, process parameters, complaint statistics. Personal data goes neither into the analysis nor into the model. The security requirements of Article 32 are implemented anyway: encryption in transit, access control, documented deletion after the project ends, on request. If data exports accidentally contain personal data (for example, operator names in shift logs), it is removed before the analysis and the procedure is recorded in writing.

IEC 62443-3-3

Industrial Control Systems Security · Edition 2013

IEC 62443 is the central standard for cybersecurity in industrial control systems. A key principle is one-way data flow: data may flow from the line to the analysis, never back. That way, a compromised analysis system cannot use this path to interfere with the production process. This separation is built firmly into the architecture — the analysis runs on an isolated local system with read-only access. No write access to PLCs, bath controls or line equipment. This is not just a technical measure but also a contractual commitment.

TÜV AUSTRIA Trusted AI

Inspection Framework · model audit completed June 2026

TÜV AUSTRIA offers a voluntary model audit for AI systems used in industry. The review covers, among other things, statistical validation, reproducibility, how model drift is handled and the separation of training and validation data. The inspection took place from late April to late May 2026, based on the submitted documentation and an audit meeting with a live demonstration of the model, and was completed in June 2026. The inspection report confirms that the system meets the expected requirements for its risk class and shows an advanced level of maturity in development and documentation. An excerpt from the management summary is available under Credentials.

How this is organized day to day

The internal data security processes follow the principles of ISO/IEC 27001 — risk assessment, access control, documented procedures, incident response. Development runs on a separate work device with disk encryption, multi-factor authentication and a hardware token for code signing. Real customer data stays exclusively on the local system; development tests use synthetic data from a digital twin.

A non-disclosure agreement is signed before every project starts. Your data stays in a protected environment throughout the entire project and, if you wish, is completely deleted after the project ends, with written confirmation.

Questions or a specific need?

If you need a detailed compliance report — for example, for your major customer's compliance department or as an attachment to a funding application — we will send you the document on request. The intro call is also a good place to talk through your specific audit context.