RiLi-Webservices

Mustervorlage: "Richtlinie zum Betrieb von Webservices"

Einleitung

Diese Richtlinie bietet einen umfassenden Rahmen für den sicheren und rechtlich konformen Betrieb von Webservices unter Berücksichtigung aktueller Standards. Sie deckt den gesamten Lebenszyklus ab und stellt sicher, dass alle relevanten technischen, organisatorischen und rechtlichen Anforderungen erfüllt werden. Regelmäßige Überprüfungen und Anpassungen der Richtlinie sind notwendig, um auf neue Bedrohungen und veränderte Anforderungen reagieren zu können.

Zweck und Ziel

Ziel dieser Richtlinie ist die Festlegung verbindlicher Regelungen für die sichere, rechtskonforme und wirtschaftliche Planung, Implementierung, den Betrieb sowie die Außerbetriebnahme von Webservices und Webservern in der Organisation. Die Richtlinie dient der:

• Risikominimierung durch systematische Sicherheits- und Datenschutzmaßnahmen,
• Einhaltung gesetzlicher und regulatorischer Anforderungen (z. B. DSGVO, TMG, TDDDG, UrhG),
• Unterstützung beim Nachweis der Umsetzung von Anforderungen gemäß ISO/IEC 27001 bzw. BSI IT-Grundschutz.

Geltungsbereich

Die Richtlinie gilt für:

• alle Webservices und Webserver, die durch die Organisation selbst betrieben oder in deren Auftrag durch Dritte bereitgestellt werden,
• alle Betriebsmodelle (on-premises, cloudbasiert, hybrid),
• alle Phasen des Systemlebenszyklus: Planung, Entwicklung, Implementierung, Betrieb, Wartung, Außerbetriebnahme,
• alle beteiligten Organisationseinheiten, internen sowie externen Dienstleistenden, die mit dem Betrieb, der Entwicklung oder Pflege betraut sind.

Nicht im Geltungsbereich sind rein interne Software-Komponenten ohne Netzwerkexposition, sofern sie keine Webschnittstellen anbieten.

Definitionen und Begriffsklärungen

• Webserver: Software oder Appliance, die HTTP/HTTPS-Anfragen entgegennimmt, verarbeitet und entsprechende Inhalte oder Dienste bereitstellt (z. B. Apache, nginx, IIS).
• Webservice: Dienst, der über standardisierte Webprotokolle (z. B. REST, SOAP, GraphQL) ansprechbar ist und maschinelle Kommunikation ermöglicht. Webservices sind typischerweise Bestandteil von serviceorientierten Architekturen (SOA) oder Microservice-Umgebungen.
• Service-Verantwortliche: Person oder Rolle mit der fachlichen und/oder technischen Gesamtverantwortung für einen konkreten Webservice (vergleichbar mit „Asset Owner“ gemäß ISO 27001).
• DMZ (Demilitarized Zone): Netzwerksegment mit restriktiven Firewall-Regeln zur sicheren Exposition öffentlich erreichbarer Dienste, z. B. Webserver mit Internetzugang.
• API-Gateway: Sicherheits- und Management-Komponente zur zentralisierten Steuerung von Zugriffen auf Webservices.

Verantwortlichkeiten und Rollenkonzept

Ein effektives Sicherheitskonzept setzt eine klare Rollenzuordnung voraus. Die Rollen und Zuständigkeiten sollten dokumentiert, kommuniziert und in geeigneter Weise überprüft werden. Zentrale Rollen sind:

Management/Leitungsebene:

• Freigabe der Richtlinie
• Bereitstellung personeller und finanzieller Ressourcen
• Überwachung der Umsetzung im Rahmen des ISMS

Informationssicherheitsbeauftragte (ISB):

• Überwachung der Richtlinieneinhaltung
• Beratung bei Sicherheits- und Datenschutzfragen
• Durchführung von Sicherheitsüberprüfungen und Audits

Systemverantwortliche / Applikationsverantwortliche:

• Technische und organisatorische Verantwortung für einzelne Webservices
• Umsetzung der technischen und betrieblichen Anforderungen
• Incident Response und Dokumentation

Datenschutzbeauftragte (DSB):

• Prüfung datenschutzrelevanter Verarbeitung
• Unterstützung bei Datenschutz-Folgenabschätzungen
• Kontrolle der Einhaltung datenschutzrechtlicher Anforderungen

IT-Betrieb / Administratoren:

• Betrieb und technische Wartung der Server
• Umsetzung der Härtung, Patching, Protokollierung, Zugriffskontrolle
• Zusammenarbeit mit ISB und Systemverantwortlichen

Entwicklung / DevOps / Provider:

• entwickeln den Webservice gemäß interner Entwicklungsrichtlinien und sicherer Programmierstandards,
• führen Test- und Qualitätssicherungsmaßnahmen durch,
• verantworten Deployment und ggf. automatisierte CI/CD-Prozesse.

Externe Dienstleistende:

• Müssen durch Verträge (AVV, SLA) zur Einhaltung dieser Richtlinie verpflichtet werden
• Verantwortlichkeiten sind klar zu regeln (Auftragsverarbeitung vs. gemeinsame Verantwortung)

Dokumentationsanforderungen

Dokumentation ist ein zentraler Bestandteil eines nachvollziehbaren, sicheren und regelkonformen Betriebs.

Allgemeine Anforderungen

• Vollständigkeit: Alle sicherheitsrelevanten Vorgänge, Systeme und Konfigurationen sind zu dokumentieren.
• Nachvollziehbarkeit: Änderungen müssen versioniert, Änderungen nachvollziehbar dokumentiert sein.
• Aktualität: Dokumente müssen regelmäßig geprüft und bei Bedarf aktualisiert werden.
• Verfügbarkeit: Dokumentationen müssen für berechtigte Personen auffindbar, zugänglich und verständlich sein.

Mindestinhalte der technischen Dokumentation:

• Systembeschreibung (inkl. Schnittstellen, verwendete Frameworks, eingesetzte Softwareversionen)
• Schutzbedarfsfeststellung und Risikoanalyse
• Zugriffsberechtigungskonzept (inkl. Rollenvergabe)
• Sicherheitsmaßnahmen (Firewall-Regeln, TLS-Konfiguration, Logging)
• Wartungs- und Patchkonzept
• Backup- und Wiederherstellungskonzept
• Incident-Response-Prozesse
• Prüfprotokolle (z. B. Penetrationstest, Schwachstellenscans)

Datenschutzrelevante Dokumentation:

• Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO)
• Technisch-organisatorische Maßnahmen (TOMs nach Art. 32 DSGVO)
• ggf. Datenschutzfolgenabschätzung (Art. 35 DSGVO)
• Vertragsunterlagen zur Auftragsverarbeitung (Art. 28 DSGVO)

Rechtliche Anforderungen

Webservices unterliegen vielfältigen rechtlichen Anforderungen. Die Richtlinie muss sicherstellen, dass Betrieb und Nutzung der Webservices mit geltendem Recht vereinbar sind. Die Einhaltung muss nachweisbar dokumentiert werden.

Allgemeine rechtliche Vorgaben

• Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG): Ersetzt das frühere TMG im Kontext von Telemediendiensten. Relevanz z. B. bei Tracking, Cookies, Analyse-Tools.
• Urheberrechtsgesetz (UrhG): Sicherstellung der Lizenzkonformität bei eingesetzter Software (Open Source, Drittmodule).
• Vertragliche Regelungen: SLAs, NDAs und AV-Verträge müssen rechtskonform ausgestaltet sein.

Datenschutzrechtliche Vorgaben

• DSGVO (insb. Art. 5, 6, 28, 32, 35):
  • Verarbeitung personenbezogener Daten nur auf rechtmäßiger Grundlage.
  • Nachweis der Umsetzung geeigneter technischer und organisatorischer Maßnahmen (TOMs).
  • Sicherstellung der Betroffenenrechte (Art. 12–23).
• Datenschutz-Folgenabschätzung (DSFA):
  • Erforderlich bei hohem Risiko für Rechte und Freiheiten Betroffener (z. B. bei Tracking, Profilbildung, biometrischer Datenverarbeitung).
  • Muss vor Inbetriebnahme durchgeführt und dokumentiert werden.
• Auftragsverarbeitung (Art. 28 DSGVO):
  • Nutzung externer Dienstleistender nur mit AV-Vertrag und Nachweis der Eignung (Audit, Zertifikat, Fragebogen).

Informationspflichten und Transparenz

• Impressumspflicht: Nach § 5 TMG i. V. m. § 18 MStV.
• Datenschutzerklärung: Verständlich, vollständig, aktuell; Anpassung bei Änderungen der Datenverarbeitung.
• Einwilligungsmanagement (z. B. Cookie-Banner):
  • Erforderlich bei nicht-funktionalen Cookies oder Drittanbieter-Tools.
  • Consent-Management-Systeme müssen technisch DSGVO-konform eingebunden sein.

Rechte an Inhalten und Software

• Lizenzen: Einsatz von Open-Source-Komponenten nur mit rechtlich zulässiger Lizenz (z. B. GPL, MIT, Apache).
• Nutzung fremder Inhalte (Bilder, Texte, Scripte) nur mit ausreichendem Nutzungsrecht.
• Dokumentation der Lizenzkonformität ist verpflichtend (z. B. Software-Bill-of-Materials, Lizenzübersicht).

Technische Anforderungen und Standards

Die Absicherung von Webservices erfordert die Einhaltung technischer Mindeststandards sowie die Umsetzung weitergehender Schutzmaßnahmen bei entsprechendem Schutzbedarf. Maßgeblich sind anerkannte Standards, Empfehlungen des BSI sowie internationale Best Practices. Die Anforderungen orientieren sich dabei am Schutzbedarf der verarbeiteten Informationen.

Relevante Standards, Richtlinien und Empfehlungen

Für die Planung, Entwicklung, den Betrieb und die Absicherung von Webservices stehen etablierte Normen, Rahmenwerke und Spezifikationen zur Verfügung, die als Grundlage für ein systematisches und überprüfbares Sicherheitsniveau dienen. Für die Organisation gelten folgende Regelwerke:

Je nach Branche, Schutzbedarf und regulatorischen Anforderungen kommen dabei unterschiedliche Schwerpunkte zum Tragen. Die Auflistung muss also je nach Organisation erweitert oder reduziert werden.

ISO/IEC 27001 / 27002

Die international anerkannte Normenreihe liefert einen risikobasierten Rahmen für die Informationssicherheit und umfasst im Anhang A (bzw. ISO/IEC 27002) zahlreiche Maßnahmen, die unmittelbar auf Webservices anwendbar sind. Relevante Inhalte betreffen u. a. Zugriffskontrollen, Schwachstellenmanagement, Entwicklungsprozesse und Lieferketten.

BSI IT-Grundschutz-Kompendium

Das Kompendium stellt ein umfassendes Maßnahmensystem für unterschiedliche IT-Komponenten bereit. Die Bausteine WEB.2 (Webserver und -anwendungen), OPS.1.1.1 (Allgemeiner IT-Betrieb) und CON.5 (Absicherung von Webanwendungen) enthalten konkrete Anforderungen zur Härtung, Authentifizierung, Protokollierung und Angriffserkennung.

OWASP Application Security Verification Standard (ASVS)

Der ASVS definiert ein gestuftes Prüfmodell zur Verifikation der Sicherheit von Webanwendungen – von grundlegenden Anforderungen (Level 1) bis zu hochkritischen Anwendungen (Level 3). Er dient als praxisnahe Ergänzung zu generischen Normen und ist insbesondere bei internen Sicherheitsreviews oder Ausschreibungen hilfreich.

OWASP Top 10

Die jährlich aktualisierte Liste der OWASP Top 10 identifiziert die häufigsten und kritischsten Schwachstellen in Webanwendungen. Sie dient als Awareness- und Kontrollliste für Entwicklung, Testing und Reviews und sollte in Sicherheitskonzepte und Entwicklungsrichtlinien integriert werden.

CIS Benchmarks (Center for Internet Security)

Für Webserver wie Apache, nginx oder Microsoft IIS existieren konkrete Konfigurationsrichtlinien zur Härtung. Diese Benchmarks enthalten prüfbare Empfehlungen, die eine standardisierte und sichere Baseline ermöglichen und sind insbesondere für automatisierte Audits geeignet.

TLS Best Practices (z. B. Mozilla Server Side TLS, BSI TR-02102-2)

Diese Richtlinien definieren aktuelle empfohlene Cipher-Suiten, TLS-Versionen und Konfigurationseinstellungen. Sie helfen, kryptografische Sicherheitslücken zu vermeiden und eine zukunftssichere Kommunikation zu gewährleisten.

RFCs zu Sicherheitsmechanismen (z. B. HSTS, CSP, OAuth 2.0, OpenID Connect)

