Zero Trust im Indiengeschäft: Was Sie als Mittelstand von der IT-Welt lernen können
Wie Sie sicherstellen, dass Informationen aus Ihrer indischen Tochtergesellschaft ungefiltert bei Ihnen ankommen.
Die Compliance-Maßnahmen in Ihrer indischen Tochtergesellschaft existieren: Audit Trails, Datenschutzrichtlinien, Arbeitsverträge. Aber die entscheidende Frage ist eine andere: Haben Sie als Stammhaus direkten Zugriff auf diese Informationen? Oder sind Sie darauf angewiesen, dass Ihnen jemand vor Ort einen Report schickt?
Diese Frage stand im Zentrum unseres WBinars „Zero Trust im Indiengeschäft“ am 24. Februar 2026. Was wir dort besprochen haben, welche einfachen IT-Tools Ihnen die Hoheit über wichtige Informationen gewährleisten, fassen wir in diesem Beitrag zusammen und ergänzen es um Hintergründe, die im 45-Minuten-Format keinen Platz hatten.
1. Warum Zero Trust kein IT-Thema ist
Zero Trust stammt aus der IT-Sicherheit. Das Prinzip: Vertraue keinem System automatisch, verifiziere jeden Zugriff. Google hat es 2009 unter dem Namen BeyondCorp eingeführt, das NIST hat es 2020 in der Special Publication 800-207 als Referenzarchitektur standardisiert.
Aber der Kern von Zero Trust ist kein technisches Konzept. Es ist ein Steuerungsprinzip:
- Personenunabhängigkeit: Systeme so bauen, dass sie funktionieren, egal wer kündigt, krank wird oder Informationen zurückhält.
- Verifizierung statt Vertrauen: Nicht davon ausgehen, dass Informationen von selbst kommen. Direkten Zugang sicherstellen.
- Least Privilege: Wissen, wer Zugriff auf was hat und warum. Nicht erforderliche Rechte werden entzogen.
Für den deutschen Mittelstand mit Indien-Tochtergesellschaften bedeutet das: Enterprise-Konzepte wie NIST Zero Trust oder ISO 27001 müssen nicht 1:1 umgesetzt werden. Aber die Prinzipien dahinter lassen sich auf die eigene Organisation übertragen, pragmatisch und kosteneffizient.
2. Die kulturelle Dimension: Warum Kontrolle in Indien erwartet wird
Europäisches Zögern bei Kontrolle wird in Indien nicht als Vertrauen verstanden, sondern als Desinteresse. Wenn Sie nicht nachfragen, signalisieren Sie: „Ist mir egal.“
Das ist keine Provokation, sondern eine kulturelle Realität, die wir bei WB über sieben Standorte und 110+ Mitarbeiter täglich erleben:
- Kontrolle ist unterschiedlich besetzt: In Europa oft negativ (Misstrauen), in Indien normal und erwartet (Interesse).
- Fehlerkultur: Probleme werden eher vertuscht als eskaliert. Gesichtsverlust wiegt schwer. Schlechte Nachrichten kommen zu spät oder gar nicht.
- Politische Antworten: Ja heißt nicht immer „Ja“. „Kein Problem“ heißt nicht, dass es keins gibt.
- „Alles läuft“ ist oft ein Warnsignal: Unsere Erfahrung zeigt: Fehlentwicklungen treten selten plötzlich auf. Sie folgen fast immer demselben Muster.
Das Framing entscheidet: Wenn Sie Ihrem Team erklären, warum Sie bestimmte Leitplanken einführen und wie sie funktionieren, wird Kontrolle nicht als Misstrauen empfunden, sondern als professioneller Standard.
3. Drei Situationen, die Sie vielleicht kennen
Situation 1: Der Buchhalter, der alles weiß
Eine Person administriert TallyPrime (ein ERP-System) allein. Nur sie kennt Passwörter und Abläufe. Reports kommen gefiltert an. Bei WB war die Realität so: Tally-Exports wurden manuell erstellt und per E-Mail nach Deutschland geschickt. Ob die Daten vollständig, unverändert oder aktuell waren, ließ sich nicht überprüfen.
Sofortmaßnahmen: Zweiten Admin-Zugang im Stammhaus einrichten. Passwortmanager einführen. Kontoauszüge direkt von der Bank abrufen, nicht über den Buchhalter. Langfristig: TallyPrime Server mit Edit-Logs und Dual Authorization für Transaktionen über einem bestimmten Schwellenwert.
Situation 2: Die Vertriebstochter und der blinde Fleck CRM
In Vertriebstöchtern entsteht Shadow IT fast automatisch. Vertriebsmitarbeiter exportieren Kundendaten aus dem CRM in lokale Excel-Dateien, speichern sie auf privaten Geräten. Rabatte werden ad hoc vergeben, ohne dokumentierte Freigabe.
Was bei einem WB-Kunden passiert ist: Ein Mitarbeiter hat aus dem CRM eine Kundendatenbank mit allen Kunden eines Bundesstaates exportiert, als Excel gespeichert und lokal bearbeitet. Der Rechner war später nicht mehr verfügbar. Die Kundendaten auch nicht.
Gegenmaßnahme: CRM zentral in M365/SharePoint. Zugriff nur über Security Groups (RBAC). Beim Exit: sofortiger Entzug. Rabattfreigabe ab Schwellenwert nur mit HQ-Genehmigung, automatisiert mit Audit-Trail.
Situation 3: Der plötzliche Personalwechsel
Schlüsselperson kündigt, oft ohne Vorlauf. Keine Vertretung, keine Dokumentation. Passwörter, Kontakte, Prozesswissen: weg. Bei einem Kunden haben wir nach einem solchen Vorfall über die M365-Audit-Logs festgestellt, dass ein Mitarbeiter über Monate nach Verlassen des Unternehmens noch versucht hatte, auf SharePoint-Daten zuzugreifen. Die Cookies waren noch gespeichert.
Key-Person-Risk ist das größte Einzelrisiko im Indiengeschäft. Personenunabhängigkeit ist keine Option, sie ist Pflicht.
4. BLUME: Fünf Hebel für operative Kontrolle
BLUME ist kein theoretisches Framework. Es sind fünf Hebel, die Sie im Prinzip sofort anfassen können:
| Hebel | Prinzip | Beispiel |
|---|---|---|
| B – Ban | Gefährliche Aktionen unterbinden | Cloud-Speicher blockieren, Apps sperren, CRM-Exporte deaktivieren |
| L – Limit | Rechte und Raten begrenzen | Dual-Auth ab Schwellenwert, Least Privilege, max. Dokumentansichten/Stunde |
| U – Usage | Nutzung an Bedingungen knüpfen | Conditional Access: Rolle + Gerät + MFA + Region |
| M – Monitor | Überwachen | Audit-Logs (Purview/Grafana), automatische Alerts bei ungewoehnlichem Verhalten |
| E – Enforce | Durchsetzen | Automatische Policies + regelmäßige Management-Reviews |
Viele dieser Controls sind mit bestehenden Microsoft-365-Lizenzen realisierbar. Power Automate ist in jeder M365-Business-Lizenz enthalten. Sie brauchen kein Enterprise-Budget.
5. Management as Code: Ihre Organisation als Deklaration
Hier wird es spannend für alle, die das Prinzip Infrastructure as Code aus der Softwareentwicklung kennen. Die Grundidee: Anstatt Infrastruktur manuell zu konfigurieren (Server aufsetzen, Firewalls einstellen, Zugänge einrichten), beschreibt man den gewünschten Zustand in einem maschinenlesbaren Dokument. Das System stellt diesen Zustand dann automatisch her.
Beispiel aus der IT-Welt: Ein DevOps-Team beschreibt in einer YAML-Datei, dass der Webserver drei Instanzen haben soll, auf Port 443 lauscht und nur aus dem internen Netzwerk erreichbar ist. Terraform oder Ansible lesen diese Datei und konfigurieren die Infrastruktur automatisch. Ändert sich etwas, ändert man die Datei, nicht den Server.
Übertragen auf Ihre Organisation: Sie beschreiben Ihre Organisationsstruktur, Rollen und Zugriffsrechte einmal zentral. Änderungen werden versioniert, jede Anpassung hinterlässt einen Audit-Trail. Aus dieser zentralen Quelle leiten sich automatisch Zugriffsrechte, Freigabeprozesse und Berichtsstrukturen ab.
| Sie deklarieren | Daraus folgt automatisch |
|---|---|
| Standorte (Delhi, München) | Standort-basierte Policies |
| Rollen (Controller, Sales) | Rollenbasierte Zugriffsrechte (RBAC) |
| Personen (Rolle + Standort) | Zuweisung zu Security Groups |
| Software-Lizenzen | Automatische Provisionierung |
| Gruppen (Finance IN, Sales DE) | Vererbte Rechte in Entra/SharePoint |
Der Vorteil für den Mittelstand: Wenn ein Mitarbeiter das Unternehmen verlässt, werden seine Zugänge automatisch deaktiviert, nicht erst, wenn jemand daran denkt. Wenn ein neuer Mitarbeiter anfängt, bekommt er genau die Rechte, die seine Rolle vorsieht. Und wenn Sie wissen wollen, wer gerade auf welche Systeme Zugriff hat, schauen Sie in Ihre zentrale Berechtigungsmatrix, fragen Sie nicht Ihren lokalen IT-Verantwortlichen.
Großkonzerne nutzen dafür Plattformen wie Okta, SailPoint oder CyberArk. Für KMU reicht oft Microsoft Entra ID mit Security Groups und Conditional Access. Das Prinzip ist dasselbe, die Tooling-Tiefe unterscheidet sich.
6. Was Infrastructure as Code mit Ihrer Indien-Tochter zu tun hat
Warum ist diese Analogie relevant? Weil sie das zentrale Problem löst, das viele KMU mit internationalen Töchtern haben: Wissen, das in Köpfen steckt statt in Systemen.
In der Softwareentwicklung hat Infrastructure as Code (IaC) ein ähnliches Problem gelöst. Früher wusste nur der eine Systemadministrator, wie der Server konfiguriert war. Wenn er kündigte, war das Wissen weg. IaC hat das geändert: Der Zustand wird deklariert, versioniert und ist jederzeit reproduzierbar, unabhängig von einzelnen Personen.
Die Parallele zum Indiengeschäft ist offensichtlich:
| IT-Welt (IaC) | Ihre Organisationen |
|---|---|
| Server-Konfiguration in Code | Rollen und Rechte in zentralem System |
| Nur der Admin weiß, was konfiguriert ist | Nur der lokale Buchhalter weiß, wer Zugriff hat |
| Änderungen werden versioniert (Git) | Änderungen werden im Audit-Trail dokumentiert |
| Zustand ist jederzeit reproduzierbar | Onboarding/Offboarding läuft automatisch |
| Kein Single Point of Failure | Kein Key-Person-Risk |
Das ist keine Zukunftsmusik. Plattformen wie Drata, Vanta oder Kertos automatisieren Compliance-Nachweise für Standards wie SOC 2 oder ISO 27001 bereits heute. Für den produzierenden Mittelstand sind das oft Overkill, aber die Denkrichtung ist dieselbe: Deklarieren statt improvisieren.
7. Was wir bei WB konkret gemacht haben
ERP-Migration: Vom Blindflug zum direkten Zugriff
Finanzdaten lagen nur lokal, ein einziger Nutzer hatte Zugang. Wir haben den TallyPrime-Server migriert, Edit-Logs aktiviert und ein Rechtekonzept mit Dual Authorization eingeführt. Ergebnis: Das HQ hat jederzeit direkten Zugriff, ohne jemanden fragen zu müssen.
Code-of-Conduct-Prüfung: Die 37,7-Prozent-Lücke
Im Oktober 2025 haben wir einen Abgleich gemacht: 106 lizenzierte M365-User gegenüber den Code-of-Conduct-Signaturen. Ergebnis: 40 von 106 Usern hatten den Code of Conduct nicht unterschrieben, darunter Abteilungsleiter und der Managing Director Indien. Das erfuhr man nur, weil aktiv geprüft wurde. Niemand vor Ort hatte es gemeldet.
Audit-Forensik: Logs als Beweismittel
Bei einem Kunden gab es Verdacht auf Datenabfluss. Durch forensische Aufbereitung der M365-Audit-Logs konnten wir eine lückenlose Beweiskette erstellen, die eine Strafanzeige in zwei Ländern unterstützte. Die Daten waren nur deshalb verfügbar, weil die Systeme vorher richtig konfiguriert waren.
Rabattfreigabe: Governance als Produktivitätsgewinn
Früher liefen Rabattfreigaben per E-Mail, unstrukturiert, ohne Audit-Trail. Mit einem Power-Automate-Workflow dauert der Prozess jetzt drei Stunden statt drei Tage. Rabatt unter 5 Prozent wird automatisch genehmigt. Darüber geht es an den Country Manager. Ab 15 Prozent ans HQ. Alles protokolliert, alles nachvollziehbar.
8. Wo stehen Sie? Vom Sales Office bis zur Software-Firma
Der Schutzbedarf hängt von Ihrer Komplexität ab. Nicht jeder braucht alles, aber jeder braucht die Basics:
| Gering: Sales Office | Mittel: Produktion | Hoch: Software | |
|---|---|---|---|
| Typisch | Rein M365 + Cloud-CRM, kein lokaler Server | Fertigung, TallyPrime, ERP lokal, OT-Netzwerk | SaaS-Produkt, Code-Repos, SOC 2 nötig |
| Governance | Entra ID + Cond. Access, MFA, DLP auf SharePoint | Legacy-Anbindung (Tailscale), Netzwerk-Segmentierung | Drata/Vanta, Code-Review-Policies, Monitoring |
| Aufwand | Niedrig: M365-Bordmittel | Mittel: Legacy braucht Integration | Höher: durch Automatisierung skalierbar |
BLUME und Management as Code gelten für alle drei Stufen. Der Unterschied liegt in der Tooling-Tiefe, nicht im Prinzip.
9. Typische Hindernisse und wie Sie diese überwinden
| Hindernis | Gegenmaßnahme |
|---|---|
| Das wirkt wie Misstrauen | Standard: Kontrolle wird in Indien erwartet. Framing entscheidet. |
| Widerstand vor Ort | Schrittweise, Quick Wins, Team einbinden. Alternativen bereitstellen. |
| Legacy nicht anbindbar | Tailscale/Cloudflare + Cloud-IAM. Auch alte Systeme lassen sich schützen. |
| Zu teuer oder zu aufwändig | Power Automate ist in M365 enthalten. Automatisierung senkt Kosten. |
| Shadow IT durch fehlende Alternativen | Genehmigte Tools mit vererbten Rechten. Wer keine Alternativen bietet, darf sich über Schatten-IT nicht wundern. |
10. Drei Fragen, die Sie diese Woche beantworten sollten
1. Ist Ihr HQ der Single Point of Truth?
Werden Rechte zentral deklariert? Test: Fordern Sie die Berechtigungsmatrix an. Wenn sie nicht innerhalb einer Woche vorliegt, ist das bereits eine wichtige Information.
2. Greifen alle fünf BLUME-Hebel?
Ban, Limit, Usage, Monitor, Enforce. Gehen Sie jeden Buchstaben durch. Wo haben Sie Lücken?
3. Wo stehen Sie im Komplexitätsspektrum?
Cloud-only, Produktion oder Software? Daraus ergibt sich, welche Tools Sie brauchen und welche Sie vermutlich schon haben.
Ihre drei nächsten Schritte
- Diese Woche: Prüfen Sie Ihren direkten Systemzugang. Können Sie heute auf die Finanzdaten Ihrer Indien-Einheit zugreifen, ohne jemanden zu fragen?
- Diesen Monat: Führen Sie einen BLUME-Check durch und automatisieren Sie einen Prozess, zum Beispiel die Rabattfreigabe.
- Dieses Quartal: Erstellen Sie eine Berechtigungsmatrix und bestimmen Sie Ihre Komplexitätsstufe. Daraus wird Ihre Governance-Roadmap.
Kostenfreier India Governance Health Check
Wenn Sie bei den Fragen gemerkt haben, dass Sie unsicher sind: Das ist normal. Wir bieten ein kostenfreies 30-minütiges Erstgespräch an, ein ehrliches Feedback und mit konkreten Empfehlungen.
Kontakt: Felix Giessmann | giessmann@wamser-batra.de
Quellen und weiterführende Links
- NIST SP 800-207: Zero Trust Architecture (2020)
- Microsoft Learn: Zero Trust security in Azure
- Google BeyondCorp: A New Approach to Enterprise Security (2014)
- CISA Zero Trust Maturity Model v2.0 (2023)
- ISO/IEC 27001:2022 – Informationssicherheits-Managementsysteme
- HashiCorp: Infrastructure as Code in 4 Flavors (terraform.io)
Dieser Beitrag basiert auf dem WBinar „Zero Trust im Indiengeschäft“ vom 24. Februar 2026. Felix Giessmann ist Projektmanager Digital Processes & IT bei Dr. Wamser + Batra GmbH. Er koordiniert IT-Themen über sieben Standorte in Indien und übersetzt Enterprise-Frameworks in KMU-taugliche Lösungen.
