Sie sehen
ein Interface.
Wir betreiben 13 Schichten.

ISO/IEC 17025:2017 §7.11.3 fordert Schutz des Informationssystems gegen unbefugten Zugriff und Manipulation. ISO/IEC 27001:2022 A.8.3 fordert Least-Privilege-Zugriffskontrolle. In einer geteilten Umgebung sind Cross-Tenant-Risiken, Konfigurationsdrift und unkontrollierte Update-Wechselwirkungen reale Risiken für Vertraulichkeit und Verfügbarkeit. Die dedizierte Instanz reduziert diese Risiken auf Instanzebene. Treten dennoch Sicherheitshinweise auf — etwa durch CVE-Monitoring oder Auffälligkeiten im zentralen Observability-Stack — werden diese als generischer Sicherheitspatch für alle Instanzen gleichzeitig behandelt. Strenge Mandantentrennung und zentrales Monitoring schließen sich nicht aus, sondern ergänzen sich.

ISO/IEC 17025:2017 §8.4.2 fordert Schutz von Aufzeichnungen gegen unbeabsichtigte Änderung. Ein direkter Datenbankzugriff — etwa über administrative Werkzeuge — erzeugt Änderungen außerhalb des Audit Trails. Das ist ein strukturelles Integritätsrisiko. Die API-Schicht ist die Maßnahme, die sicherstellt, dass jede Datenoperation authentifiziert, autorisiert und vollständig im Audit Trail erfasst ist — ohne Ausnahme.

ISO/IEC 17025:2017 §7.5.2 fordert, dass Änderungen an technischen Aufzeichnungen zurückverfolgbar sind — Original und Änderung müssen beide vollständig erhalten bleiben. §8.4.2 fordert Schutz gegen Änderung und Verlust. Ein Audit Trail, der selbst veränderbar ist, erfüllt diese Anforderungen nicht. Die Unveränderbarkeit auf Datenbankebene ist die Maßnahme gegen das Integritätsrisiko.

ISO/IEC 17025:2017 §4.2 fordert Vertraulichkeit aller Informationen des Labors. §7.11.3 a) fordert Schutz vor unbefugtem Zugriff. DSGVO Art. 32 fordert technische Maßnahmen, die dem Risiko angemessen sind — Zugriffsbeschränkung ist explizit genannt. Ein seitenbasiertes Rollenmodell ist nicht ausreichend granular: das Risiko einer unzulässigen Datenänderung mit Auswirkung auf Akkreditierungsunterlagen wird erst durch RBAC auf Entitätsebene strukturell reduziert.

ISO/IEC 17025:2017 §7.11.2 fordert, dass Änderungen an Informationssystemen vor Implementierung autorisiert, dokumentiert und validiert werden. EUROLAB TR 01/2024 §6.5 (Acceptance Testing) fordert nachvollziehbare Qualifizierung vor Inbetriebnahme. Bei einem manuellen Deployment-Prozess müsste die Systemkonfiguration bei jeder Inbetriebnahme und bei jedem Änderungsnachweis separat dokumentiert werden — mit dem Risiko von Abweichungen zwischen dem dokumentierten und dem tatsächlichen Zustand. Infrastructure as Code macht die Konfiguration zum unveränderlichen Bestandteil des Codes: der dokumentierte Zustand ist zugleich der deployte Zustand.

DSGVO Art. 44 ff. verbietet Drittlandsübermittlung personenbezogener Daten ohne angemessene Schutzmaßnahmen. Der US CLOUD Act ermächtigt US-Behörden, auf Daten bei US-kontrollierten Unternehmen zuzugreifen — auch bei europäischen Tochtergesellschaften. Das ist das Risiko einer erzwungenen Drittland-Offenlegung, das durch vertragliche Zusicherungen allein nicht vollständig ausgeschlossen werden kann. Die Wahl eines Rechenzentrumsbetreibers ohne US-Konzernmutter eliminiert dieses Risiko auf Infrastrukturebene. Für die Azure-Backups gilt: die Daten liegen verschlüsselt vor, und die Schlüssel sind ausschließlich aus dem Netzwerk von AUDITTRAILS Networks GmbH anwendbar — im Falle einer erzwungenen Offenlegung wäre ausschließlich Ciphertext zugänglich.