Webservices, die Authentifizierungsdienste oder Sicherheitsmechanismen umsetzen, sollten sich eng an die jeweiligen RFCs und IETF-Standards halten, insbesondere bei der Implementierung von Content Security Policies, Authentifizierungsprotokollen oder Session Management.

Mindestanforderungen für alle Webanwendungen und Webserver

Unabhängig vom konkreten Schutzbedarf sind folgende Maßnahmen für alle Webservices der Organisation verpflichtend umzusetzen:

Inventarisierung und Verantwortlichkeiten

Alle eingesetzten Webserver und Webservices müssen in einem aktuellen Systeminventar geführt werden. Für jeden Dienst ist eine verantwortliche Stelle (Betriebsverantwortung) benannt. Die Betriebsführung erfolgt dokumentiert und nachvollziehbar.

Transportverschlüsselung und sichere Kommunikation

Verbindungen zu Webservices müssen durchgängig verschlüsselt erfolgen. TLS ab Version 1.2 ist Mindeststandard, TLS 1.3 wird empfohlen. Zertifikate müssen von vertrauenswürdigen Stellen stammen, z. B. über automatisierte ACME-Verfahren (Let’s Encrypt). Die Konfiguration ist regelmäßig mit Tools wie testssl.sh oder Qualys SSL Labs zu prüfen.

Zugriffskontrolle und Authentifizierung

Der Zugriff auf Verwaltungsoberflächen oder geschützte Bereiche erfolgt ausschließlich über individuell zuordenbare Konten. Shared Accounts sind untersagt. Authentifizierungen sind über sichere Verfahren umzusetzen, mindestens mit starkem Passwortschutz, idealerweise mit Mehrfaktor-Authentifizierung.

Härtung der Webserver und Dienste

Alle Webserver müssen gehärtet betrieben werden. Dazu gehört die Deaktivierung nicht benötigter Module und Dienste, die Absicherung von Admin-Oberflächen (z.B. per VPN oder IP-Filterung) sowie das Verhindern von Directory Listing und HTTP TRACE. Konfigurationen orientieren sich an anerkannten Benchmarks (z.B. CIS Benchmarks).

Sicherer Umgang mit Sitzungen und Cookies

Sessions sind mit Sicherheitsmerkmalen wie Secure, HttpOnly und SameSite abzusichern. Inaktive Sitzungen müssen automatisch beendet werden (Session Timeout). Sitzungs-IDs sind kryptografisch sicher zu generieren.

Eingabevalidierung und Ausgabekodierung

Zur Vermeidung von Injection-Angriffen sind alle Benutzereingaben zu validieren (Whitelist-Prinzip) und Ausgaben kontextgerecht zu kodieren (z. B. HTML-Encoding).

Protokollierung und Überwachung

Sicherheitsrelevante Ereignisse (z. B. Authentifizierungsversuche, Systemänderungen) müssen mit Zeitstempel, Quell-IP und Benutzerbezug protokolliert werden. Die Logdaten sind vor unbefugtem Zugriff und Manipulation zu schützen. Eine zentrale Auswertung ist vorgesehen.

Schutz gegen häufige Angriffsvektoren

Grundlegende Schutzmaßnahmen sind umzusetzen gegen:

• Brute-Force-Angriffe (Rate Limiting, Lockouts),
• Injection-Angriffe (Prepared Statements, Input-Whitelisting),
• Cross-Site-Angriffe (Content-Security-Policy, CSRF-Tokens, X-Frame-Options),
• Man-in-the-Middle (TLS, HSTS),
• einfache DDoS-Angriffe (Rate-Limiting, Geo/IP-Filter).

Zusätzliche Anforderungen bei höherem Schutzbedarf

Bei Webservices, die personenbezogene Daten, vertrauliche Informationen oder besonders schützenswerte Inhalte verarbeiten, gelten erweiterte Anforderungen:

Risikobewertung und Schutzbedarfsfeststellung

Vor Inbetriebnahme ist eine strukturierte Risikoanalyse durchzuführen. Die Ergebnisse bilden die Grundlage für weitergehende technische und organisatorische Schutzmaßnahmen.

Sichere Softwareentwicklung (Secure SDLC)

Die Entwicklung muss nach definierten Sicherheitsrichtlinien erfolgen, einschließlich Bedrohungsmodellierung (Threat Modeling), sicherem Coding, Code-Reviews und Testverfahren mit Fokus auf Sicherheit. Frameworks zur Erkennung und Vermeidung der OWASP Top 10 sind verpflichtend.

Verstärkte Authentifizierung und Zugriffsschutz

Bei sensiblen Webdiensten ist zwingend eine starke Authentifizierung vorzusehen, idealerweise mit MFA. Rollen- und attributbasierte Zugriffskontrollen (RBAC/ABAC) sind zu implementieren, die Rechtevergabe ist restriktiv und nachvollziehbar zu dokumentieren.

Technische Schwachstellenbehandlung

Es ist ein strukturierter Prozess zur Behandlung technischer Schwachstellen vorzuhalten. Dazu gehören regelmäßige Schwachstellenscans, automatisiertes Patching und eine Überwachung einschlägiger Advisories (z. B. CVE, BSI, CERT-Bund). Kritische Lücken sind mit hoher Priorität zu schließen.

Erkennung und Reaktion auf Angriffe

Ein zentrales Monitoring zur Erkennung von Angriffsmustern ist erforderlich. Dazu gehören IDS/IPS, WAFs oder korrelierte Loganalysen. Sicherheitsereignisse müssen eindeutig klassifiziert, dokumentiert und bewertet werden können.

Supply-Chain-Sicherheit

Verwendete Softwarebibliotheken und Drittanbieterkomponenten sind auf ihre Vertrauenswürdigkeit zu prüfen. Abhängigkeiten sind nachvollziehbar zu dokumentieren, z. B. in Form eines SBOM (Software Bill of Materials). Sicherheitsupdates externer Komponenten sind zeitnah umzusetzen.

Langzeitarchivierung und Datenschutzanforderungen

Soweit personenbezogene oder besonders schützenswerte Daten verarbeitet werden, müssen zusätzlich datenschutzrechtliche Vorgaben (z. B. aus DSGVO, BDSG) erfüllt und die Langzeitarchivierung entsprechend abgesichert sein (z. B. durch Verschlüsselung, Zugriffsschutz, nachvollziehbare Löschkonzepte).

Planung und Konzeption

