Grundregel: Informationssicherheit wird von der Projektidee bis zum Projektabschluss in Ziele, Anforderungen, Risiken, Entscheidungen, Ressourcen, Lieferobjekte und Abnahmen integriert.
Kein Umsetzungsnachweis: Diese Seite beschreibt das Sollverfahren der fiktiven „Muster GmbH“. Sie belegt weder, dass ein vollständiges Projektportfolio geführt wird, noch dass Sicherheitsanforderungen, Gate-Prüfungen, Risikoentscheidungen oder Abnahmen in realen Projekten durchgeführt wurden.
TISAX-Hinweis: Im Reiter „Informationssicherheit“ der ISA-Selbsteinschätzung sind alle 46 Fragen umzusetzen und zu bewerten. Einzelne Fragen werden nicht wie Controls in einer ISO-27001-SoA als „nicht anwendbar“ ausgeschlossen.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-11 |
| Dokumentenart | Richtlinie und Verfahren für Informationssicherheit im Projektmanagement |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Informationssicherheit-im-Projektmanagement |
| Verantwortlich | Projektmanagement-Verantwortung und ISMS-Verantwortliche/r |
| Fachlich geprüft durch | Projektverantwortliche, Information Owner, IT, Datenschutz, Recht/Compliance, Einkauf, Entwicklung, BCM und TISAX-Koordination |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Projektportfolio, Gate-Prozess, Rollen, Nachweise und Wirksamkeit nicht bestätigt |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Nächste Prüfung | Mindestens jährlich sowie bei wesentlichen Änderungen des Projektmodells, der Anforderungen oder des ISMS |
| Schutzklasse | Intern |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.8; ergänzend 5.2, 5.3, 5.5, 5.6, 5.19 bis 5.23, 5.31 bis 5.34, 8.25 bis 8.33 und 8.32 |
| VDA-ISA-Bezug | ISA 6.0.3, Informationssicherheit – alle 46 Fragen; insbesondere Organisation, Risikomanagement, Lieferantenbeziehungen, Betriebssicherheit sowie Systembeschaffung und Entwicklung |
Diese Regelung legt fest:
Ziel ist, Sicherheitsanforderungen rechtzeitig und nachvollziehbar in Projekte einzubauen und späte, teure oder unkontrollierte Nachbesserungen zu vermeiden.
Die Regelung gilt im festgelegten ISMS-Geltungsbereich für:
Die Bezeichnung „Projekt“, „Initiative“, „Pilot“, „Proof of Concept“, „Test“, „Migration“ oder „Sonderauftrag“ ändert nichts an der Anwendbarkeit.
Diese Seite steuert die Integration der Informationssicherheit in das Projektmanagement. Sie ersetzt nicht:
Projektfreigabe und Sicherheitsfreigabe sind getrennte Entscheidungen. Eine Termin-, Budget- oder Kundenfreigabe bestätigt nicht automatisch die Informationssicherheit.
| Begriff | Bedeutung |
|---|---|
| Projekt | zeitlich begrenztes Vorhaben mit definiertem Ziel, Ressourcen, Verantwortlichkeiten und Lieferobjekten |
| Projektauftrag | dokumentierte Beauftragung mit Ziel, Scope, Rollen, Rahmen und Entscheidung |
| Sicherheitsrelevanz | Ausmaß, in dem ein Projekt Informationswerte, Systeme, Personen, Kunden, Standorte oder Schutzanforderungen beeinflusst |
| Security-by-Design | Sicherheitsanforderungen werden von Beginn an in Lösung und Prozess eingebaut |
| Security-by-Default | die sichere Konfiguration und Nutzung ist der vorgesehene Ausgangszustand |
| Security Gate | definierter Entscheidungspunkt mit Sicherheitskriterien und dokumentiertem Ergebnis |
| Sicherheitsanforderung | überprüfbare Vorgabe für Organisation, Prozess, Technik, Personal, Vertrag oder Nachweis |
| Sicherheitslieferobjekt | im Projekt zu erstellender oder zu übergebender Sicherheitsnachweis |
| Projektrisiko | Unsicherheit, die Projektziele oder Schutzwerte beeinträchtigen kann |
| ISMS-Risiko | Risiko für Informationen oder Informationsverarbeitung, das im ISMS gesteuert wird |
| Restpunkt | offene Anforderung, Abweichung oder Maßnahme bei Übergabe oder Abschluss |
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung/Projektsponsor | Projektauftrag, Ressourcen, wesentliche Risiken und Eskalationen entscheiden |
| Projektleitung | Sicherheitsaktivitäten planen, Verantwortliche einbinden, Nachweise und offene Punkte steuern |
| ISMS-Verantwortung | Sicherheitsrelevanz, ISMS-Anbindung, Risiko- und Gate-Prüfungen koordinieren |
| Information Owner | Schutzbedarf, zulässige Nutzung, Empfänger, Aufbewahrung und Akzeptanz fachlich entscheiden |
| Asset-/System Owner | Sicherheitsanforderungen, Betriebsfähigkeit, technische Abnahme und Lifecycle verantworten |
| Fachbereich/Product Owner | Geschäftsanforderungen, Akzeptanzkriterien und fachliche Abnahme festlegen |
| IT/Architektur | Architektur, Integration, Betrieb, Netz, Identitäten, Protokollierung und Resilienz prüfen |
| Entwicklung | sicheren Entwicklungslebenszyklus, Tests und technische Nachweise umsetzen |
| Datenschutz | Personenbezug, Datenschutzanforderungen und Datenschutz-Folgenabschätzung prüfen |
| Recht/Compliance | Rechts-, Vertrags-, Geheimhaltungs-, Export- und Nachweisanforderungen prüfen |
| Einkauf/Lieferantenmanagement | Due Diligence, Verträge, Unterauftragnehmer, Leistung und Exit steuern |
| BCM/Notfallmanagement | Kritikalität, Abhängigkeiten, Wiederanlauf und Notbetrieb prüfen |
| Projekt-QS/Test | unabhängige Prüfungen, Testabdeckung, Befunde und Abnahme unterstützen |
| Betrieb/Service Owner | Betriebsübernahme, Monitoring, Support, Patchen, Backup und Exit bestätigen |
| TISAX-/Kundenkoordination | Assessment-, Kunden- und Prototypenanforderungen koordinieren |
Rollen, Stellvertretungen und Entscheidungsbefugnisse werden projektspezifisch dokumentiert.
Alle Vorhaben mit möglicher Sicherheitsrelevanz werden frühzeitig in einem Projektregister erfasst.
| Feld | Inhalt |
|---|---|
| Projekt-ID und Titel | eindeutige Referenz |
| Sponsor/Projektleitung | benannte Rollen und Stellvertretung |
| Ziel und Scope | erwartetes Ergebnis sowie Ein- und Ausschlüsse |
| betroffene Prozesse/Standorte | Referenzen zur Prozess- und Scope-Dokumentation |
| betroffene Assets/Informationen | Systeme, Daten, Dienste, Geräte und Lieferobjekte |
| Kunden/Lieferanten | beteiligte Organisationen und Ansprechpartner |
| Sicherheitsrelevanz | Stufe, Begründung und Prüftiefe |
| Schutzklassen | höchste betroffene Klasse und Zusatzkennzeichen |
| Rechts-/Vertragsbezug | Kataster-, Kunden- und Genehmigungsreferenzen |
| Risiken/Maßnahmen | Projekt- und ISMS-Risiken mit Ownern |
| Gates | geplante und erreichte Entscheidungen |
| Zielbetrieb | Service-/Asset-Owner und Betriebsmodell |
| Status | Idee, Prüfung, freigegeben, aktiv, pausiert, Übergabe, beendet |
| Abschluss/Review | Datum, Ergebnis, Restpunkte und Lessons Learned |
Der reale Projektbestand ist vor Freigabe dieser Richtlinie zu erheben.
Eine Sicherheitsprüfung ist insbesondere erforderlich bei:
Vor Projektfreigabe wird mindestens bewertet:
| Prüfdimension | Leitfrage |
|---|---|
| Informationen | Welche Klassen, Kunden-, Personen-, Prototypen- oder Geheimnisinformationen sind betroffen? |
| Kritikalität | Welche Geschäftsprozesse und Wiederanlaufziele können beeinflusst werden? |
| Exposition | Gibt es Internetzugriff, externe Verbindungen, mobile Nutzung oder neue Vertrauensgrenzen? |
| Technologie | Ist die Lösung neu, komplex, nicht unterstützt oder schwer reversibel? |
| Änderungen | Werden Architektur, Identitäten, Netze, Prozesse oder Standorte wesentlich verändert? |
| Dritte | Sind Lieferanten, Cloud-Anbieter, Unterauftragnehmer oder externe Entwicklung beteiligt? |
| Recht/Vertrag | Bestehen Kunden-, Datenschutz-, Export-, Lizenz- oder Genehmigungsanforderungen? |
| Umfang | Sind viele Personen, Systeme, Datensätze oder Standorte betroffen? |
| Sicherheitsfolgen | Können Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität oder Nachweisbarkeit wesentlich beeinträchtigt werden? |
| Exit | Kann die Lösung kontrolliert beendet, ersetzt und gelöscht werden? |
Das Ergebnis bestimmt Sicherheitsstufe, erforderliche Rollen, Gates und Nachweise.
| Stufe | typische Merkmale | Mindeststeuerung |
|---|---|---|
| S0 – keine erkennbare zusätzliche Sicherheitswirkung | rein organisatorisches Vorhaben ohne relevante Informations-/Systemänderung | dokumentierte Vorprüfung und normale Schutzregeln |
| S1 – begrenzte Sicherheitsrelevanz | interne Informationen, Standardlösung, begrenzter Nutzerkreis | Sicherheitsanforderungen, Risikoprüfung und Abschlusskontrolle |
| S2 – erhöhte Sicherheitsrelevanz | vertrauliche Daten, externe Schnittstellen, Lieferanten, wichtige Prozesse | Security Owner, detaillierte Risikoanalyse, mehrere Gates, Tests und Betriebsabnahme |
| S3 – hohe/kritische Sicherheitsrelevanz | streng vertrauliche, Prototypen- oder Massendaten; kritische Produktion; erhebliche Rechts-/Kundenwirkung | unabhängige Prüfung, Managemententscheidungen, vertiefte Tests, Notfall-/Exitnachweis und engmaschige Steuerung |
Schwellenwerte, Benennung und verbindliche Kriterien sind vor Freigabe anhand des realen Projektmodells zu bestätigen.
Der Projektauftrag enthält mindestens:
Ungeklärte sicherheitsrelevante Annahmen werden sichtbar als offene Punkte geführt.
Für Projekte ab festgelegter Sicherheitsstufe wird ein Sicherheitsplan geführt.
| Feld | Inhalt |
|---|---|
| Sicherheitsziele | konkrete Schutzziele und Bezug zu Projektzielen |
| Anforderungen | eindeutige, priorisierte und testbare Sicherheitsanforderungen |
| Rollen | Verantwortliche, Prüfer, Genehmigende und Stellvertretungen |
| Risiken | Bewertung, Maßnahmen, Rest- und Akzeptanzentscheidungen |
| Architektur/Design | Sicherheitsprinzipien, Vertrauensgrenzen und Abhängigkeiten |
| Daten/Assets | Klassen, Flüsse, Ablagen, Eigentümer und Lebenszyklus |
| Lieferanten | Due Diligence, Verträge, Kontrollen und Exit |
| Tests | Testarten, Abdeckung, Kriterien, Umgebungen und Nachweise |
| Gates | Eingangskriterien, Entscheider und erwartete Lieferobjekte |
| Betrieb | Monitoring, Support, Patchen, Backup, Notfall und Wiederanlauf |
| Kommunikation | vertrauliche Projektkommunikation und Meldewege |
| Abschluss | Übergabe, Restpunkte, Rückgabe, Löschung und Lessons Learned |
Jede wesentliche Sicherheitsanforderung wird nachvollziehbar geführt.
| Feld | Inhalt |
|---|---|
| Anforderungs-ID | eindeutige Referenz |
| Quelle | Recht, Vertrag, Kunde, Risiko, Policy, Architektur oder Standard |
| Anforderung | klarer und überprüfbarer Sollzustand |
| Begründung/Schutzziel | betroffener Wert und erwartete Wirkung |
| Priorität | Muss/Soll/Kann oder bestätigtes Projektmodell |
| Owner | fachlich verantwortliche Rolle |
| Umsetzung | Arbeitspaket, Komponente, Lieferant oder Prozess |
| Akzeptanzkriterium | messbares Prüfergebnis |
| Nachweis | Test, Konfiguration, Dokument, Protokoll oder Abnahme |
| Status | offen, in Arbeit, umgesetzt, geprüft, abgelehnt oder Ausnahme |
| Änderung | Version, Entscheidung, Datum und Auswirkung |
„Sicher“, „angemessen“ oder „nach Stand der Technik“ ohne konkretisierte Kriterien ist allein nicht ausreichend testbar.
Anforderungen werden aus mindestens folgenden Quellen abgeleitet:
Projekt- und ISMS-Risiken werden miteinander verbunden, aber nicht vermischt:
Ein Projektrisiko darf nicht allein wegen Projektende geschlossen werden, wenn das Sicherheitsrisiko im Betrieb fortbesteht.
Ab Sicherheitsstufe S2 oder bei entsprechendem Risiko werden betrachtet:
Methode und Tiefe werden der Lösung angepasst und dokumentiert.
Das Projekt:
Architekturentscheidungen berücksichtigen mindestens:
Wesentliche Entscheidungen und bewusst verworfene Alternativen werden nachvollziehbar dokumentiert.
Bei Personenbezug werden frühzeitig geprüft:
Die Datenschutzprüfung erfolgt mit der zuständigen Rolle und wird nicht durch eine allgemeine Sicherheitsbewertung ersetzt.
Vor Design- oder Beschaffungsentscheidung werden insbesondere geprüft:
Ergebnisse werden mit Rechts- und Vertragskataster und gegebenenfalls Prototypenschutz verknüpft.
Vor Beauftragung werden nach Risiko bewertet:
Die Anforderungen werden vor Leistungsbeginn vertraglich oder anderweitig verbindlich übertragen. Einzelheiten regelt Lieferanten und Dienstleister.
Das Projekt stellt sicher:
Der Kommunikationsplan legt fest:
Übertragungen erfolgen nach Informationsübertragung.
Einzelheiten regelt Zugriff und Berechtigungen.
Sicherheitsanforderungen werden vor Produktauswahl, Bestellung oder Vertragsschluss festgelegt.
Die Bewertung umfasst:
Eine bereits ausgewählte Lösung darf die Sicherheitsanforderungen nicht nachträglich ohne dokumentierte Entscheidung beschränken.
Bei Software-, Produkt- oder Konfigurationsentwicklung gelten:
Das Detailverfahren ist in Sichere Entwicklung beschrieben.
Die Teststrategie leitet Umfang und Unabhängigkeit aus Risiko und Sicherheitsstufe ab.
| Prüfart | möglicher Inhalt |
|---|---|
| Anforderungsreview | Vollständigkeit, Eindeutigkeit und Testbarkeit |
| Architekturreview | Vertrauensgrenzen, Angriffsflächen und Sicherheitsprinzipien |
| Konfigurationsprüfung | Härtung, Rollen, Protokolle, Verschlüsselung und Defaults |
| Code-/Komponentenprüfung | Schwachstellen, Secrets, Abhängigkeiten und Herkunft |
| Schnittstellenprüfung | Authentisierung, Autorisierung, Validierung, Fehler und Wiederholung |
| Schwachstellenprüfung | automatisierte und manuelle Prüfungen nach Exposition |
| Berechtigungsprüfung | Rollen, Funktionstrennung und privilegierte Zugriffe |
| Wiederanlaufprüfung | Backup, Restore, Failover, Notbetrieb und Abhängigkeiten |
| Datenschutzprüfung | Minimierung, Rollen, Rechte, Löschung und Übermittlung |
| fachliche Sicherheitsabnahme | Soll-Ist-Abgleich und Restpunkte |
Testtiefe, Testdaten, Werkzeuge, Unabhängigkeit, Kriterien und Behandlung von Befunden werden vorab festgelegt.
Jeder relevante Befund enthält:
Ein Status „behoben“ ohne Retest oder geeigneten Umsetzungsnachweis schließt den Befund nicht automatisch.
Änderungsanträge werden auf Sicherheitsauswirkungen geprüft, insbesondere bei:
Die Änderung aktualisiert Anforderungen, Risiken, Tests, Dokumentation, Verträge und Gate-Entscheidungen. Technische Änderungen folgen zusätzlich IT-Betrieb und Änderungen.
Agile Arbeitsweisen ändern die Sicherheitsziele nicht. Sicherheitssteuerung wird integriert durch:
Ein Pilot ist kein kontrollfreier Raum.
| Gate | Zeitpunkt | Mindestentscheidung |
|---|---|---|
| G0 – Vorprüfung | Projektidee | Sicherheitsrelevanz, Verantwortliche und Prüftiefe bestimmt |
| G1 – Auftrag | vor Projektfreigabe | Scope, Anforderungen, Risiken, Ressourcen und Sicherheitsplan akzeptiert |
| G2 – Design/Beschaffung | vor Bindung an Lösung/Anbieter | Architektur, Lieferant, Datenschutz, Vertrag und Exit bewertet |
| G3 – Build/Umsetzung | vor Integrations- oder Abnahmetest | Anforderungen umgesetzt, Nachweise und offene Befunde bekannt |
| G4 – Produktivsetzung/Übergabe | vor produktiver Nutzung | Tests, Betriebsfähigkeit, Risiken, Dokumentation und Rückfall freigegeben |
| G5 – Abschluss | vor Projektauflösung | Assets, Zugänge, Verträge, Restpunkte, Löschung und Lessons Learned übergeben |
| G6 – Nutzen-/Wirksamkeitsreview | nach definierter Betriebsphase | Sicherheitsziele und Maßnahmen im realen Betrieb wirksam geprüft |
Gates können mit dem bestehenden Projektmodell kombiniert werden. Kriterien und Entscheider dürfen dabei nicht entfallen.
Zulässige Ergebnisse sind:
| Entscheidung | Bedeutung |
|---|---|
| Freigegeben | alle verpflichtenden Kriterien erfüllt und nachgewiesen |
| Freigegeben mit Auflagen | begrenzte offene Punkte mit Owner, Termin, Schutzmaßnahme und zulässigem Risiko |
| Zurückgestellt | Informationen, Nachweise oder Entscheidungen fehlen |
| Abgelehnt | Risiko oder Nichterfüllung ist nicht vertretbar |
| Abbruch | Projekt wird kontrolliert beendet und zurückgebaut |
Eine Freigabe mit Auflagen ist keine dauerhafte Ausnahme. Kritische Ausschlusskriterien und genehmigungsfähige Restpunkte sind vor Anwendung festzulegen.
| Gate | typische Nachweise |
|---|---|
| G0 | Vorprüfung, Projektregistereintrag, vorläufige Owner |
| G1 | Projektauftrag, Sicherheitsstufe, Anforderungs- und Risikoregister, Ressourcen |
| G2 | Architekturentscheidung, Lieferanten-/Datenschutz-/Vertragsprüfung, Datenflüsse, Exitkonzept |
| G3 | Umsetzungsstatus, Testplan, Konfiguration, Komponenten-/Asset-Nachweise, Befundliste |
| G4 | Testberichte, Retests, Betriebsabnahme, Monitoring, Backup/Restore, Notfall, Schulung, Freigaben |
| G5 | Übergabeprotokoll, Restpunktliste, Zugriffsbereinigung, Rückgabe/Löschung, Abschlussbericht |
| G6 | Betriebskennzahlen, Vorfälle, Wirksamkeitsprüfung, Nutzer-/Owner-Feedback und Verbesserungen |
Projektabweichungen werden nach Ausnahmen und Risikoakzeptanzen behandelt.
Sie enthalten mindestens:
Projektleitung oder Anbieter dürfen Risiken nicht stellvertretend für den zuständigen Risikoeigentümer akzeptieren.
Eine Eskalation erfolgt insbesondere bei:
Eskalationsziel und Frist richten sich nach Risiko und Entscheidungskompetenz.
Vor produktiver Nutzung bestätigt der künftige Service-/Asset-Owner mindestens:
Eine technische Bereitstellung allein ist keine Betriebsabnahme.
Projekte mit kritischen Prozessen oder Diensten:
Ein Konzept ohne praktische Prüfung gilt nicht als Wirksamkeitsnachweis.
Sicherheitsereignisse werden über den Meldeweg für Sicherheitsvorfälle behandelt.
Das Projekt:
Vor Auflösung der Projektorganisation werden:
Auch bei Abbruch oder Pause werden:
Das Abschluss- oder Wirksamkeitsreview betrachtet:
Verbesserungen werden in Kontinuierliche Verbesserung überführt.
| Kennzahl | Definition | Ziel im Entwurf |
|---|---|---|
| Projekte mit dokumentierter Sicherheitsvorprüfung | geprüfte / identifizierte relevante Projekte | Zielwert festzulegen |
| Projekte mit bestätigter Sicherheitsstufe | eingestufte / relevante Projekte | Zielwert festzulegen |
| rechtzeitig einbezogene Sicherheitsrollen | vor G1 einbezogen / relevante Projekte | Zielwert festzulegen |
| Anforderungen mit Akzeptanzkriterium | testbare / wesentliche Sicherheitsanforderungen | Zielwert festzulegen |
| Gates mit vollständigem Nachweis | vollständige / fällige Gates | Zielwert festzulegen |
| überfällige kritische Befunde | Anzahl und Alter | 0 angestrebt |
| Produktivsetzungen mit offener kritischer Abweichung | Anzahl | 0 |
| Projekte mit kontrollierter Betriebsübergabe | vollständige Übergaben / Produktivsetzungen | Zielwert festzulegen |
| Projekte mit Wirksamkeitsreview | geprüfte / fällige Projekte | Zielwert festzulegen |
| wiederkehrende Ursachen | Anzahl nach Kategorie und Trend | Reduktion anzustreben |
Zielwerte, Datenquellen, Berichtsfrequenz und Owner werden vor Freigabe festgelegt.
Geeignete Stichproben verfolgen:
Auditergebnisse werden in Interne Audits und Abweichungen und Korrekturmaßnahmen behandelt.
| ISO/IEC-27001:2022-Bezug | Beitrag dieser Seite |
|---|---|
| A.5.8 Informationssicherheit im Projektmanagement | Sicherheitssteuerung über Projektlebenszyklus, Rollen, Anforderungen, Risiken, Gates und Nachweise |
| A.5.2/A.5.3 Rollen und Funktionstrennung | Projekt- und Sicherheitsverantwortung sowie unabhängige Prüfungen |
| A.5.19 bis A.5.23 | Lieferanten-, Cloud-, Vertrags-, Änderungs- und Exitsteuerung |
| A.5.31 bis A.5.34 | Rechts-, Vertrags-, Aufzeichnungs-, Datenschutz- und Vertraulichkeitsanforderungen |
| A.8.25 bis A.8.33 | sicherer Entwicklungslebenszyklus, Anforderungen, Architektur, Code, Tests, externe Entwicklung und Umgebungen |
| A.8.32 | Sicherheitsbewertung von Änderungen |
Die verbindliche Anwendbarkeit und der Umsetzungsstatus werden im Statement of Applicability geführt. Diese Richtlinie ist ein möglicher Sollnachweis, aber kein Beleg für Umsetzung oder Wirksamkeit in realen Projekten.
Die Regelung unterstützt insbesondere:
Verbindliche Bewertungsregeln:
Die Bewertung erfolgt in VDA-ISA-Selbsteinschätzung und Maßnahmenplan und Reifegrad.
Die Projektsteuerung unterstützt insbesondere die Behandlung von:
| Referenz | Projektbezug |
|---|---|
| RIS-2026-001 | Identitäten, Rollen und vertrauliche Kundenzeichnungen |
| RIS-2026-003 | Cloud-Abhängigkeit, Notbetrieb, Export und Exit |
| RIS-2026-004 | externe Fernzugriffe und Lieferanten |
| RIS-2026-005 | Informationsübertragung und sensible Freigaben |
| RIS-2026-006 | Wiederherstellbarkeit kritischer Systeme |
| RIS-2026-008 | physischer und Prototypenschutz |
| RIS-2026-010 | Schwachstellen, Patchen und technische Änderungen |
| RIS-2026-012 | Rechts-, Vertrags- und Kundenanforderungen |
| RIS-2026-013 | Softwarekomponenten und IKT-Lieferkette |
Die Referenz bedeutet nicht, dass Risiken oder Maßnahmen durch Erstellung dieser Seite behandelt oder abgeschlossen sind.
Die Seite unterstützt insbesondere TISAX-M-002, TISAX-M-004, TISAX-M-011, TISAX-M-012 und TISAX-M-013.
TISAX-M-011 bleibt offen, bis Sicherheitsanforderungen in realen Beschaffungs-, Entwicklungs-, Test- und Änderungsprojekten umgesetzt, geprüft und mit belastbaren Nachweisen belegt sind.
| Prüfaspekt | Status am 23.07.2026 |
|---|---|
| Sollregelung erstellt | Ja, als Entwurf |
| reales Projektportfolio erfasst | Nicht nachgewiesen |
| Sicherheitsstufen und Schwellenwerte freigegeben | Nein |
| Projekt-Security-Gates operationalisiert | Nicht nachgewiesen |
| Rollen und Entscheidungsbefugnisse bestätigt | Nein |
| Sicherheitsanforderungsregister in Projekten | Nicht nachgewiesen |
| reale Risiko- und Gate-Nachweise | Nicht geprüft |
| Lieferanten-, Datenschutz- und Vertragsintegration | Nicht vollständig geprüft |
| Betriebsübergabe und Wirksamkeitsreview | Nicht nachgewiesen |
| TISAX-M-011 abgeschlossen | Nein, offen |
| fachliche Prüfung | Ausstehend |
| Geschäftsführungsfreigabe | Ausstehend |
| 46 ISA-Informationssicherheitsfragen bewertet | Nein; 0 von 46 |
TISAX-M-011 kontrollfragenbezogen konkretisieren| Prüffrage | Status Entwurf |
|---|---|
| Sind alle Projektarten und informellen Vorhaben erfasst? | Nein |
| Sind Sicherheitsstufen und Prüftiefen eindeutig? | Beispielsweise beschrieben; nicht freigegeben |
| Sind Anforderungen testbar und nachverfolgbar? | Sollverfahren vorhanden; reale Anwendung offen |
| Sind Gate-Entscheider und Ausschlusskriterien bestätigt? | Nein |
| Sind ISMS-Risiken mit Projekt- und Betriebsrisiken verbunden? | Konzeptuell; nicht praktisch nachgewiesen |
| Sind Lieferanten, Datenschutz, Kunden und Verträge integriert? | Sollregelung vorhanden; Bestand offen |
| Sind Entwicklung, Change, Notfall und Übergabe abgestimmt? | Verweise vorhanden; praktische Integration offen |
| Sind Ausnahmen befristet und befugt entschieden? | Nicht nachgewiesen |
| Ist mindestens eine reale Projektstichprobe vollständig geprüft? | Nein |
| Ist TISAX-M-011 wirksam abgeschlossen? | Nein |
| Sind alle 46 ISA-Informationssicherheitsfragen bewertet? | Nein; 0 von 46 |
| Liegen fachliche Prüfung und Geschäftsführungsfreigabe vor? | Nein |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Sicherheitssteuerung für Projektlebenszyklus, Anforderungen, Risiken, Gates, Übergabe und Abschluss angelegt | Projektmanagement / ISMS | Ausstehend | – |
| Funktion | Name | Entscheidung | Datum |
|---|---|---|---|
| Projektmanagement-Verantwortung | – | Fachliche Prüfung ausstehend | – |
| ISMS-Verantwortung | – | Sicherheitsprüfung ausstehend | – |
| IT/Entwicklung/Betrieb | – | technische und betriebliche Prüfung ausstehend | – |
| Datenschutz/Recht/Compliance | – | Anforderungsprüfung ausstehend | – |
| Geschäftsführung | – | Freigabe ausstehend | – |
Normtexte, VDA-ISA, Rechtsquellen, Kundenverträge und aktuelle technische Empfehlungen sind in ihrer jeweils gültigen Fassung separat zu prüfen. Diese Seite gibt keine Norm, Rechtsquelle oder vertragliche Vorgabe vollständig wieder.