ISO/IEC 27001:2022 A.8.8 fordert, Schwachstellen in eingesetzter Software zu identifizieren und zu beheben. NIS-2 (§30 BSIG) verlangt, Lieferanten in die Risikobetrachtung einzubeziehen. Der EU Cyber Resilience Act 2024/2847 macht SBOM ab Dezember 2027 zur Pflicht für Hersteller vernetzter Produkte. Das Risiko ist konkret: eine bekannte Schwachstelle in einer Software-Abhängigkeit bleibt unentdeckt, wenn die Zusammensetzung der eingesetzten Software nicht dokumentiert ist. SBOM und CVE-Monitoring sind die Maßnahmen gegen dieses Lieferketten-Risiko.

DSGVO Art. 32 fordert Verschlüsselung als technische Maßnahme, wo das Risiko für die Rechte betroffener Personen erheblich ist. EU CRA Anhang I fordert Security by Design. NIS-2 (§30 BSIG) fordert ein dokumentiertes ISMS. Die DEKRA-Zertifizierung bestätigt nicht die Sicherheit des Produkts als solche, sondern dass der Prozess der Konzeption, Entwicklung und Bereitstellung im Rahmen eines geprüften Informationssicherheits-Managementsystems stattfindet. Informationssicherheitsmaßnahmen aus diesem Prozess wirken sich direkt auf die Sicherheit des Systems aus.

ISO/IEC 17025:2017 §7.11.4 fordert, dass extern betriebene Systeme die Anforderungen des Labors kontinuierlich erfüllen — Verfügbarkeit eingeschlossen. ISO/IEC 27001:2022 A.8.6 fordert Kapazitätsüberwachung. Das Risiko ist konkret: eine ausgeschöpfte Festplatte verhindert das Schreiben neuer Aufzeichnungen. Das gefährdet die Dokumentationspflicht nach §7.5 der 17025 unmittelbar. Reaktives Handeln nach Eintritt des Ausfalls ist in einem Akkreditierungskontext keine akzeptable Strategie.

ISO/IEC 17025:2017 §7.11.4 fordert, dass extern bereitgestellte Systeme die Anforderungen des Labors erfüllen — das umfasst nicht nur Verfügbarkeit, sondern auch Leistung. Das Risiko: ein System, das erreichbar ist, aber unter Last messbar langsam reagiert, beeinträchtigt Arbeitsabläufe und kann die Dokumentation zeitkritischer Vorgänge verzögern. Distributed Tracing ermöglicht es, Engpässe zu lokalisieren und strukturell zu beheben, bevor sie zu Ausfällen werden.

ISO/IEC 17025:2017 §7.11.2 fordert, dass Änderungen an Informationssystemen vor Implementierung validiert werden. Die Validierungsumgebung ist keine optionale Komfortfunktion — sie ist normative Anforderung. Daneben adressiert die Single-Tenant-Architektur spezifische Risiken: das Risiko von Ressourcenkonkurrenz zwischen Kunden (Noisy-Neighbor-Effekt, Auswirkung auf Verfügbarkeit), das Risiko unbeabsichtigten Datenzugriffs über gemeinsame Datenbankstrukturen sowie das Risiko unkontrollierter Update-Wechselwirkungen. Trotz dieser Isolierung ermöglicht das zentrale Monitoring, dass sicherheitsrelevante Erkenntnisse als generische Maßnahme für alle Instanzen gleichzeitig umgesetzt werden.

ISO/IEC 27001:2022 A.8.15 fordert, Protokollierungsereignisse zu erzeugen, zu schützen und aufzubewahren — Schutz vor Manipulation ist explizit gefordert. Ein Log, der nachträglich änderbar ist, ist als Sicherheitsnachweis wertlos. Im Oktober 2025 hat DEKRA (Abweichung Nr. 6) genau dieses Defizit festgestellt: Logs lagen vor, waren aber nicht schreibgeschützt. Object Lock im COMPLIANCE-Modus ist die Maßnahme, die Unveränderbarkeit unabhängig von der Anwendungskonfiguration und unabhängig von kompromittierten Zugangsdaten sicherstellt — auch Root kann innerhalb der Frist nicht löschen.

ISO/IEC 17025:2017 §7.11.4 fordert, dass extern betriebene Systeme Verfügbarkeit und Wiederherstellbarkeit sicherstellen. ISO/IEC 27001:2022 A.8.13 fordert Datensicherung, A.8.14 Redundanz. EUROLAB TR 01/2024 §6.15 empfiehlt die 3-2-1-Regel für Backups. Das strukturelle Risiko einer SLA, die nur die Anwendungsschicht abdeckt: fällt die Infrastruktur aus, liegt die Verantwortung bei einem anderen Vertragspartner als die Anwendung — Zuständigkeitslücke im Störungsfall. In unserem Modell gibt es diesen Zuständigkeitsbruch nicht.