Die Phase der Planung und Konzeption bildet das Fundament eines sicheren und stabilen Webservice-Betriebs. In ihr werden nicht nur funktionale Anforderungen spezifiziert, sondern auch Sicherheits- und Compliance-Vorgaben verbindlich definiert und in das Gesamtkonzept integriert. Ohne eine strukturierte und methodische Vorgehensweise in dieser frühen Phase drohen nicht nur technische Mängel, sondern auch Verstöße gegen regulatorische Anforderungen und eine unzureichende Risikovorsorge.

Anforderungsanalyse

Die systematische Erhebung der funktionalen Anforderungen ist essenziell, um die Zielsetzung des Webservices eindeutig zu bestimmen und eine spätere Fehlentwicklung zu vermeiden. Dazu gehört auch die Ermittlung von Qualitätsmerkmalen wie Verfügbarkeit, Performanz und Skalierbarkeit. Parallel müssen die Sicherheitsanforderungen aus der Informationssicherheit, dem Datenschutz sowie branchenspezifischen Vorgaben (z. B. KRITIS, NIS2) identifiziert und dokumentiert werden. Dies umfasst unter anderem Authentifizierungsmechanismen, Protokollierungsanforderungen und Schutzbedarfe gemäß den Vorgaben eines etablierten ISMS.

Ergänzend erfolgt eine Ressourcen- und Bedarfsanalyse, in der technische und personelle Kapazitäten, externe Abhängigkeiten und Lizenzkosten eingeplant werden. Dies stellt sicher, dass sowohl die Entwicklung als auch der Betrieb des Webservices realistisch und nachhaltig erfolgen kann.

Architektur und Design

Basierend auf den Anforderungen wird die Zielarchitektur festgelegt. Dabei ist insbesondere zwischen monolithischen und serviceorientierten Ansätzen zu unterscheiden, etwa ob der Webservice als eigenständige Applikation betrieben oder in eine Microservices-Architektur eingebunden wird. Für öffentliche Webservices ist ein DMZ-taugliches Design mit klaren Zonengrenzen erforderlich, um eine Trennung kritischer Komponenten zu gewährleisten.

Das Design folgt etablierten Prinzipien wie Modularität, Wiederverwendbarkeit und „Security by Design“. Sicherheitsmuster wie Eingabefilterung, Fehlerbehandlung, Trennung von Rollen und Datenverschlüsselung sind fester Bestandteil des Designs. Ebenso ist die Interoperabilität mit bestehenden Systemen, etwa durch standardisierte Schnittstellen (REST, SOAP, GraphQL), bereits im Architekturentwurf zu berücksichtigen. Integrationsanforderungen mit bestehenden IAM-Systemen, Monitoring-Infrastrukturen oder Logservern sind frühzeitig einzuplanen.

Risikobewertung

Die Risikobewertung beginnt mit einer strukturierten Risikoanalyse, bei der potenzielle Bedrohungen und Schwachstellen des geplanten Webservices identifiziert werden. Diese Analyse kann auf Basis bewährter Methoden wie STRIDE oder OCTAVE erfolgen. Die identifizierten Risiken – etwa durch unzureichende Zugriffskontrollen, unsichere Drittanbieter-Bibliotheken oder unsachgemäße Verarbeitung personenbezogener Daten – werden hinsichtlich Eintrittswahrscheinlichkeit und Schadensausmaß bewertet.

Darauf aufbauend werden geeignete Maßnahmen zur Risikominderung geplant. Dazu zählen technische, organisatorische und prozessuale Kontrollen wie die Einführung eines zentralen Patchmanagements, Einschränkung von Verwaltungszugriffen oder der Einsatz sicherer Entwicklungsframeworks. Diese Maßnahmen sind nicht nur im Sicherheitskonzept, sondern auch im Projekt-Backlog zu verankern, um eine kontinuierliche Umsetzung sicherzustellen.

Konzepterstellung

Das technische Konzept fasst alle bisherigen Ergebnisse zusammen und dokumentiert die geplante Servicestruktur, Schnittstellen, Rollenmodelle, Sicherheitsarchitektur und Betriebsprozesse. Es dient sowohl als Planungsgrundlage für die Umsetzung als auch als Nachweis gegenüber internen und externen Prüfenden.

Die Konzepterstellung schließt die detaillierte Planung von Sicherheitsmaßnahmen mit ein – darunter TLS-Konfiguration, Authentifizierungsverfahren, Mandantenfähigkeit, Protokollierung und Wiederherstellbarkeit. Datenschutzaspekte wie Speicherfristen, Datenminimierung und Betroffenenrechte sind vollständig integriert. Das Konzept ist so zu erstellen, dass es sowohl dem Stand der Technik entspricht als auch künftige Änderungen und Erweiterungen unterstützt.

Beschaffung und Installation

Die Phase der Beschaffung und Installation legt den Grundstein für einen sicheren und regelkonformen Betrieb von Webservices. Sowohl die Auswahl der Software als auch die Installation und Absicherung müssen dokumentierten Sicherheits- und Qualitätskriterien folgen, um spätere Betriebsrisiken zu minimieren und Compliance-Vorgaben zu erfüllen.

Beschaffungsprozess

Die Auswahl geeigneter Softwareprodukte und Dienstleistender erfolgt auf Basis definierter funktionaler und nicht-funktionaler Anforderungen. Neben klassischen Bewertungskriterien wie Kompatibilität, Skalierbarkeit und Integrationsfähigkeit sind auch Sicherheitsaspekte wie die Unterstützung sicherer Protokolle, die Qualität des Patchmanagements oder die Fähigkeit zur Protokollierung sicherheitsrelevanter Ereignisse entscheidend. Datenschutzrechtliche Eignung, z. B. im Sinne der DSGVO, ist spätestens bei der Verarbeitung personenbezogener Daten zwingend zu prüfen.

Die Bewertung potenzieller Anbieter oder Open-Source-Produkte erfolgt idealerweise entlang eines Kriterienkatalogs. Dabei sind u. a. Zertifizierungen (z. B. ISO 27001, BSI C5), öffentlich verfügbare Sicherheitsreports, der Umgang mit Sicherheitslücken (z. B. CVE-Handling, Responsible Disclosure), sowie die Update- und Supportpolitik relevant. Auch Aspekte der Lieferkettensicherheit (Software Supply Chain Security) gewinnen zunehmend an Bedeutung.

