Praxisorientierte Einordnung zu TISAX Scope richtig festlegen: Standorte, Prozesse und Informationswerte: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für TISAX Beratung aufbauen.
Der TISAX Assessment Scope bestimmt, welche Standorte, Prozesse, Verfahren und Ressourcen im Assessment betrachtet werden. Ein zu enger Scope kann die Kundenanforderung verfehlen; ein unnötig breiter Scope erhöht Aufwand und verbindet unterschiedlich reife Bereiche. Gute Abgrenzung folgt deshalb dem tatsächlichen Umgang mit Schutzobjekten, nicht dem Organigramm.
ENX empfiehlt für die große Mehrheit der Teilnehmer den vorgegebenen Standard Scope. Die wesentliche Gestaltungsfrage ist nicht sein Wortlaut, sondern welche Locations registriert werden und wie zentrale Leistungen, mobile Arbeit, Cloud und Dienstleister einbezogen sind. Eine belastbare Datenflussanalyse schafft dafür die Grundlage.
ISMS-Scope und Assessment Scope sind nicht identisch
Ein Unternehmen definiert den Geltungsbereich seines Informationssicherheitsmanagementsystems selbst. Der TISAX Assessment Scope kann kleiner sein, muss aber innerhalb dieses ISMS liegen. Das Assessment betrachtet die für die ausgewählten Schutzobjekte und Objectives relevanten Prozesse, Verfahren und Ressourcen an den registrierten Standorten.
Diese Unterscheidung erlaubt ein breites Unternehmens-ISMS und einen kundenbezogenen Assessment Scope. Sie darf jedoch nicht dazu dienen, zentrale Abhängigkeiten auszublenden. Eine Kontrolle aus dem breiteren ISMS bleibt im Assessment relevant, wenn sie die Sicherheit des Scopes trägt.
Der Standard Scope schützt die Austauschbarkeit
Die Standard-Scope-Beschreibung ist von ENX vorgegeben und kann nicht frei formuliert werden. Andere TISAX-Teilnehmer akzeptieren Assessment-Ergebnisse auf dieser Grundlage. Custom Scopes sind Sonderfälle und werden nur nach sorgfältiger Prüfung gewählt.
Der Standard schafft Vergleichbarkeit, aber keine automatische Vollständigkeit. Das Unternehmen muss die richtigen Standorte und Objectives registrieren. Fehler in dieser Auswahl können durch einen formal korrekten Standardtext nicht geheilt werden.
Vom Kundenauftrag zum Schutzobjekt
Die Abgrenzung beginnt mit dem konkreten Produkt oder der Dienstleistung für den Geschäftspartner. Das Team identifiziert, welche vertraulichen Informationen, personenbezogenen Daten oder Prototypen empfangen, erzeugt, verarbeitet und weitergegeben werden. Jedes Schutzobjekt erhält einen Eigentümer und einen Lebenszyklus.
Eine Kundenzeichnung kann beispielsweise per Portal eingehen, in einem Product-Lifecycle-System verarbeitet, für einen Lieferanten exportiert und nach Projektende archiviert werden. Diese Kette verbindet mehrere Organisationseinheiten und technische Dienste. Der Scope muss alle verantworteten Schritte angemessen berücksichtigen.
Die sieben Stationen eines Informationsflusses
- Empfang oder Erzeugung der Information
- Klassifizierung und Zuordnung zu einem Auftrag
- Speicherung in fachlichen und technischen Systemen
- Bearbeitung durch interne oder externe Rollen
- Übertragung zwischen Standorten und Partnern
- Archivierung, Backup und Wiederherstellung
- Löschung, Rückgabe oder kontrollierte Vernichtung
Für jede Station werden Ort, Verantwortlicher, System und Schutzanforderung dokumentiert. Dadurch erscheinen häufig bislang unbeachtete Exportordner, E-Mail-Flüsse und Dienstleister. Der Datenfluss ist zugleich eine gute Grundlage für Interviews und Stichproben.
Locations im Sinne des Assessments verstehen
Eine Location ist nicht nur eine postalische Adresse. Entscheidend ist, wo relevante Prozesse und Ressourcen unter Verantwortung des Teilnehmers betrieben werden. Büros, Entwicklungszentren, Werkstätten, Testflächen oder andere Betriebsstätten können unterschiedliche Rollen im Scope besitzen.
Die Registrierungsdaten müssen zur realen Nutzung passen. Gebäude auf einem Campus werden anhand ENX-Vorgaben und tatsächlicher organisatorischer Grenzen betrachtet. Umzüge, zusätzliche Flächen und neue Standorte benötigen frühzeitige Auswirkungsprüfung.
Homeoffice und mobiles Arbeiten
Beschäftigte verarbeiten Schutzobjekte oft außerhalb registrierter Büroflächen. Mobile Arbeit wird über Prozesse, Geräte, Zugriffe, physische Umgebung und Verhaltensregeln in das ISMS einbezogen. Sie ist nicht automatisch eine eigene registrierte Location, verändert aber die zu prüfenden Ressourcen und Kontrollen.
Der Scope-Workshop klärt, welche Informationen mobil bearbeitet werden dürfen, wie Sichtschutz, Ausdrucke, Gespräche und lokale Speicherung geregelt sind und wie Endgeräte geschützt werden. Technische Konfiguration und Schulungsnachweise stützen die Aussagen. Pauschale Homeoffice-Verbote, die in der Praxis nicht gelten, sind keine belastbare Abgrenzung.
Zentrale IT-Services sichtbar machen
Ein Standort kann seine Identitäten, Endgeräte, Netze, Backups oder Logs durch eine Konzernzentrale betreiben lassen. Diese zentralen Services sind für die Sicherheit des lokalen Scopes relevant. Die Verantwortungsgrenze wird in einem Servicekatalog oder einer RACI-Matrix dokumentiert.
Der Assessor benötigt Nachweise für zentrale Kontrollen und ihre Anwendung am Standort. Dazu gehören Richtlinien, Betriebsberichte und lokale Stichproben. Eine rein organisatorische Aussage „wird zentral gemacht“ ist ohne Leistungsbeschreibung und Evidenz unzureichend.
Shared Service Center und verbundene Unternehmen
Leistungen innerhalb einer Unternehmensgruppe sind nicht automatisch interne Tätigkeiten des Scopes. Rechtliche Einheit, Verantwortung und Vertragsbeziehung müssen verstanden werden. Ein verbundenes Unternehmen kann als Dienstleister auftreten und benötigt klare Sicherheitsanforderungen.
Der Scope-Entscheid dokumentiert, welche Prozesse vom Teilnehmer verantwortet und welche extern erbracht werden. Schnittstellen, Berichtswege, Vorfälle und Änderungsmanagement werden einbezogen. So verhindert die Konzernstruktur blinde Flecken.
Cloud- und SaaS-Dienste einordnen
Cloudrechenzentren werden nicht allein deshalb als eigene Teilnehmerstandorte registriert, weil dort Daten liegen. Für den Scope relevant sind der genutzte Dienst, die verantworteten Konfigurationen, Identitäten, Datenflüsse und Lieferantenbeziehungen. Der konkrete Fall wird anhand der ENX-Scope-Logik und des Vertragsmodells geprüft.
Eine Shared-Responsibility-Matrix zeigt Pflichten von Anbieter und Nutzer. Zertifikate und Berichte des Providers dienen als Evidenz, decken aber die eigene Mandantenkonfiguration nicht ab. Auch Exit, Datenexport und Löschung gehören zum Informationslebenszyklus.
Managed Service Provider und externe Administration
Externe Administratoren besitzen häufig weitreichende Zugriffe auf Systeme im Scope. Das Unternehmen bleibt für Auswahl, Berechtigung, Überwachung und Vertragsanforderungen verantwortlich. Fernzugänge und Supportprozesse werden in den Daten- und Administrationsfluss aufgenommen.
Der Dienstleister benötigt nicht automatisch einen eigenen Platz im registrierten Scope des Kunden. Seine Leistung und die beim Kunden verbleibenden Kontrollen müssen jedoch prüfbar sein. Kritische Unterauftragnehmer und Supportstandorte werden risikobasiert berücksichtigt.
Entwicklungspartner und verlängerte Werkbank
Externe Entwickler können Kundeninformationen auf eigenen Systemen verarbeiten oder über kontrollierte virtuelle Arbeitsplätze zugreifen. Diese Varianten führen zu unterschiedlichen Risiken und Nachweisen. Vertrag, Zugriff, Datenhaltung und Löschung werden deshalb getrennt beschrieben.
Ein Zugriff auf Systeme des Auftraggebers beseitigt nicht alle Lieferantenpflichten. Endgerät, Identität, Arbeitsumgebung und Personalwechsel bleiben relevant. Der Scope-Workshop klärt, welche Organisation welche Kontrolle tatsächlich ausführt.
Prototypen über physische Grenzen verfolgen
Prototypen bewegen sich zwischen Entwicklung, Werkstatt, Testgelände, Logistik und Veranstaltungen. Die zugehörigen Zeichnungen, Fotos und Messdaten folgen teilweise anderen Pfaden als das physische Objekt. Beide Flüsse werden gemeinsam modelliert.
Temporäre Flächen und externe Transporte dürfen nicht erst kurz vor dem Assessment auffallen. Genehmigung, Tarnung, Zugang, Aufnahmeverbote und Rückgabe werden je Station betrachtet. So entstehen Scope und Kontrollen aus dem realen Lebenszyklus.
Datenschutzobjekte sauber zuordnen
Bei Datenschutz-Objectives werden relevante personenbezogene Daten und Verarbeitungstätigkeiten identifiziert. Personal-, Bewerber-, Kunden- oder Telematikdaten können an unterschiedlichen Standorten verarbeitet werden. Datenschutzregister und TISAX-Datenfluss sollten dieselben Verantwortlichen und Systeme zeigen.
Auftragsverarbeiter werden über Vertrag und Leistung einbezogen. Technische Löschung, Zugriffsrechte und Vorfallwege müssen im Scope funktionieren. Eine reine juristische Liste ohne Systembezug ist nicht ausreichend.
Hohe Verfügbarkeit als Scope-Treiber
Verfügbarkeits-Objectives lenken den Blick auf Leistungen, deren Ausfall den Partner erheblich beeinträchtigt. Zentrale Plattformen, Standortverbindungen, Personal und externe Dienste können dadurch relevanter werden. Wiederanlauf und Abhängigkeiten sind nicht auf den primären Anwendungsserver begrenzt.
Eine Business-Impact-Betrachtung identifiziert Zeitkritikalität und Ersatzverfahren. Der Scope bleibt an der Kundenleistung ausgerichtet, erfasst aber die notwendigen Ressourcen. Nicht benötigte Unternehmensbereiche werden nicht allein wegen allgemeiner Wichtigkeit aufgenommen.
Ein Scope-Inventar aufbauen
| Objektart | Mindestangaben | Typische Quelle |
|---|---|---|
| Standort | Adresse, Nutzung, Schutzobjekte, Kontakt | Facility- und ENX-Daten |
| Prozess | Ergebnis, Eigentümer, Partnerbezug | Prozesslandkarte |
| Information | Klassifizierung, Lebenszyklus, Empfänger | Datenfluss und Vertrag |
| Anwendung | Zweck, Betreiber, Daten, Nutzer | Servicekatalog |
| Dienstleister | Leistung, Zugriff, Vertrag, Nachweise | Lieferantenregister |
Das Inventar muss nicht alle Unternehmensassets duplizieren. Es verweist auf führende Quellen und dokumentiert die Scope-Relevanz. Eigentümer bestätigen Vollständigkeit und Aktualität.
Mehrere Standorte in einem Scope bündeln
Ein gemeinsamer Scope bietet ein Assessment-Ergebnis und kann zentrale Prozesse effizient berücksichtigen. Er passt, wenn Governance, Policies und wesentliche Kontrollen gemeinsam gesteuert werden. Lokale Unterschiede müssen dennoch in Stichproben sichtbar bleiben.
Die Vorbereitung bewertet den schwächsten relevanten Standort, nicht nur den Hauptsitz. Lokale Maßnahmenpläne werden vor dem Initial Assessment zusammengeführt. Ein gemeinsamer Scope ist keine Methode, niedrige Reife durch Mittelwerte auszugleichen.
Wann getrennte Scopes sinnvoll sind
Getrennte Scopes können bei unterschiedlichen Kundenanforderungen, Zeitplänen, rechtlichen Einheiten oder stark abweichenden Betriebsmodellen passend sein. Sie ermöglichen gezieltere Vorbereitung und Ergebnisfreigabe. Gleichzeitig können zentrale Prozesse mehrfach relevant werden.
Die Entscheidung berücksichtigt Kosten, Auditaufwand, Ablaufdaten und künftige Nutzung. Eine kurzfristige Teilmenge darf nicht die langfristige Lieferantenstrategie untergraben. Die Gründe werden dokumentiert und regelmäßig überprüft.
Custom Scope nur als begründete Ausnahme
ENX unterscheidet Standard Scope und Varianten eines Custom Scope. Da der Standard für fast alle Teilnehmer vorgesehen und allgemein akzeptiert ist, benötigt eine Abweichung eine klare fachliche Begründung. Vor- und Nachteile werden mit Kunde und Audit Provider geklärt.
Ein Full Custom Scope kann die Anerkennung durch andere Teilnehmer einschränken. Er ist daher kein Werkzeug, um Prüfaufwand beliebig zu reduzieren. Der geschäftliche Nutzen muss die geringere Austauschbarkeit rechtfertigen.
Beispiel: Engineering-Gruppe mit vier Standorten
Eine Gruppe entwickelt Komponenten für mehrere Fahrzeughersteller. Standort A führt Konstruktion und Projektsteuerung durch, Standort B baut Prototypen, Standort C erbringt Softwaretests und Standort D ist reine Vertriebsniederlassung. Identitäten, Endgeräte und Cloudplattformen werden zentral betrieben.
Der Datenfluss zeigt, dass A, B und C Kundeninformationen verarbeiten. Standort D erhält nur freigegebene Produktunterlagen und hat keinen Zugriff auf Projektplattformen. Die zentrale IT bleibt als gemeinsame Leistung relevant, obwohl sie organisatorisch an A angesiedelt ist.
Die Gruppe registriert A, B und C in einem Standard Scope und dokumentiert D als abgegrenzten Bereich mit technischen Zugriffsbeschränkungen. Bei einer späteren Ausweitung der Vertriebsarbeit wird die Entscheidung erneut geprüft. So folgt die Grenze der tatsächlichen Verarbeitung statt der Firmenstruktur.
Grenzen durch technische Kontrollen bestätigen
Ein ausgeschlossener Bereich sollte nicht nur auf einer Folie getrennt sein. Identitäten, Berechtigungen, Netzwerkzugänge und Informationsklassifizierung müssen die Grenze unterstützen. Stichproben prüfen, ob ausgeschlossene Benutzer oder Systeme tatsächlich keinen unzulässigen Zugriff besitzen.
Wo vollständige technische Trennung nicht sinnvoll ist, werden gemeinsame Kontrollen transparent einbezogen. Das ist häufig bei zentralen Plattformen der Fall. Eine ehrliche gemeinsame Abhängigkeit ist besser als ein nicht haltbarer Ausschluss.
Scope und Audit-Provider-Angebot verbinden
Ein Audit Provider kalkuliert auf Basis von Scope ID, Locations, Objectives, Assessment Level und Rahmenbedingungen. Unvollständige Angaben erschweren vergleichbare Angebote. Unternehmen sollten deshalb erst nach dem Scoping-Workshop anfragen.
Ändert sich der Scope nach Beauftragung, können Termine und Aufwand betroffen sein. Wesentliche Unsicherheiten werden vor Vertragsabschluss angesprochen. Der Provider entscheidet nicht die interne Geschäftsgrenze, kann aber Verfahrensfragen klären.
Scope-Änderungen steuern
Neue Standorte, Leistungen, Kunden, Cloudsysteme oder Unternehmenszukäufe können den Scope verändern. Ein festgelegter Trigger verbindet Vertrieb, Architektur, Einkauf und Facility mit dem ISMS. Der Scope Owner bewertet Auswirkungen auf Registrierung und Assessment.
Änderungen werden mit Datum, Grund und Entscheidung dokumentiert. Auch vermeintliche Abgrenzungen benötigen Review. So bleibt die Grundlage über die dreijährige Ergebnislaufzeit belastbar.
Eine Scope-Governance mit klaren Rollen
Der Scope Owner verantwortet Konsistenz und Änderungen, ohne alle Quelldaten selbst zu pflegen. Standortverantwortliche bestätigen lokale Prozesse und Flächen, Service Owner zentrale Dienste und Account-Verantwortliche Kundenanforderungen. Informationssicherheit moderiert und dokumentiert.
Die Geschäftsleitung genehmigt wesentliche Ein- und Ausschlüsse. Ein regelmäßiges Review betrachtet Veränderungen und offene Annahmen. Dadurch wird Scope-Management Teil der Steuerung statt einer einmaligen Registrierungsaufgabe.
Typische Scoping-Fehler
- Nur die Vertragsadresse wird registriert, obwohl andere Standorte Informationen verarbeiten.
- Der Scope folgt dem Organigramm statt dem Informationsfluss.
- Zentrale IT und Shared Services werden als „außerhalb“ behandelt, ohne ihre Wirkung zu prüfen.
- Cloud- und Managed Services gelten pauschal als Verantwortung des Anbieters.
- Homeoffice und mobile Verarbeitung existieren praktisch, aber nicht im Kontrollmodell.
- Prototypendaten und physische Prototypen werden getrennt betrachtet.
- Ein Custom Scope wird nur zur Aufwandsreduktion gewählt.
- Änderungen nach der Registrierung erreichen den Scope Owner nicht.
Die meisten Fehler werden durch Datenflussworkshops und technische Stichproben sichtbar. Eine größere Assetliste allein genügt nicht. Entscheidend sind Verantwortung und Beziehung zur Kundenleistung.
25 Fragen für den Scoping-Workshop
- Welche konkrete Kundenanforderung löst das Assessment aus?
- Welche Objectives sind schriftlich verlangt?
- Welche Produkte oder Leistungen sind betroffen?
- Welche Schutzobjekte werden empfangen oder erzeugt?
- Wo findet die erste Verarbeitung statt?
- Welche Standorte bearbeiten oder speichern die Informationen?
- Welche Beschäftigten arbeiten mobil?
- Welche Anwendungen unterstützen die Leistung?
- Wo werden diese Anwendungen betrieben?
- Welche zentralen Identitätsdienste bestehen?
- Welche Netzwerk- und Sicherheitsdienste sind gemeinsam?
- Welche Cloudanbieter verarbeiten Schutzobjekte?
- Welche Dienstleister besitzen administrativen Zugriff?
- Welche Entwicklungspartner erhalten Informationen?
- Welche physischen Prototypen bewegen sich zwischen Orten?
- Welche Transport- und Veranstaltungsprozesse bestehen?
- Wo liegen Backups und Archive?
- Wie werden Daten gelöscht oder zurückgegeben?
- Welche Bereiche sollen ausgeschlossen werden?
- Welche technische Kontrolle stützt den Ausschluss?
- Sind mehrere Standorte gemeinsam steuerbar?
- Welche lokalen Reifeunterschiede bestehen?
- Ist der Standard Scope verwendbar?
- Wer genehmigt Scope-Änderungen?
- Welcher Prozess erkennt neue Scope-Treiber?
Antworten werden nicht nur protokolliert, sondern mit Quellen verknüpft. Offene Annahmen erhalten Frist und Eigentümer. Nach Klärung bilden sie die Basis für Registrierung und Auditangebot.
Fazit: Der Scope folgt der Schutzverantwortung
Ein belastbarer TISAX Scope entsteht aus Kundenanforderung, Schutzobjekten, Datenflüssen und realer Verantwortung. Standorte sind wichtig, aber nicht ausreichend; zentrale Dienste, mobiles Arbeiten, Cloud und Partner prägen die Sicherheitsleistung. Der Standard Scope erhält die gewünschte Austauschbarkeit.
BlackMount unterstützt bei der Festlegung und Validierung des TISAX Assessment Scopes: von Datenfluss- und Standortworkshops über Shared-Service-Analyse bis zu Registrierungsgrundlage und Audit-Provider-Briefing. Das Ergebnis ist eine prüfbare Grenze ohne verdeckte Abhängigkeiten.
