Die meisten ISO/IEC-27001:2022-Checklisten sind plattformneutral geschrieben, wodurch sie übersehen, was in Apple-Hardware bereits eingebaut ist — und was trotzdem noch konfiguriert und dokumentiert werden muss. Das hier ist ein praktischer Startpunkt, plus ein genauerer Blick auf Apples On-Device-KI-Modell und warum das für eure Risikolage relevant ist, nicht nur heute, sondern auch in Zukunft.
Ein Startpunkt — eine echte Gap-Analyse bildet jede Kontrolle ab, aber hier haben Apple-first-Unternehmen am häufigsten Lücken.
Ist Verschlüsselung im Ruhezustand tatsächlich flottenweit durchgesetzt (FileVault per MDM-Richtlinie, nicht einzelnen Nutzern überlassen), und ist das Schlüsselmanagement dokumentiert — nicht nur „die Geräte sind verschlüsselt"?
Werden Sicherheits-Basiskonfigurationen (Gatekeeper, SIP, Firewall, Update-Richtlinie) zentral über MDM durchgesetzt und überwacht, mit Drift-Erkennung — oder einmal beim Kauf eingestellt und nie wieder geprüft?
Wenn Mitarbeitende Drittanbieter-KI-Tools mit Unternehmensdaten nutzen, ist das dokumentiert und risikobewertet wie jeder andere Cloud-Dienst auch? Diese Domäne haben die meisten Unternehmen noch nicht nachgeholt.
Wissen Mitarbeitende tatsächlich, welche KI-Tools für vertrauliche Daten freigegeben sind und welche nicht — oder wird das eher angenommen als dokumentiert und geschult?
Was bereits in der Hardware steckt, und was trotzdem noch konfiguriert und belegt werden muss.
Ein separater Co-Prozessor in jedem Apple-Silicon-Mac und -iPhone, der Verschlüsselungsschlüssel und biometrische Daten isoliert vom Hauptprozessor verarbeitet — relevanter Nachweis für kryptografische Kontrollanforderungen, muss aber trotzdem als Teil eures ISMS dokumentiert werden, nicht nur vorausgesetzt.
Volldatenträgerverschlüsselung ist in macOS eingebaut, aber ISO 27001 verlangt den Nachweis, dass sie konsequent durchgesetzt wird, nicht optional ist. Mosyle-MDM-Richtliniendurchsetzung macht daraus eine auditierbare Kontrolle statt nur ein Feature.
Code-Signing-Prüfung, eingebaute Malware-Signaturerkennung und Schutz vor unautorisierter Systemänderung — alles nativ in macOS, gemappt auf eure Annex-A-Kontrollen zu Malware-Schutz und System-Härtung.
Supervised Enrollment, durchgesetzte Konfigurationsprofile und eine Echtzeit-Geräteinventur — genau der Nachweis zu Asset-Management und Zugriffskontrolle, den ein Auditor tatsächlich sehen will.
Apples Ansatz für KI-Funktionen (Apple Intelligence) ist darauf ausgelegt, Anfragen wo immer möglich direkt auf dem Gerät zu verarbeiten, mithilfe der Neural Engine in Apple Silicon — die Daten verlassen das Gerät nicht. Für Anfragen, die tatsächlich mehr Rechenleistung brauchen, leitet Apple sie an Private Cloud Compute weiter: Apples eigene Server, die gezielt so gebaut sind, dass Apple selbst nicht auf die verarbeiteten Daten zugreifen kann, mit keiner Datenspeicherung nach Abschluss der Anfrage, und unabhängige Sicherheitsforscher können die tatsächlich laufende Server-Software einsehen, um das zu verifizieren. Für ein ISO-27001-ISMS ist das konkret relevant: Jedes Mal, wenn Mitarbeitende vertrauliche Unternehmensdaten in ein Drittanbieter-KI-Tool einfügen, ist das ein Cloud-Dienst-Risiko (A.5.23), das ihr dokumentieren, bewerten und kontrollieren müsst. Ein Geräte- und Plattform-KI-Modell, das die meiste Verarbeitung lokal hält — und beim Rest architektonisch transparent ist —, verkleinert diese Risikofläche spürbar, ohne dass ihr bei jedem neuen KI-Feature eine neue Richtlinie schreiben müsst. Und da Apple über aufeinanderfolgende Hardware-Generationen hinweg immer mehr Fähigkeiten auf das Gerät verlagert, wird diese Fläche eher kleiner als größer — ein seltener Fall, in dem sich der compliance-relevante Trend tatsächlich zu eurem Vorteil entwickelt.
Sie nimmt euch einen Teil der manuellen Konfigurationsarbeit ab — Secure Enclave, FileVault, Gatekeeper und System Integrity Protection bieten von Haus aus eine starke Hardware- und Betriebssystem-Sicherheitsbasis —, aber die Zertifizierung erfordert weiterhin das vollständige ISMS: dokumentierte Richtlinien, Risikobewertungen, Zugriffskontrollprozesse und den Nachweis, dass Kontrollen konsequent durchgesetzt werden, nicht nur technisch möglich sind. Apple-Hardware erleichtert mehrere Annex-A-Kontrollen; sie ersetzt nicht das Managementsystem drumherum.
Zunehmend ja. Auditoren und Assessoren fangen an zu fragen, wie Unternehmen die Nutzung generativer KI-Tools mit vertraulichen Daten durch Mitarbeitende kontrollieren — das fällt unter Cloud-Dienst-Sicherheitskontrollen (A.5.23), unabhängig davon, ob eure ISMS-Dokumentation KI explizit erwähnt. Eine Plattform, bei der KI-Verarbeitung größtenteils on-device bleibt und bei der der Cloud-Fallback (Private Cloud Compute) architektonisch so gebaut ist, dass er selbst für den Plattformanbieter unzugänglich ist, gibt euch eine deutlich einfachere Antwort auf diese Frage als das Senden von Daten an einen generischen Drittanbieter-KI-Dienst.
Die TISAX-Checkliste richtet sich speziell an Automotive-Zulieferer, die sich auf ein TISAX-Assessment vorbereiten (VDA-ISA-Katalog, OEM-getriebene Anforderung). Diese hier ist für jedes Apple-first-Unternehmen, das aus eigenem Antrieb eine ISO/IEC-27001:2022-Zertifizierung anstrebt — ein breiterer, international anerkannter Standard, der sich mit TISAX stark überschneidet, aber nicht identisch ist.
Eine Beratung, die die tatsächliche ISO/IEC-27001:2022-Lead-Auditor-Qualifikation hält und echte Gerätemanagement-Expertise mitbringt, statt eine generalistische Compliance-Boutique, die Apple-Hardware als Nebensache behandelt. JF Agency hält beides — ISO/IEC-27001:2022-Lead-Auditor-Zertifizierung und Mosyle-Certified-Administrator-Status —, sodass Gap-Analyse, ISMS-Dokumentation und Mosyle-Richtliniendurchsetzung von demselben Team kommen, nicht zwischen zwei Anbietern aufgeteilt sind.
Gap-Analyse, ISMS-Aufbau und Zertifizierungsberatung.
Mobile Device Management für eure Apple-Flotte.
Was ihr vor eurem TISAX-Assessment prüfen solltet.
Risikomanagement, ISMS und Zero-Trust-Architektur.