Bei der Vertragsgestaltung sind klare Anforderungen an Datenschutz, Verfügbarkeit, Service-Level, Reaktionszeiten bei Sicherheitsvorfällen sowie an Auditierbarkeit zu formulieren. Bei Fremdbezug von Webservices oder Komponenten, die personenbezogene Daten verarbeiten, ist eine DSGVO-konforme Vereinbarung zur Auftragsverarbeitung zwingend. Für Open-Source-Komponenten muss die Lizenzkonformität überprüft und dokumentiert werden.

Installation und Grundkonfiguration

Die Installation erfolgt gemäß dem technischen Konzept und unter Berücksichtigung sicherheitsrelevanter Vorgaben. Dabei ist sicherzustellen, dass ausschließlich vertrauenswürdige Quellen für Installationsmedien und Pakete verwendet werden. Integritätsprüfungen (z. B. über Signaturen oder Hash-Werte) sind verbindlich umzusetzen.

Der Webserver wird so konfiguriert, dass nur notwendige Module aktiviert sind. Konfigurationsdateien sind restriktiv berechtigt und standardisierte Sicherheitsparameter (z. B. für Header, Session Management oder TLS-Parameter) sind gemäß Vorgaben des BSI oder OWASP umzusetzen. Die Webservice-Komponenten selbst werden in dedizierten Verzeichnissen betrieben, die gegen unberechtigten Zugriff abgesichert sind. Abhängigkeiten und Drittbibliotheken müssen dokumentiert und in Versionen eingebunden werden, die aktiv gepflegt und auf bekannte Schwachstellen geprüft sind.

Die Grundkonfiguration umfasst auch die Anbindung an zentrale Dienste wie DNS, Logging, NTP und gegebenenfalls zentrale IAM-Lösungen. Dabei ist sicherzustellen, dass Schnittstellen nur über abgesicherte Kanäle und nach Authentifizierung erreichbar sind.

Härtung und Sicherheitskonfiguration

Nach der Basiskonfiguration folgt die systematische Härtung der Systeme nach etablierten Best Practices – z. B. anhand von CIS Benchmarks, BSI-Empfehlungen oder Herstellerleitfäden. Dies beinhaltet die Einschränkung von Benutzerrechten, die Deaktivierung von Standardzugängen, die Absicherung von Netzwerkschnittstellen sowie die Implementierung von Schutzmechanismen gegen bekannte Angriffsvektoren (z. B. Directory Traversal, Input Injection).

Nicht benötigte Dienste, Funktionen und Daemons – etwa Debug-Modi, Demoseiten oder ungenutzte Netzwerkports – sind konsequent zu entfernen oder zu deaktivieren. Die Konfiguration erfolgt nach dem Prinzip der minimalen Rechte (Least Privilege) und minimalen Funktionalität (Attack Surface Reduction). Administratorenzugänge werden ausschließlich über gesicherte Wege (z. B. SSH mit Public-Key-Verfahren, VPN) und nach Mehrfaktor-Authentifizierung bereitgestellt.

Sicherheitsfunktionen wie TLS-Verschlüsselung, restriktives Session-Handling, Logging sicherheitsrelevanter Ereignisse und automatische Sperrmechanismen bei Fehlversuchen werden aktiv konfiguriert. Der Umgang mit Fehlermeldungen erfolgt so, dass keine internen Informationen offengelegt werden („Security by Obscurity“ ist jedoch keine tragfähige Grundlage). Die Konfiguration ist durch automatisierte Tests (z. B. testssl.sh, lynis) zu verifizieren.

Monitoring und Logging

Ein wirksames Monitoring ist zentral für den sicheren Betrieb von Webservices. Bereits bei der Einrichtung müssen die relevanten Metriken definiert und in ein zentrales Überwachungssystem eingebunden werden. Dazu gehören technische Kenngrößen (z. B. Auslastung, Antwortzeiten, Fehlerraten) ebenso wie sicherheitsrelevante Indikatoren (z. B. Login-Versuche, untypische Zugriffsmuster, Dienstverfügbarkeit).

Die Konfiguration erfolgt in enger Abstimmung mit den Betriebsteams und orientiert sich am Schutzbedarf sowie an der Kritikalität des Webservices. Schwellwerte und Eskalationsstufen werden dokumentiert und regelmäßig überprüft. Die Alarmierung muss so konfiguriert sein, dass sicherheitsrelevante Ereignisse unverzüglich und nachvollziehbar erfasst und bearbeitet werden können – entweder über zentrale SIEM-Systeme oder abgestimmte Benachrichtigungsketten.

Logdaten sicherheitsrelevanter Ereignisse sind manipulationssicher, datenschutzgerecht und revisionsfähig zu speichern. Es ist sicherzustellen, dass nur autorisierte Personen Zugriff auf Protokolle haben und dass die Aufbewahrungsfristen gemäß interner Richtlinien und gesetzlicher Vorgaben eingehalten werden. Eine regelmäßige Auswertung sicherheitskritischer Logs unterstützt die Früherkennung von Angriffen und Abweichungen vom Sollverhalten.

Betrieb und Wartung

Ein sicherer und stabiler Betrieb von Webservices erfordert strukturierte Betriebsprozesse, klare Verantwortlichkeiten und ein effektives Zusammenspiel von Änderungs-, Überwachungs- und Zugriffskontrollen. Diese Phase stellt sicher, dass die zuvor entwickelten Sicherheits- und Qualitätsstandards dauerhaft umgesetzt, überwacht und weiterentwickelt werden.

Betriebskonzept

Das Betriebskonzept legt verbindlich fest, wie der Webservice im Regelbetrieb zu führen ist. Es enthält Vorgaben zu Betriebszeiten, Verantwortlichkeiten, Notfallprozessen sowie zu den technischen und organisatorischen Rahmenbedingungen des Betriebs. Eine zentrale Rolle spielt dabei die Dokumentation: Sowohl Systemkonfigurationen als auch Schnittstellen und Betriebsprozesse müssen nachvollziehbar dokumentiert und aktuell gehalten werden.

Für den Änderungs- und Updateprozess ist ein geregeltes Vorgehen zu definieren, das alle Änderungen nachvollziehbar macht, potenzielle Risiken frühzeitig identifiziert und die Auswirkungen bewertet. Governance-Vorgaben regeln die Zulässigkeit und Kontrolle von Änderungen, inklusive der Pflicht zur Genehmigung sicherheitskritischer Anpassungen. Alle Prozesse sind so zu gestalten, dass sie mit den Anforderungen eines ISMS nach ISO/IEC 27001 kompatibel sind – insbesondere im Hinblick auf Nachvollziehbarkeit und Auditierbarkeit.

Patch- und Änderungsmanagement

