Dr.DOC enthält alle technischen Voraussetzungen für einen sicheren Betrieb und revisionssichere Archivierung nach gängigen Compliance-Anforderungen.
Wir haben Dr.DOC in den letzten 42 Jahren konsequent nach hochspezifischen Kundenanforderungen (u.a. aus hochregulierten Branchen und Märkten, wie z.B. Luft-/Raumfahrt, Medizintechnik, Pharma) weiterentwickelt, und diese technisch möglichst allgemein implementiert.
Damit haben Dr.DOC Kunden Zugriff auf Best Practices, die nicht nur regulatorische Compliance-Anforderungen erfüllen, sondern haben zusätzlich einen echten Nutzen und Mehrwert, wie z.B. Sicherheit, Qualität, Kontrolle und Nachvollziehbarkeit.
Ziel und Zweck diese Dokuments ist die Bereitstellung eines nützlichen Leitfadens; durch die allgemeine Dokumentation zur Erreichung optimaler Produktsicherheit, u.a. durch Sicherstellung der Korrektheit (Unversehrtheit) von Daten und der korrekten Funktionsweise vom ECM/DMS System Dr.DOC.
Dieses Dokument dient als Leitfaden und sollte in Verbindung mit den spezifischen Anforderungen des Kunden und den aktuellen Gesetzen und Vorschriften interpretiert werden.
Die finale rechtliche Bewertung und Validierung der Dr.DOC Konfiguration und Systemeinstellungen obliegt dem Betreiber im Rahmen seiner branchenspezifischen Pflichten.
Dieses Dokument hat zusätzlich den Zweck, Dr.DOC Kunden einen geeigneten Rahmen zu geben, bei der Implementierung einer z.B. ISO/IEC 27001, ISO 9001 / DIN EN 9100 / DIN EN 9110, EU 2017/745 MDR, GMP oder EU Vo 748/2012 mit klassischen Aufzeichnungspflichten.
Revisionssicherheit
Revisionssicherheit bezieht sich auf die Aufbewahrung von digitalen Informationen (z.B. Prüfberichte, Rechnungen oder Verträge). Diese muss so erfolgen, dass die rechtlichen Anforderungen in Bezug auf Ordnungsmäßigkeit, Vollständigkeit, Sicherheit, Verfügbarkeit, Nachvollziehbarkeit, Unveränderlichkeit und Zugriffsschutz erfüllt sind.
Beim Thema "Revisionssicherheit" geht um das Sicherstellen (samt Nachweis), dass ein Dokument weder verloren geht noch verändert wird. Das betrifft z.B. den Eingang eines Dokuments in ein Dr.DOC Archiv, bis hin zur endgültigen Langzeitarchivierung/Speicherung.
Eine genaue Definition des Begriffes "Revisionssicherheit" liefert der deutsche Gesetzgeber nicht. Jedoch kann man in Ableitung an das HGB, der AO und den GoBD einige Kriterien und Anforderungen für das Konzept der Revisionssicherheit entnehmen (siehe Kriterien und Anforderungen).
| Kürzel | |
|---|---|
| WF | Workflow |
| KMU | Kleine- und mittlere Unternehmen |
| DMS | Dokumentenmanagement-System |
| API | Programmschnittstelle |
| ISP | Internet Service Provider |
| AO | Abgabenordnung |
| AD | Active Directory |
| GoBD | Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (ehem. GDPdU und GoBS) |
Produkt:
Dr.DOC ist eine Standardsoftware und Komplettlösung für revisionssichere Archivierung, Dokumentenverwaltung (DMS) und Informationsverwaltung. Dr.DOC ist ein B2B-Produkt und kein B2C Produkt.
Für Details, siehe Komponenten unten.
Zielgruppe:
Dr.DOC ist ein DMS/ESM System primär für Organisationen, z.B. Unternehmen und Behörden.
Komponenten:
Die DMS Komplettlösung Dr.DOC besteht aus den folgenden Produkten und Funktions-Komponenten:
interninterninternEine Dr.DOC Archivumgebung besteht aus:
Sicherheitshinweise:
Sicherung: Alle Dr.DOC Verzeichnisse MÜSSEN regelmäßig, vollständig gesichert werden (Datensicherung/Backup); ggf. zusätzlich verschlüsselt, an einen anderen Standort (z.B. wegen Feuer, Krieg).
Vor einer Reorganisation sollte eine Datensicherung erfolgen, da sich der Zustand bestehender Metainfos und ggf. Dokumente ändern kann (z.B. bei geplanter, vollständigen Dok. Löschung aus dem Container).
Dr.DOC-Berechtigungen: Die Option im Benutzer-Manager -> Benutzer -> Tab "Beschreibung" -> Checkbox "Zugangsberechtigung für Benutzer-Manager" MUSS restriktiv verwendet werden (Admin kann und muss u.a. Rechte ändern und ausweiten können). Wir empfehlen, die Option im Benutzer-Manager -> Menü -> Benutzerverwaltung -> Eingeschaften -> "Automatische Anmeldung mit Netzwerk-Anmeldenamen" auf "Nein, kein Benutzer" zu setzen (deaktivieren). Falls "Benutzerspezifisch" ausgewählt wurde, sollte Benutzer-Manager -> Benutzer: Benutzer wählen -> Tab "Beschreibung" -> Checkbox "Automatische Anmeldung mit Netzwerk-Anmeldenamen" deaktiviert werden, sofern kein AD mit Domaincontroller sicher eingerichtet ist und in Dr.DOC korrekt angebunden wurde (in Benutzer-Datei %appdata%\Dr.DOC\ARCHIV.INI bzw. Vorlage-/Dienst: %programdata%\Dr.DOC\ARCHIV.INI: Wert anfügen [PFAFF_ARCHIV] SECURITY_LOGIN=1, Dr.DOC Dienst als Domänen-User ausführen, mit Impersonation Berechtigung für anzumeldende Benutzer).
Berechtigungen im Dr.DOC Benutzermnager sind additiv. Ein Recht, welches von einer Gruppe gegeben wurde, kann also von einer anderen, gleichwertigen Gruppe nicht genommen werden. Datensatzspezifische Datensatzrechte sind höherwertiger als Standard-Datensatzrechte aus der Archivverbindung. Direkte Benutzerspezifische Rechte sind höherwertiger als Gruppenrechte.
-> Tipp: wir empfehlen grundsätzlich:
%B% für eingetragen WF Bearbeiter); Rechte vererben über Gruppenmitgliedschaften nach Abteilung, Rolle, Funktion.Prüfen und testen Sie die einzelnen Rechte (z.B. Datensatzrechte) der Dr.DOC Benutzer/Gruppen, ob die gemachten Konfigurationsänderungen im Benutzermanager Ihren Anforderungen entsprechen. Bitte beachten Sie, dass eine Änderung von Feldinhaltsspezifischen Datensatzrechten am Server, logischerweise auch die gesetzten/verknüpften Berechtigungen ändert, da dadurch die Bedingung geändert wird, wann/ob ein Recht greift. Feldinhaltsspezifische Feldauswahlen sind aus Sicherheitsgründen nur lokal am Server möglich.
Neue Feldauswahlen sollten grundsätzlich nur vom Dr.DOC Benutzer PUBLIC angelegt/geändert werden. Wenn Sie Feldauswahlen als Dr.DOC Benutzer PUBLIC ändern/anlegen, sind diese Feldauswahlen für alle Dr.DOC Benutzer sichtbar und wirksam (als Vorlage). Ein Dr.DOC Benutzer kann eine benutzerspezifische Feldauswahl (z.B. für Suchvorlage, Sortierung, Auswahlliste) angelegen und damit die Vorlage vom Benutzer PUBLIC für sich überladen.
-> Prüfen Sie regelmäßig:
logs-Verzeichnis auf Fehler und Warnungen.KOMM\Arbeit Verzeichnis.Sperrfristen:
Das System erlaubt harte, zeitgesteuerte Sperrfristen (Legal Holds).
Wechselwirkung mit anderen Produkten:
Virenscanner: Virenscanner können während/nach der Installation wichtige Systemdateien entfernen oder zu archivierende Dokumente aus dem Hotfolder entfernen.
Netzwerk Ports: Netzwerkports werden von Dr.DOC exklusiv gebunden. Bitte achten Sie darauf, einen Port nur von einer App/Dienst zu belegen (und wenn doch, siehe Logs nach Fehlermeldungen).
TOTP oder TLS/X509 Zertifikatefehler: Bitte prüfen Sie die Uhrzeit Ihres Endgeräts und des Dr.DOC Servers. Die Uhrzeit MUSS Synchron sein.
Wechselwirkung mit Betriebssystem:
Betriebssystem: Dr.DOC benötigt ein Microsoft Windows Betriebssystem mit x86 Prozessorarchitektur (32 Bit oder 64 Bit), mindestens Windows 7 oder Windows Server 2012.
Dateisystem: Dr.DOC kann nur ordnungsgemäß funktionieren, wenn ausreichend Speicherplatz auf der Festplatte vorhanden ist. Andernfalls können keine Dokumente archiviert werden. Dr.DOC benötigt keine Dateifreigabe auf der Server Maschine, auf der ein Dr.DOC Server läuft. Der Hotfolder Import lässt sich auf einem anderen Gerät realisieren (pull).
Das Dr.DOC System-Verzeichnis (z.B. C:\DrDOC\SYSTEM) darf für Clients NICHT beschreibbar/veränderbar sein; also höchstens Read-Only lesbar sein, wenn ein "geteiltes System-Verzeichnis" gewünscht ist. Alle Dr.DOC Archiv-Verzeichnisse und alle anderen Dr.DOC Verzeichnisse auf dem Server MÜSSEN geschützt werden und dürfen für den Client NICHT zugreifbar sein.
Auch kann Dr.DOC nur so sicher sein, wie das System/Plattform/Betriebssystem/VM, auf der Dr.DOC läuft.
Kommunikation: Alle Dr.DOC Produkte kommunizieren zwischen Client und Server über TCP/IP Sockets. Dr.DOC Produkte kommunizieren untereinander über Mutex, Dateien und Netzwerk Sockets. Alle anderen Netzwerk-Ports und Dienste werden von Dr.DOC nicht direkt benötigt. Bis auf die von Dr.DOC verwendeten, gebundenen TCP/IP Ports kann aus Dr.DOC Sicht ein großteil aller Dienste und Port deaktiviert/geschlossen werden.
Dr.DOC benötigt grundsätzlich keine Windows Server CALs für Dr.DOC Benutzer; Windows CALs sind nur im Terminal-Betrieb notwendig.
Benutzerrechte und Dienste am Server: bitte beachten Sie, dass ein Dr.DOC Dienst nur Dateien von (Netz-)Laufwerken laden/importieren kann, auf die der Benutzer Zugriffsrechte hat (z.B. Dienst auführen als User ..). Der Dr.DOC Netzwerk Server Import (Hot-Folder) unterstützt UNC-Pfade. Bitte prüfen Sie im Fehlerfall zuerst (z.B. kein Import stattgefunden), ob der Import mit lokalen Pfaden ordnungsgemäß funktioniert.
Die für den Dr.DOC Netzwerk Server und Dr.DOC Web verwendete Dr.DOC Konfigurationsdatei ARCHIV.INI hängt am ausführenden Benutzer des Prozesses. Das ist bei Windows Diensten und Terminal-Servern i.d.R. %programdata%\Dr.DOC\ARCHIV.INI und bei normalen Windows Benutzern %appdata%\Dr.DOC\ARCHIV.INI. Kritische Einstellungen sollten in beide ARCHIV.INIs eingetragen werden.
Lizenz und Version:
Ihre Produktversion und Lizenz erkennen Sie unter:
Mehr:
Siehe Benutzerhandbuch in Ihrer Dr.DOC System Installation (Handbuch\D).
Konformitätserklärung:
Hiermit erklären wir als Hersteller, dass das Produkt "Dr.DOC Netzwerk Client/Server" (z.B. Dr.DOC N50 Lizenz) und "Dr.DOC Web" der GPSR (EU) 2023/988 entspricht.
München, 27.03.2026.
Dr.DOC System Version 29.0.1.216
Dr.DOC Web Build Version 166
Änderungen: https://drdoc.com/node/de/products/web/changelog
Dr.DOC ist kein Medizinprodukt im Sinne der MDR (EU) 2017/745, sondern eine Software u.a. zur Unterstützung des Qualitätsmanagementsystems (QMS) von Medizinprodukteherstellern (siehe MDCG 2019-11).
Als Software zur Unterstützung des QMS von Medizinprodukteherstellern stellt Dr.DOC die technischen Voraussetzungen bereit, um eine Validierung nach DIN EN ISO 13485:2016 (Kapitel 4.1.6) durchzuführen.
Dr.DOC erfüllt grundsätzlich (Konfiguration!) die Anforderungen an computergestützte Systeme gemäß EU GMP Leitfaden Annex 11 sowie FDA 21 CFR Part 11 (Audit Trail, Electronic Records). "accessibility, readability and integrity" sind unser Kerngeschäft.
Incident Response Management (Meldeweg für Sicherheitsvorfälle):
E-Mail an: info[at]drdoc.com
Meldungen werden binnen 24 Stunden in unserem System erfasst und nach einer definierten Triage-Matrix bewertet. Schwerwiegende Vorfälle werden gemäß den gesetzlichen Anforderungen und Fristen z.B. an das Safety Gate Portal der EU gemeldet.
Hersteller:
Dr.DOC GmbH
Geschäftsführung / Tobias Pfaff
Hesseloherstr. 9
D-80802 München
Email: info[at]drdoc.com
Migrationen und Langzeitverfügbarkeit:
Durch die konsistente, saubere Architektur von Dr.DOC (nach innen) und Interoperabilität durch Schnittstellen (nach außen), ist Dr.DOC über Jahrzehnte hinweg betreibbar (z.B. "Life of Aircraft"-Anforderung). Für alle Dr.DOC Versionen bis ins Jahr 1997 bestehen automatisierte, strukturierte Migrationspfade, die fest in der Software integriert sind (technisch: durch Archiv Reorganisation). Durch die starke Abwärtskompatibilität ist Dr.DOC ideal für extreme Langzeitverfügbarkeit. Dr.DOC ist ein Langzeitarchiv by-design durch zahlreiche Architekturentscheidungen und unsere bewährte Technologie in der Informationsorganisation (Metadaten, NCI/CI Dokumente Container etc.).
Versionsverwaltung und Nachvollziehbarkeit (Traceability)
Dr.DOC bietet eine konfigurierbare Versionsverwaltung, die sowohl den operativen Anforderungen als auch den strengen Compliance-Vorgaben verschiedener Branchen gerecht wird.
Die in Dr.DOC integrierte Versionsverwaltung und das Statusmodell (Entwurf/Release) unterstützen Entwicklungs- und Herstellungsbetriebe bei der Erfüllung der Aufzeichnungspflichten, z.B. gemäß EASA Part 21.A.55 (Record Keeping).
Diese Funktion gewährleistet eine revisionssichere Dokumentation und unterstützt die Einhaltung von Anforderungen an Traceability (Nachvollziehbarkeit, Rückverfolgbarkeit).
Z.B. relevant beim Configuration Management (CM).
Funktionsweise und Konfiguration:
Audit Trail/Journal Archiv/Änderungsverwaltung:
Die Dr.DOC Änderungsverwaltung und das Protokoll ist ein eigenes, separates Archiv, welches alle Aktivitäten eventgesteuert, revisionssicher archiviert. Ein Trigger feuert z.B. bei Änderungen eines Datensatzes oder Feldwerts, einer Suche eines Benutzers etc. und führt die Protokollierung aus.
Es handelt sich damit (je nach Konfiguration) um eine chronologische, manipulationssichere Aufzeichnung, die alle relevanten Aktivitäten, Änderungen und Zugriffe auf Daten enthält ("Non-Repudiation").
Verantwortlichkeiten: Shared Responsibility Model
Dr.DOC liefert die technische Basis (Standardsoftware / Technical Controls), der Kunde verantwortet die prozessualen und organisatorischen Rahmenbedingungen (Procedural Controls).
Durch die Architektur von Dr.DOC (z.B. lokale KI-Modelle, Audit-Trails, Versionsverwaltung, Verschlüsselung etc.) unterstützen wir z.B. den MedTech-Hersteller dabei, die grundlegenden Sicherheits- und Leistungsanforderungen (GSPR) der MDR hinsichtlich IT-Sicherheit zu erfüllen.
Dr.DOC ist nach GAMP 5 grundsätzlich als "Konfigurierte Standardsoftware" (Kategorie 4) einzuordnen. Einige Module/Komponenten können als "Nicht-konfigurierte Standardsoftware" (Kategorie 3) eingeordnet werden ("wie besehen"-, "as it is"-Kriterium).
Der Kunde muss die User Requirement Specification (URS) schreiben, wogegen Dr.DOC als Hersteller (bzw. das zuständige Systemhaus) bei der Functional Specification (FS) und den IQ/OQ/PQ-Tests (Installation/Operational/Performance Qualification) unterstützt (z.B. mit Standard-Skripten).
Die Qualifizierung der IT-Infrastruktur (Server, OS, Netzwerk) liegt nach ITIL/GAMP-Best-Practice in der Verantwortung des Betreibers.
Support sowie die Bereitstellung von Templates erfolgt i.d.R. über Systemäuser (authorisierte Dr.DOC Partner).
Computersystemvalidierung (CSV) / Tool Qualification / Verfahrensdokumentation:
Auf Anfrage bieten wir Ihnen eine Validierungsunterstützung an (Verfahrensdokumentation, standardisierte Validierungsdokumentation, Handbücher, etc.).
Für die Luftfahrt unterstützt Dr.DOC die Qualifizierung nach RTCA DO-330 / EUROCAE ED-215. Wir liefern gerne Basisdaten für den Tool Qualification Plan (TQP) und die Tool Operational Requirements (TOR), typischerweise für die Evaluierung nach Tool Criteria 3 (TC3, Software Validierung ohne Code Änderung).
Tool Service History: Wir haben 42 Jahren Erfahrung. Alle kritischen Komponenten sind mindestens 30 Jahre am Markt und werden laufend modernisiert und validiert.
Intern: Siehe Dr.DOC Versionsverwaltung Sperr- / Freigabehistorie.
Beipiel:
| Datum | Änderung | Autor |
|---|---|---|
| ... |
Bitte entsprechend anpassen!
| Asset-Type | Kategorie / Asset Name | Asset Owner: Abteilung |
Asset Owner: Rechte |
Schutzbedarf | Sicherheit / Klassifizierung |
Ort / Lage |
Medium / Form |
|---|---|---|---|---|---|---|---|
| Mensch / Persoal | Rolle(n): Rechte und Pflichten Fähigkeiten
|
HR | hoch | vertraulich | .. | .. | |
| Dokumentation und Organisatorische Abläufe | Orgahandbuch | VE | read, write | .. | intern | Papier | |
| Hardware und HMI | TSP / ISP: Telekom | IT | |||||
Router
|
IT | ||||||
Switch
|
IT | ||||||
| E-Mail-Server | IT | ||||||
Server
|
IT | Schrank 2 | |||||
| OS, Betriebssystem | MS Server 2025 | IT | intern | VM1 / Hostname server1 |
|||
| Apps, Software, Services und Systeme | Software Dr.DOC Usermanager Beispiel Archive mit Feldern, Eigenschaften, FAs DS mit Feldwerten und Dokument |
IT | hoch | intern |
|
digital / VM Image | |
| Dr.DOC Archiv Personalakten/Arbeitsverträge | HR | Datensatz: read, write Dokument: read, append |
hoch | vertraulich | digital / Archiv | ||
| Dr.DOC Archiv für Eingangsrechnungen + LS |
Einkauf | Datensatz: read, write Dokument: read, append |
hoch | intern | digital / Archiv |
Ein Ablauf definiert z.B. Zustandsänderungen von Assets.
| Bezeichnung | Initiierendes Asset | Betroffene Assets | Zustandsänderung |
|---|---|---|---|
| Posteingang: Vorqualifizierung | Posteingang User |
|
Erzeugen mehrerer Stapel, Trennung nach Kontext, Verschieben in E-Mail Verzeichnisse
|
| Erfassung als digitalen Repräsentation (z.B. Scan) | Posteingang User |
|
|
| Automatische Verschlagwortung je nach Archiv / Feldvorbelegung / Import-Def. | Dr.DOC |
|
Feldwerte erkennen und ändern mittels:
|
| Ablage des Originals | Posteingang User |
|
|
| Verschlagwortung / WF Bearbieter setzen | Posteingang User |
|
Setzen bzw. Überprüfen der von vorausgefüllten Feldwerten:
|
| WF Schritte: z.B. Freigabe Sachbearbeiter/Besteller, Freigabe Buchung, Freigabe Zahlung | Freigabe User |
|
|
| Sperrung | Sperr/AL User |
|
Im Dr.DOC Datensatz das Dokument sperren, z.B. wenn alle WF erledigt wurden oder über ein Checkbox Bool Feld, mit Datensatzspezifischer Berechtigung |
| Recherche | Mandanten User |
|
Keine Änderung |
Löschung:
|
Lösch User |
|
Sofern Sie KI Funktionen nutzen, muss ggf. der AI-Act der EU erfüllt werden. Dafür sollte in einem ersten Schritt das Risikopotenzial durch KI Verwendung ermittelt werden. i.d.R. haben Dr.DOC Anwendungen/Implementierungen ein "Minimales Risiko" bis "Begrenztes Risiko" ohne "systemisches Risiko" nach EU AI Act.
Dabei gilt: je höher das Risiko, desto strenger die Anforderungen.
Dr.DOC Web integriert z.B. die OpenAI API und Ollama API. Damit kann Ihre KI lokal (On Prem) als auch in der Cloud laufen.
Bei der Nutzung lokaler Modelle (Ollama) verbleiben alle Daten in Ihrem Haus (On-Premises), wodurch das Risiko von Datenabflüssen von sensiblen Unternehmens- oder Patientendaten (MDR/GxP) vollständig eliminiert wird.
Achtung: Sollte Ihr KI Modell in der Cloud laufen, verlassen Ihre Daten Ihr Haus! Prüfen Sie zwingend Ihre regulatorishen Ramenbedingungen und Risiken. Sorgen Sie mindestens für explizite Auftragsverarbeitungsverträge (AVV) und prüfen Sie, ob Opt-outs für das Modell-Training vorliegen.
Bitte beachten Sie: Unbefugtes Löschen trotz Frist führt zu Compliance-Verstößen. Lösch- und Sperrfristen können über DS-spezifische Rechte spezifiziert werden.
beachten Sie, falls Sie Dr.DOC für therapeutische oder diagnostische Entscheidungen nutzen sollten, dass sich das Risiko "Falsche Antwort durch KI" damit fundamental ändern würde. Jegliche Nutzung von Dr.DOC oder der integrierten KI zur direkten diagnostischen oder therapeutischen Entscheidungsfindung (Clinical Decision Support) ist vom Intended Use nicht erfasst und würde das System potenziell als Medical Device Software (MDSW) qualifizieren. Bitte kontaktieren Sie uns gerne; wir sirgen für absolute Klarheit und Planbarkeit.
Bitte entsprechend anpassen!
| Schweregrad (Severity) z.B. Schadensausmaß in EUR |
Bewertung |
|---|---|
| < 10 Tsd. | sehr sehr gering |
| >= 10 Tsd. | sehr gering |
| >= 10 Mio. | gering |
| >= 25 Mio. | mittel |
| > 50 Mio. | hoch |
| Eintrittswahrscheinlichkeit in % | Bewertung |
|---|---|
| < 5 % | sehr unwahrscheinlich |
| 5% - < 25% | unwahrscheinlich |
| 25% - < 50% | möglich |
| 50% - 75% | wahrscheinlich |
| > 75% | sehr wahrscheinlich |
Definition: Auswirkungen auf die Vermögens-, Finanz- und Ertragslage von [...].
Berechnung des eff. Schadensbetrags:
z.B. als "Eintrittswahrscheinlichkeit × Schadensausmaß × Detectability" (z.B. GAMP/GxP)
oder vereinfacht in der FMEA als:
"Schweregrad (Severity) x Auftrittswahrscheinlichkeit (Probability) x Entdeckbarkeit (Detectability) = Risikoprioritätszahl (RPN)"
Je nach Branche und regulatorischem Umfeld, zwingend die Spalte "Entdeckbarkeit" (Detectability) füllen und pflegen (GAMP/GxP-Risikoanalyse).
| Ereignis | Schadensausmaß/ Schadenspotential |
Eintrittswahrscheinlichkeit | Schadensbetrag | Detectability | Aktionen / Vermeidungsmaßnahme | Inhärente, technische Schutzmaßnahmen | Risiko nach Mitigierung |
|---|---|---|---|---|---|---|---|
| Datei/Festplatte Schreibfehler | kein bis vollständiger Datenverlust | sehr unwahrscheinlich | sehr gering | hoch |
|
|
sehr sehr gering |
| Festplatte voll | Störung des ordnungsgemäßen Betriebs / keine Änderungen möglich / Beendigung des Dienstes | möglich | mittel | hoch |
|
|
sehr sehr gering |
| Verlust der Lesbarkeit über lange Zeiträume (> 15 Jahre) | kein bis vollständiger Datenverlust | möglich | hoch | mittel |
|
|
sehr sehr gering |
| Verlust der Datenintegrität durch unautorisierte Datenbankeingriffe | hoch | möglich | hoch | hoch |
|
|
|
| Unbefugtes, Direktes Bearbeiten von Dateien am Server | Störung des ordnungsgemäßen Betriebs, Datenzerstörung oder Manipulation | unwahrscheinlich | sehr hoch | mittel |
|
|
sehr sehr gering |
| MITM / Abhören der Kommunikation | Anmeldung als Benutzer(je nach Nutzerrecht), Rechteausweitung | möglich | hoch | hoch |
|
|
sehr sehr gering |
| Passwort Bruteforce Angriff | Anmeldung als Benutzer, Datensätze zum Löschen markieren, Metadaten bearbeiten etc. (je nach Nutzerrecht), Rechteausweitung | möglich | hoch | mittel |
|
|
sehr sehr gering |
| Rechteausweitung | Anmeldung als Benutzer (je nach Nutzerrecht) | möglich | hoch | mittel |
|
|
sehr sehr gering |
| Schadhafte/Virus Datei wird archiviert | Word *.doc mit schadhaftem Makro | wahrscheinlich | hoch | niedrig |
|
|
sehr sehr gering |
| DDOS Angriff | Kein Netzwerkzugriff für Nutzer möglich | möglich | mittel |
|
sehr sehr gering | ||
| Krieg, Feuer, Wasserschaden | Störung des ordnungsgemäßen Betriebs, Datenzerstörung | möglich | hoch |
|
|
sehr sehr gering | |
| Löschen vor Ablauf der Aufbewahrungsfrist | möglich | hoch |
|
|
sehr sehr gering | ||
| Fehler bei Einhaltung der Aufbewahrungsfristen | möglich | mittel |
|
|
sehr sehr gering | ||
| Veröffentlichung innerhalb der Sperrfrist | möglich | hoch | Das System erlaubt harte, zeitgesteuerte Sperrfristen (Legal Holds), durch harte, Datensatzspezifische Rechte. | Datensatzspezifische Rechte | sehr sehr gering | ||
| Dokument oder Metainfo wird geändert | möglich | mittel |
|
|
sehr sehr gering | ||
| Rechnung wird falsch gebucht flasche Vorbelegung durch KI |
möglich | hoch |
|
|
sehr sehr gering | ||
| Falsche Antwort/Information im Chat durch KI | wahrscheinlich | hoch |
|
|
gering | ||
| Dokument wurde nicht archiviert | möglich | mittel |
|
|
sehr sehr gering | ||
| Dokument wurde mehrfach archiviert | möglich | mittel |
|
|
sehr sehr gering | ||
| Dokument/Metanfo wird nicht/falsch/unvollständig gespeichert | sehr unwahrscheinlich | hoch |
|
sehr sehr gering | |||
| Ein Benutzer hat einen Datensatz bearbeitet/gesehen/gesucht/geändert | sehr wahrscheinlich | gering |
|
|
sehr sehr gering | ||
| Ein Benutzer hat einen Datensatz unbefugt bearbeitet/gesehen/gesucht/geändert wg. Fehlkonfiguration | unwahrscheinlich | hoch |
|
|
sehr gering |