Ein strukturiertes Patchmanagement gewährleistet, dass Sicherheitsupdates zeitnah bewertet, getestet und installiert werden. Dabei werden alle relevanten Komponenten einbezogen – vom Betriebssystem über die Middleware bis hin zum Anwendungscode. Sicherheitsrelevante Patches sind priorisiert zu behandeln, insbesondere bei CVSS-Werten über 7 oder bei bereits aktiv ausgenutzten Schwachstellen (Exploit verfügbar).

Änderungen an der System- oder Applikationskonfiguration – sei es zur Optimierung, Anpassung an neue Anforderungen oder Fehlerbehebung – erfolgen grundsätzlich kontrolliert und dokumentiert. Jedes Change-Request durchläuft ein definiertes Verfahren zur Risikobewertung und Testfreigabe. Testumgebungen müssen so beschaffen sein, dass reale Betriebsbedingungen ausreichend simuliert werden können.

Vor dem Produktiveinsatz erfolgt eine formale Freigabe durch die zuständigen Stellen. Dies umfasst – je nach Kritikalität – automatisierte Regressionstests, Penetrationstests oder Code-Reviews. Die Nachverfolgbarkeit aller Änderungen und eingesetzten Patches muss jederzeit über ein zentrales Change-Log gewährleistet sein.

Überwachung und Protokollierung

Die kontinuierliche Überwachung des Webservices ist eine Grundvoraussetzung für die Erkennung von Betriebsstörungen, sicherheitsrelevanten Ereignissen und Kapazitätsengpässen. Dazu werden technische Metriken (z. B. Antwortzeiten, Fehlerraten, Ressourcenverbrauch) in Echtzeit überwacht. Eine mehrstufige Alarmierung stellt sicher, dass Auffälligkeiten unverzüglich analysiert und gegebenenfalls eskaliert werden.

Die Protokollierung sicherheitsrelevanter Ereignisse – z. B. Anmeldeversuche, Berechtigungsänderungen, Konfigurationszugriffe – erfolgt gemäß den Anforderungen der DSGVO, des BSI IT-Grundschutzes oder anderer regulatorischer Rahmenwerke. Logdaten sind manipulationssicher zu speichern und dürfen nur von berechtigten Personen ausgewertet werden. Die Aufbewahrungsdauer wird auf Grundlage von Schutzbedarf und rechtlichen Anforderungen festgelegt.

Anomalieerkennung erfolgt idealerweise automatisiert über etablierte Muster, Heuristiken oder ML-gestützte Verfahren. Dabei ist die Korrelation von Ereignissen aus verschiedenen Systemen (SIEM) ein bewährter Ansatz zur Erkennung komplexer Angriffe. Ergebnisse aus der Überwachung fließen regelmäßig in das Risikomanagement ein.

Nutzungsrichtlinien und Zugriffsmanagement

Die Festlegung von Nutzungsrichtlinien sorgt für klare Erwartungen im Umgang mit den bereitgestellten Webservices. Dazu gehören Vorgaben zur zulässigen Verwendung, zu sicherem Verhalten (z. B. keine Weitergabe von Zugangsdaten, keine Nutzung unverschlüsselter Verbindungen) sowie zu Sanktionen bei Missbrauch.

Benutzende und technische Konten werden nach dem Prinzip „Need to Know“ und „Least Privilege“ vergeben. Die Verwaltung der Berechtigungen erfolgt nachvollziehbar, rollengesteuert und regelmäßig überprüft. Bei Änderungen in Zuständigkeiten, Rollen oder Beschäftigungsverhältnissen ist die zeitnahe Anpassung der Berechtigungen essenziell.

Authentifizierungsverfahren orientieren sich am Schutzbedarf: Für administrative oder sicherheitskritische Zugriffe ist eine starke Authentifizierung (z. B. MFA) verpflichtend. Der Einsatz zentraler Identitätsdienste (z. B. LDAP, SAML, OpenID Connect) unterstützt nicht nur die Sicherheit, sondern auch die Nachvollziehbarkeit durch einheitliches Logging und Lifecycle-Management der Konten.

Performance- und Kapazitätsmanagement

Ein dauerhaft performanter Betrieb erfordert nicht nur initiale Optimierung, sondern auch eine kontinuierliche Überwachung und Weiterentwicklung der zugrundeliegenden Systeme. Über definierte Metriken wie Antwortzeiten, Durchsatzraten und Systemlasten kann frühzeitig erkannt werden, ob Ressourcenengpässe oder Leistungsprobleme entstehen.

Maßnahmen zur Optimierung – z. B. Caching, Load Balancing, Query-Optimierungen – sind Bestandteil der laufenden Betriebsüberwachung und werden bei Bedarf implementiert. Dabei ist sicherzustellen, dass Sicherheitsaspekte wie Session-Handling oder Zugangskontrolle durch Performance-Maßnahmen nicht kompromittiert werden.

Kapazitätserweiterungen – etwa durch Skalierung, Clusterbildung oder Migration in andere Betriebsumgebungen – müssen frühzeitig geplant und getestet werden. Für geschäftskritische Webservices ist ein dynamisches Ressourcenmanagement (z. B. via Container-Orchestrierung) sinnvoll, um Lastspitzen ohne manuelle Eingriffe abzufangen.

Notfallmanagement

Ein effektives Notfallmanagement stellt sicher, dass der Betrieb kritischer Webservices auch bei schwerwiegenden Störungen oder Sicherheitsvorfällen zeitnah wiederhergestellt werden kann. Ziel ist es, die Auswirkungen auf Verfügbarkeit, Integrität und Vertraulichkeit zu minimieren und die Handlungsfähigkeit der Organisation aufrechtzuerhalten. Dazu sind technische, organisatorische und kommunikative Maßnahmen zu verzahnen und regelmäßig zu überprüfen.

12.1 Notfallplanungen

Die Grundlage für ein funktionierendes Notfallmanagement bilden strukturierte Notfallpläne. Diese definieren systematisch, wie auf unterschiedliche Notfallszenarien zu reagieren ist – z. B. bei Ausfall der Infrastruktur, Kompromittierung von Authentifizierungsdiensten oder vollständiger Datenverlust.

Für jeden identifizierten Risikofall sind konkrete Wiederherstellungsziele zu definieren:

• Recovery Time Objective (RTO) beschreibt, wie schnell ein System oder Dienst wieder zur Verfügung stehen muss.
• Recovery Point Objective (RPO) legt fest, wie viel Datenverlust – gemessen in Zeit – tolerierbar ist.

Die Pläne müssen klare Ansprechpersonen, Kommunikationswege und technische sowie organisatorische Maßnahmen enthalten. Dabei ist darauf zu achten, dass auch externe Abhängigkeiten (z. B. Cloud-Anbieter, Zertifikatsstellen) in die Planung einbezogen werden.

12.2 Sicherheitsvorfälle und Reaktion

Ein entscheidender Bestandteil des Notfallmanagements ist der strukturierte Umgang mit IT-Sicherheitsvorfällen. Die Fähigkeit, Angriffe oder Kompromittierungen frühzeitig zu erkennen und zielgerichtet darauf zu reagieren, ist zentral für die Schadensbegrenzung und die Wiederherstellung des Normalbetriebs.

Hierzu gehören:

• definierte Erkennungsmechanismen, etwa durch SIEM-Systeme, IDS/IPS oder manuelle Auswertungen von Logs,
• standardisierte Reaktionsprozesse, einschließlich Isolierung betroffener Systeme, forensischer Sicherung und Kommunikationsmaßnahmen,
• abgestimmte Eskalationsstufen, die regeln, wann und wie interne Stellen (z. B. IT-Leitung, Datenschutzbeauftragte) oder externe Stellen (z. B. CERT-Bund, Aufsichtsbehörden) eingebunden werden.

Ein Incident-Response-Plan legt alle notwendigen Schritte fest, inklusive interner Dokumentationspflichten, Lessons Learned und Berichtsprozesse.

12.3 Backup und Wiederherstellung

Regelmäßige, überprüfbare Datensicherungen sind unverzichtbar für die Resilienz von Webservices. Das Backup-Konzept muss:

• den Schutzbedarf der Daten berücksichtigen (z. B. differenzierte Aufbewahrungsfristen, Verschlüsselung),
• alle relevanten Komponenten erfassen (Datenbanken, Konfigurationen, Zertifikate, Schlüsselmaterial) und
• klare Verantwortlichkeiten für Durchführung und Kontrolle festlegen.

Wesentlich ist, dass die Wiederherstellbarkeit der Daten regelmäßig getestet wird. Ohne dokumentierte Restore-Tests ist ein Backup-Konzept nicht wirksam. Automatisierte Testverfahren, gestaffelte Backup-Ziele (lokal/offsite/cloud) und unveränderbare Backup-Speicher (immutable backups) sind Best Practices zur Vermeidung von Datenverlust und Ransomware-Auswirkungen.

12.4 Notfall-Übungen und Tests

Notfallpläne entfalten ihre Wirkung nur dann, wenn sie unter realitätsnahen Bedingungen getestet werden. Dazu gehören geplante Notfallübungen mit Beteiligung aller relevanten Rollen – IT-Betrieb, Informationssicherheitsbeauftragte, Geschäftsleitung und ggf. externe Dienstleister.

Solche Übungen können verschiedene Formen annehmen:

• Tabletop-Übungen, bei denen das Szenario theoretisch durchgespielt wird,
• technische Simulationen, bei denen einzelne Systeme isoliert ausfallen,
• vollumfängliche Tests, bei denen komplette Wiederanläufe getestet werden.

Ziel ist nicht nur die Prüfung der technischen Maßnahmen, sondern auch die Bewertung der Reaktionsfähigkeit, Entscheidungswege und Kommunikationsabläufe. Die Ergebnisse jeder Übung sind systematisch auszuwerten, dokumentierte Schwachstellen gezielt zu adressieren und die Notfallpläne entsprechend weiterzuentwickeln.

Überprüfung und Verbesserung

Die Wirksamkeit von Sicherheits- und Betriebsmaßnahmen muss regelmäßig geprüft und aktiv weiterentwickelt werden. Ziel ist es, bestehende Prozesse und Schutzmaßnahmen systematisch auf Schwachstellen und Verbesserungspotenzial zu analysieren. Dies erfordert strukturierte Audits, belastbare Kennzahlen und eine gelebte Kultur der kontinuierlichen Verbesserung – im Einklang mit den Anforderungen eines ISMS.

Audits und Assessments

Sicherheitsüberprüfungen müssen planmäßig und risikoorientiert durchgeführt werden. Dazu gehören sowohl interne Audits als auch unabhängige Assessments durch externe Fachpersonen. Solche Prüfungen sollen nicht nur die Einhaltung definierter Vorgaben nachweisen, sondern auch bisher unerkannte Schwächen im technischen oder organisatorischen Bereich aufdecken.

Audits nach ISO/IEC 27001 oder BSI IT-Grundschutz prüfen strukturell, ob das Sicherheitsmanagementsystem wirksam umgesetzt wird. Wesentliche Kriterien sind dabei die Umsetzung der Sicherheitsziele, die Aktualität der Risikobewertung, die Einhaltung dokumentierter Verfahren sowie die Umsetzung von Maßnahmen nach dem Stand der Technik.

Penetrationstests und Schwachstellenscans ergänzen diese Audits durch eine technische Tiefenprüfung. Während Schwachstellenscans automatisiert bekannte Sicherheitslücken identifizieren, analysieren Penetrationstests gezielt, wie verwundbar ein System gegen gezielte Angriffe ist – auch unter Einbezug von Fehlkonfigurationen, Authentifizierungsmechanismen oder unzureichend geschützten Schnittstellen. Diese Tests sind regelmäßig und anlassbezogen (z. B. nach Systemänderungen) durchzuführen.

Kennzahlen und Berichtswesen

Die Steuerung und Bewertung von Sicherheits- und Betriebsprozessen erfolgt auf Basis geeigneter Kennzahlen. Diese müssen den jeweiligen Schutzbedarf und den Reifegrad der Organisation berücksichtigen. Typische Metriken betreffen:

• Systemverfügbarkeit,
• Zeit bis zur Behebung von Sicherheitslücken (Patch-Zyklen),
• Anzahl und Schweregrade von Sicherheitsvorfällen,
• Ergebnisquoten aus Audits oder Testverfahren.

Wichtig ist, dass die Kennzahlen nicht isoliert betrachtet, sondern in Form regelmäßiger Berichte strukturiert aufbereitet und zielgruppengerecht adressiert werden. Diese Berichte sind Grundlage für das Management-Review, das gemäß ISO/IEC 27001 zwingend vorgesehen ist. Im Rahmen dieser Reviews bewertet die Unternehmensleitung die Wirksamkeit des ISMS, beschließt notwendige Maßnahmen zur Anpassung und priorisiert Ressourcen für die Weiterentwicklung.

Kontinuierlicher Verbesserungsprozess

Ein gelebter kontinuierlicher Verbesserungsprozess (KVP) ist essenziell für ein widerstandsfähiges Sicherheitsniveau. Basis hierfür ist die strukturierte Analyse von Sicherheitsvorfällen, Audit-Feststellungen, Monitoring-Ergebnissen sowie Rückmeldungen aus dem operativen Betrieb.

Dabei ist ein transparenter Feedbackmechanismus zu etablieren, über den technische oder organisatorische Schwächen gemeldet und dokumentiert werden können – idealerweise durch alle beteiligten Rollen, nicht nur die IT-Abteilung.

Die gewonnenen Erkenntnisse fließen in die Überarbeitung von Richtlinien, Verfahrensanweisungen und Sicherheitsmaßnahmen ein. Anpassungen erfolgen nachvollziehbar, dokumentiert und auf Basis strukturierter Entscheidungskriterien (z. B. Risikoauswirkung, Umsetzbarkeit, Abhängigkeiten). Wichtig ist, dass auch externe Entwicklungen – wie neue Bedrohungslagen oder regulatorische Änderungen – kontinuierlich beobachtet und in das Sicherheitsmanagement integriert werden.

Außerbetriebnahme

Die Außerbetriebnahme von Webservices ist ein sicherheitsrelevanter Prozess, der nicht nur das Abschalten technischer Komponenten betrifft, sondern auch Fragen der Datenhaltung, Compliance, Nachvollziehbarkeit und Nachhaltigkeit. Eine strukturierte Vorgehensweise minimiert Risiken, sichert regulatorische Anforderungen und ermöglicht eine geordnete Übergabe, Migration oder endgültige Stilllegung.

Planung der Außerbetriebnahme

Bevor ein Webservice außer Betrieb genommen wird, ist zu prüfen, ob die dafür notwendigen Voraussetzungen erfüllt sind. Technisch-fachliche Kriterien können z. B. durch Systemablösung, veraltete Plattformen oder strategische Neuausrichtungen gegeben sein. Daneben spielen Aspekte wie Wirtschaftlichkeit, Wartungsaufwand oder mangelnde Nutzung eine Rolle.

Die Planung umfasst:

• eine belastbare Zeitplanung, die Abhängigkeiten zu anderen Systemen und Datenflüssen berücksichtigt,
• eine realistische Ressourcenkalkulation für Personal, Infrastruktur und externe Dienstleister,
• eine strukturierte Kommunikation mit allen betroffenen Stellen, etwa Fachbereiche, IT-Betrieb, Informationssicherheits- und Datenschutzbeauftragte.

Ziel ist es, frühzeitig sicherzustellen, dass alle Prozesse im Zusammenhang mit der Außerbetriebnahme nachvollziehbar und mit möglichst geringem Störpotenzial für den laufenden Betrieb umgesetzt werden.

Datenmigration und -archivierung

Im Rahmen der Stilllegung sind Datenbestände differenziert zu betrachten: Welche Daten sind noch produktiv erforderlich? Welche müssen revisionssicher archiviert werden? Und welche dürfen oder müssen gelöscht werden?

Ein geordnetes Vorgehen umfasst:

• die Sicherung und Validierung aller relevanten Daten vor der Abschaltung,
• eine Datenmigration in Nachfolgesysteme, sofern erforderlich – unter Berücksichtigung von Konsistenz, Vollständigkeit und Integrität,
• die Langzeitarchivierung nach geltenden rechtlichen und regulatorischen Vorgaben, etwa gemäß GoBD, HGB, DSGVO oder branchenspezifischen Aufbewahrungsfristen.

Besondere Aufmerksamkeit gilt personenbezogenen Daten: Hier ist eine sorgfältige Datenbereinigung geboten, bei der ausschließlich Daten verarbeitet werden, für die eine Rechtsgrundlage vorliegt.

Sichere Entsorgung

Ein sicherer Rückbau umfasst mehr als das Abschalten von Diensten. Daten, Systeme und ggf. Hardware müssen nachhaltig und nachvollziehbar entsorgt werden.

Dabei ist sicherzustellen, dass:

• alle Datenbestände sicher gelöscht oder physikalisch vernichtet werden, z. B. durch zertifizierte Verfahren wie Secure Erase, Degaussing oder physische Zerstörung,
• ausgediente Hardware umweltgerecht entsorgt oder recycelt wird – idealerweise durch zertifizierte Entsorgungsunternehmen,
• alle Schritte vollständig dokumentiert werden, einschließlich Entsorgungsnachweise, Seriennummern und ggf. Abnahmeprotokolle.

Der Nachweis der Datenvernichtung ist insbesondere für schutzbedürftige oder personenbezogene Daten zwingend erforderlich und Bestandteil des Verfahrensverzeichnisses.

Abschließende Dokumentation

Zum Abschluss des Stilllegungsprozesses ist eine umfassende Dokumentation anzufertigen. Diese enthält:

• die vollständige Chronologie und Beschreibung des Außerbetriebnahmeprozesses,
• eine strukturierte Darstellung von Lessons Learned, z. B. technische oder organisatorische Erkenntnisse, die in künftige Projekte einfließen sollen,
• die Aktualisierung aller betroffenen Dokumente, etwa IT-Servicekatalog, Netzwerkpläne, Rollenverzeichnisse oder ISMS-relevante Nachweise (z. B. Asset-Listen, Risikoanalysen, BCM-Pläne).

Die abschließende Bewertung und Genehmigung des Prozesses sollte durch die verantwortlichen Rollen (IT, Informationssicherheit, Datenschutz) gemeinsam erfolgen. Damit wird sichergestellt, dass alle Aspekte der Stilllegung nachvollziehbar abgeschlossen und keine Sicherheits- oder Compliance-Lücken bestehen bleiben.

Schlussbemerkung

Behandlung von Ausnahmen

Ausnahmen von den Regelungen dieser Richtlinie sind nur mit einem begründeten Ausnahmeantrag im Rahmen des Ausnahmemanagements möglich.

Revision

Diese Richtlinie wird regelmäßig, jedoch mindestens einmal pro Jahr, durch den Regelungsverantwortlichen auf Aktualität und Konformität geprüft und bei Bedarf angepasst.

Inkrafttreten

Diese Richtlinie tritt zum 01.01.2222 in Kraft.

Freigegeben durch: Organisationsleitung

Ort, 01.12.2220,

Unterschrift, Name der Leitung