Wann das NZISM ein deutsches Unternehmen trifft: Betrieb im Auftrag, Vereinbarungen über eingestufte Informationen, Outsourcing, Abweichungsverfahren und Nachweise gegenüber dem Kunden

Problem in der Praxis

Deutsche Anbieter treffen das NZISM meist in der Ausschreibung oder im Vertragsentwurf eines neuseeländischen Ministeriums oder einer Behörde: "Der Auftragnehmer erfüllt das NZISM." Oft folgt die Frage nach einem "NZISM-Zertifikat". Beides führt in die Irre. Das NZISM verpflichtet als Handbuch zunächst die Regierungsstelle, und ein Verfahren, mit dem sich ein Unternehmen als Ganzes für das NZISM zertifizieren lassen könnte, beschreibt es nicht. Zertifizierung und Akkreditierung beziehen sich im NZISM auf Systeme und zugehörige Dienste, und die Entscheidung über den Betrieb liegt bei der Accreditation Authority des Kunden.

Daraus folgen drei typische Fehlplanungen. Erstens wird zugesagt, "alle Controls" umzusetzen, ohne Systemumfang und Einstufung zu klären. Zweitens wird eine vorhandene ISO/IEC-27001-Zertifizierung oder ein SOC-2-Bericht als vollständiger Nachweis angeboten, obwohl das NZISM selbst sagt, dass kein einzelnes Schema seine Anforderungen vollständig abdeckt. Drittens wird übersehen, dass Leistungen aus Deutschland oder mit nicht neuseeländischem Personal an Grenzen stoßen können, sobald eingestufte Informationen, Freigabevermerke oder der Vermerk NZEO (New Zealand Eyes Only) im Spiel sind.

CISO-Einordnung

Was das NZISM selbst zur Verbindlichkeit sagt

Nach NZISM 1.2.6 ist die Befolgung des NZISM nicht gesetzlich vorgeschrieben; die Controls könnten durch Gesetz oder Kabinettsanweisung für Ministerien und Regierungsstellen verbindlich gemacht werden (Einzelheiten und gesperrte Quellen in nzism-001). Die Controls selbst sind fast durchweg an Regierungsstellen gerichtet. Für ein deutsches Unternehmen ist deshalb jede Aussage des NZISM über "agencies" eine Beschreibung dessen, was der Auftraggeber verlangen muss oder soll, und keine eigene gesetzliche Pflicht. Verbindlich für das Unternehmen wird nur, was Vertrag oder Vereinbarung übernehmen.

Konstellationen für deutsche Unternehmen

Betrieb im Auftrag. Nach NZISM 1.2.3 gilt das NZISM für Informationen und Systeme, die von oder im Auftrag der in den Anhängen des Ombudsmen Act 1975 und des Official Information Act 1982 genannten Regierungsstellen betrieben werden. Welche Stellen dort genannt sind, liegt dem Track nicht vor; ob ein bestimmter Kunde dazugehört, ist bei ihm zu erfragen. Das NZISM zählt zum Informationssystem ausdrücklich zugehörige Dienste wie Telekommunikation oder Cloud (1.1.34), der System Owner der Regierungsstelle bleibt für den Gesamtbetrieb einschließlich ausgelagerter Dienste verantwortlich (1.1.39, 3.4.3), und die Akkreditierung umfasst auch ausgelagerte Dienste (4.4.1). Nach 5.8.3 bleiben Risikoeigentum und Verantwortlichkeit bei der Regierungsstelle, auch wenn Aufgaben ausgelagert sind. Zum Zielpublikum gehören nach 1.1.9 ausdrücklich Personen, die für eine Regierungsstelle tätig sind ("contracted to"), und Dienstleister.

Formale Vereinbarung über eingestufte Informationen. Ebenfalls nach 1.2.3 gilt das NZISM für Informationen und Systeme, die von oder im Auftrag von Organisationen betrieben werden, die mit der neuseeländischen Regierung eine formale Vereinbarung über den Zugang zu eingestuften Informationen geschlossen haben. Erfasst sein kann deshalb sowohl ein deutsches Unternehmen, das selbst eine solche Vereinbarung geschlossen hat, als auch ein Dienstleister, der Systeme im Auftrag einer solchen Organisation betreibt, ohne selbst Partei der Vereinbarung zu sein. Ziel des Abschnitts 2.2 ist, dass Nichtregierungsorganisationen, die eingestufte Informationen handhaben, dieselben Schutzmaßnahmen umsetzen wie Regierungsstellen (2.2.1). Auftragnehmer können nach der Begründung in 2.2.5 eingestufte Informationen erhalten, wenn ihre Systeme für die entsprechende Einstufung akkreditiert sind; Auftragnehmer und alle Beschäftigten mit Zugang zu den eingestuften Systemen müssen dafür für die Stufe der verarbeiteten Informationen freigegeben sein ("cleared to the level"). Was das heißt, hängt nach Abschnitt 9.2 an der Einstufung, denn Neuseeland kennt danach zwei Verfahren: Für CONFIDENTIAL und höher ist ein förmliches Überprüfungsverfahren (vetting) für eine National Security Clearance nötig (9.2.7), und ohne abgeschlossene Überprüfung und erteilte Clearance darf kein Zugang zu solchen Systemen oder Informationen gewährt werden (MUST NOT, 9.2.13). Für RESTRICTED und darunter sind Autorisierungen, Sicherheitsprüfungen und begleitende Unterweisungen Teil der Einstellungs- und Einarbeitungsprozesse der Regierungsstelle und werden durch eine förmliche Genehmigung und eine unterschriebene Bestätigung des Beschäftigten belegt (9.2.8). Wo das NZISM den Begriff security clearance verwendet, meint es eine von einer neuseeländischen Regierungsstelle erteilte National Security Clearance; ausländische Staatsangehörige können sie erhalten, wenn die erkannten Risiken gemindert werden können (9.2.3). Die für den Zugang zu einem System nötigen Autorisierungen, Clearances und Unterweisungen muss die Stelle im System Security Plan festlegen (MUST, 9.2.10), und zu den Nutzergruppen, deren Zugangsvoraussetzungen zu dokumentieren sind, zählt die Begründung ausdrücklich Auftragnehmer. Wie die Prüfungen für RESTRICTED und darunter beim Personal eines Auftragnehmers ablaufen, regelt das NZISM nicht ausdrücklich; das ist mit dem Kunden zu klären. Inhalt solcher Vereinbarungen und das Überprüfungsverfahren regeln nicht das NZISM, sondern die nicht vorliegenden Protective Security Requirements (PSR) und die Vereinbarung selbst.

Outsourcing von IT-Diensten. Abschnitt 2.2 versteht unter Outsourcing die Beauftragung einer externen Stelle mit wesentlichen Geschäftsfunktionen und -prozessen, die die Regierungsstelle auch selbst erbringen könnte; Outsourcing kann erhöhte und zusätzliche Risiken bringen und verlangt deshalb mehr Prüfung, nachweisbare Governance und höhere Assurance vor Vertragsschluss (2.2.5). Bezogene Leistungen wie Strom, Wasser, Gebäudeunterhalt, Büromaterial und Telekommunikation brauchen nach dem NZISM keine Akkreditierung und keine Prüfung durch Dritte; dort genügt die übliche vertragliche Sorgfaltsprüfung. Telekommunikation nennt das NZISM an anderer Stelle allerdings auch als ausgelagerten Dienst (1.1.39, 3.4.3, 5.8.3); wie eine konkrete Leistung einzuordnen ist, entscheidet der Kunde. Cloud Computing ist nach 2.2.3 eine Form des Outsourcing, und die Outsourcing-Anforderungen gelten für Cloud-Anbieter gleichermaßen; Einzelheiten zur Cloud behandelt nzism-005. Für das Outsourcing trägt Abschnitt 2.2 vier Aussagen:

• Beauftragt eine Regierungsstelle die Industrie mit IT-Diensten und -Funktionen außerhalb ihrer Räume (off-site), muss sie die Systeme des Auftragnehmers mindestens nach demselben Mindeststandard akkreditieren wie ihre eigenen (MUST). Nach dem NZISM kann das über einen Prüfbericht eines Dritten nach ISAE 3402 (Assurance Reports on Controls at a Service Organisation) erreicht werden.
• Solche Dienste soll sie nicht in Ländern beauftragen, mit denen Neuseeland kein multilaterales oder bilaterales Sicherheitsabkommen zum Schutz eingestufter Informationen der neuseeländischen Regierung hat (SHOULD NOT); im Zweifel soll der CISO der Stelle konsultiert werden. Das NZISM nennt keine Länder; in der Begründung hält es fest, dass es für Abkommen über Informationsaustausch keine einzelne Liste oder Quelle gibt (2.2.5).
• IT Security Manager (ITSM) der Stelle sollen vom IT-Dienstleister unabhängig sein, und der Dienstleister soll eine zentrale Ansprechstelle für alle Fragen der Informationssicherheit benennen (SHOULD, 2.2.6).
• Die Stelle soll ein Programm zur Steuerung der für off-site IT-Dienste akkreditierten Auftragnehmer aufbauen (SHOULD, 2.2.7).

Weitere Anforderungen an Lieferanten und Unterauftragnehmer stehen in Abschnitt 12.7 (Lieferkette) und werden im Track in nzism-004 behandelt.

Neuseeländische Tochter. Eine Tochtergesellschaft, die keine Regierungsstelle ist, keine formale Vereinbarung über eingestufte Informationen hat und Systeme weder im Auftrag einer Regierungsstelle noch im Auftrag einer Organisation mit einer solchen Vereinbarung betreibt, gehört nach 1.1.2 zur Privatwirtschaft, die zur Nutzung des NZISM nur ermutigt wird. Arbeitet sie für Regierungsstellen oder für eine Organisation mit formaler Vereinbarung, gelten für sie die Konstellationen oben. Ob sie aus anderem neuseeländischem Recht Sicherheitspflichten hat, beantwortet das NZISM nach 1.2.13 nicht umfassend und dieser Track nicht.

Ausländische Staatsangehörige und Zugriff aus dem Ausland. Für Informationen mit dem Vermerk NZEO sind die Grenzen hart: Systeme mit NZEO-Informationen müssen jederzeit unter der Kontrolle eines neuseeländischen Staatsangehörigen bleiben, der für die neuseeländische Regierung arbeitet (MUST, 4.4.11), ausländische Staatsangehörige dürfen auf Systeme mit ungeschützten NZEO-Informationen keinen Zugang haben, ebenso wenig auf Systeme, in denen NZEO-Informationen durch Controls vor ihnen abgeschirmt sind, jeweils einschließlich abgeordneter ausländischer Staatsangehöriger (MUST NOT, 9.2.15), und der Zugriff auf NZEO-Informationen von Systemen und Einrichtungen aus, die nicht allein unter Kontrolle der neuseeländischen Regierung und neuseeländischer Staatsangehöriger stehen, ist ausgeschlossen (MUST NOT, 16.2.7). Bei Informationen mit Freigabevermerken nach Staatsangehörigkeit dürfen ausländische Staatsangehörige nur auf das zugreifen, was für ihr Land freigegeben ist (MUST NOT, 9.2.16). Für sonstige eingestufte Informationen soll die Stelle den Zugriff von solchen Systemen und Einrichtungen aus nicht erlauben, es sei denn, ein multilaterales oder bilaterales Sicherheitsabkommen besteht (SHOULD NOT, 16.2.7). Welche Markierungen im Einzelnen als eingestuft gelten, ergibt sich aus dem nicht vorliegenden Klassifizierungssystem der PSR.

Must, Should und das Abweichungsverfahren aus Sicht eines Dienstleisters

Das NZISM verlangt nicht, jede Control auf jedes System anzuwenden. Die Regierungsstelle bestimmt bei der Entwicklung eines Systems dessen Umfang und die anwendbaren Controls (1.1.41). Für Controls außerhalb dieses Umfangs gilt das Abweichungsverfahren nicht; fällt eine Control in den Umfang und wird trotzdem nicht umgesetzt, muss die Stelle das Verfahren durchlaufen (1.1.42). Für den Dienstleister folgt daraus: Der Systemumfang ist eine Entscheidung des Kunden, die er schriftlich braucht.

Baseline-Controls (MUST, MUST NOT). Ihre Anwendung oder Unterlassung ist wesentlich, außer die Control ist für das System nachweislich nicht relevant (1.1.45); sie gehen den SHOULD-Controls vor (1.1.46). Die Gründe für eine Nichtanwendung müssen der Accreditation Authority (der Stelle, die den Betrieb des Systems formal freigibt und die Risiken annimmt) im Zertifizierungsverfahren klar dargelegt werden, bevor eine exception genehmigt wird (1.1.46). Ein System Owner, der eine Dispensation (Befreiung) von einer Baseline-Control anstrebt, muss sie von seiner Accreditation Authority erhalten (1.1.64), und er muss dafür eine Risikobewertung der Regierungsstelle erstellen, die unter anderem die Gründe, die Auswirkungen auf eigene, ressortübergreifende oder gesamtstaatliche (All-of-Government) Systeme, die Ersatzmaßnahmen und ihre Stärke, das Restrisiko und einen Termin zur Überprüfung der Entscheidung festhält (1.1.65). Kann eine Control nicht unmittelbar umgesetzt werden, müssen geeignete Ersatzmaßnahmen (compensating controls) gewählt werden, und die Accreditation Authority kann einen waiver oder eine exception von einer bestimmten Anforderung gewähren, wenn das Restrisiko im Risikoappetit der Regierungsstelle liegt (Tabelle in 1.1.25). Das NZISM kennt zwei Formen der Befreiung: den waiver, der nur kurzfristig gilt und voraussetzt, dass die volle Erfüllung oder Ersatzmaßnahmen innerhalb einer von der Accreditation Authority gesetzten Zeit erreicht werden, wobei die volle Akkreditierung erst nach Erfüllung aller Bedingungen erteilt werden kann (1.1.23), und die exception, die für die Laufzeit der Akkreditierung oder eine kürzere Zeit gilt (1.1.24). Manche Baseline-Controls kann eine Regierungsstelle nach dem NZISM nicht einzeln risikobasiert behandeln, ohne ressortübergreifende, gesamtstaatliche oder internationale Systeme zu gefährden; für MUST- und MUST-NOT-Controls bei eingestuften Systemen und Informationen hält die Begründung in 1.1.64 allgemein fest, dass Regierungsstellen sie nicht wirksam einzeln risikobasiert behandeln können, ohne die eigene, ressortübergreifende oder gesamtstaatliche Informationssicherheit zu gefährden (siehe auch die Tabelle in 1.1.25).

Empfohlene Praxis (SHOULD, SHOULD NOT). Für die Nichtanwendung kann es triftige Gründe geben, etwa fehlende Relevanz, eine in der Stelle nicht vorhandene Technik oder eine gleich starke Ersatzmaßnahme (1.1.47). Die Stelle muss aber festhalten und formal anerkennen, dass eine Nichtanwendung ohne gebührende Prüfung das Restrisiko erhöhen kann, und dieses Restrisiko muss von der Accreditation Authority anerkannt werden (1.1.48, 1.1.69); nach der Tabelle in 1.1.25 wird die Nichtanwendung förmlich festgehalten, Ersatzmaßnahmen werden nach Bedarf gewählt, und dass das Restrisiko im Risikoappetit der Stelle liegt, wird anerkannt und von der Accreditation Authority förmlich bestätigt. Die Abwägung ist prüfbar zu dokumentieren (1.1.49).

Konsultation, Überprüfung, Aufzeichnung. Verarbeitet ein System eingestufte Informationen einer anderen Regierungsstelle, muss diese vor einer Abweichung vom Klassifizierungssystem konsultiert werden; stammen sie von einer ausländischen Regierung, muss diese vor einer Abweichung von NZISM-Controls konsultiert werden (MUST, 1.1.66). Ist ein System mit mehreren Regierungsstellen verbunden oder Teil eines gesamtstaatlichen Systems, müssen die interessierten Parteien vor einer Abweichung von Baseline-Controls formal konsultiert werden (MUST, 1.1.67); dazu können nach der Begründung auch wichtige Dienstleister wie Cloud-Anbieter gehören. Entscheidungen über Abweichungen sollen mindestens jährlich überprüft werden (SHOULD, 1.1.68), und die Risikobewertung und die Entscheidungen über Abweichungen von Baseline-Controls sind aufzubewahren (MUST, 1.1.69). Nach 1.1.51 bis 1.1.53 genügt es nicht, Risiken nur anzuerkennen: Bei Altsystemen soll die Risikobewertung Ersatzmaßnahmen benennen, und wo eine Stelle nicht sofort alle Controls umsetzen kann, sieht gutes Risikomanagement einen Zeitplan für die Umsetzung vor.

Wer die Accreditation Authority ist. In der Regel der Leiter der Regierungsstelle (Agency Head) für Systeme bis einschließlich RESTRICTED, mit der Möglichkeit, die Befugnis an ein Mitglied der Leitung zu delegieren, wobei er verantwortlich bleibt (1.1.13, 1.1.14). Für multinationale und ressortübergreifende Systeme wird sie durch formale Vereinbarung der Beteiligten bestimmt (1.1.16), für NZEO und aus Gründen der nationalen Sicherheit abgeschottete Informationen ist es der Director-General des GCSB (1.1.17), ebenso bei High Assurance Cryptographic Systems (1.1.64). Die Zuordnung im Einzelnen behandelt nzism-003. In allen Fällen ist die Accreditation Authority nach 1.1.15 mindestens eine leitende Führungskraft einer Regierungsstelle, die die Risiken für die Stelle annimmt. Für den Dienstleister heißt das: Er kann Abweichungen nicht selbst genehmigen, sondern nur begründen, Ersatzmaßnahmen anbieten und belegen.

Zusätzliche Controls, die das NZISM nicht vorsieht, sind nach 1.1.66 willkommen, solange sie den NZISM-Controls nicht widersprechen.

Nachweise gegenüber dem Kunden

Den Rahmen für Nachweise setzt Abschnitt 5.8 (Independent Assurance Reports). Die Regierungsstelle muss durch eine Risikobewertung bestimmen, welche Art und welches Maß unabhängiger Assurance sie für Zertifizierung und Akkreditierung braucht (MUST, 5.8.61). Kann sie die Abläufe des Dienstleisters nicht unmittelbar prüfen, soll sie unabhängige Assurance-Berichte einholen, und sie soll einschlägige Berichte und Zertifizierungen des Dienstleisters für Risikobewertung und Zertifizierung heranziehen, etwa als Beleg für die Wirksamkeit von Controls und für Abhilfepläne (SHOULD, 5.8.61). Die Ergebnisse muss sie in ihr Zertifizierungsverfahren einbeziehen, um das Restrisiko und die nötigen Controls zu verstehen (MUST, 5.8.62), und nach der Begründung in 5.8.62 ist es wichtig, einzelne Berichte mit anderen Berichten und unabhängigen Zertifizierungen abzugleichen.

Das NZISM beschreibt die üblichen Formen ohne Rangfolge:

• Attestierungsberichte nach anerkannten Standards von Berufsorganisationen, vor allem ISAE 3402 und für Prüfungen in Neuseeland ISAE (NZ) 3402 oder ISAE (NZ) 3000, für US-Anbieter SSAE 16, sowie die SOC-Berichte (5.8.6, 5.8.10 bis 5.8.30). Ein Type-1-Bericht betrifft einen Zeitpunkt und ist nach dem NZISM von begrenztem Nutzen, weil er die Wirksamkeit im Betrieb nicht erfasst; ein Type-2-Bericht prüft die Controls über einen Zeitraum von mindestens sechs Monaten (5.8.15 bis 5.8.17). Die SOC-Berichte sind nach 5.8.30 auf die Bedürfnisse der Dienstleister selbst zugeschnitten und nicht dafür entworfen, Kunden Assurance zu geben; ein SOC-3-Bericht ist zur allgemeinen Veröffentlichung bestimmt und enthält statt der detaillierten Beschreibung der Prüfhandlungen eine zusammenfassende Beurteilung.
• Direkte Prüfungen ohne Attestierungsstandard, etwa nach ISO 2700x, COBIT, NIST oder Kriterien der Cloud Security Alliance (5.8.7).
• ISO/IEC-27001-Zertifizierung als weiteres Mittel, Assurance über Dienstleister zu gewinnen (5.8.34).
• CSA STAR; eine Selbstbewertung liefert nach dem NZISM nicht notwendig substanzielle Assurance (5.8.36).

Zwei Grenzen sind für das Angebot entscheidend. Kein einzelnes Assurance-Schema deckt nach 5.8.61 alle Anforderungen des NZISM ab, und keines der gängigen ausgereiften Schemata deckt spezifische Regierungsanforderungen und den Umgang mit Official Information ab, etwa die personelle Sicherheit mit Überprüfungen von Nutzern und Administratoren oder Fragen der Datenhoheit. Und die Assurance hängt am Vertrag: Nach 5.8.8 und 5.8.9 speist sie sich auch aus den Vertragsbedingungen, und ohne vertragliche Verankerung kann die Regierungsstelle möglicherweise keine ausreichende Assurance erhalten. Eine Zertifizierung des australischen ASD beruht auf dem australischen ISM, das sich vom NZISM im Detail unterscheidet und eine andere Rechtsgrundlage hat (5.8.46). Die Wiederverwendung von Bewertungen anderer Regierungsstellen wird nach 5.8.61 ermutigt, und der GCDO unterstützt die gemeinsame Nutzung vorhandener Cloud-Bewertungen.

Für die Fassung gilt: Regierungsstellen müssen bei der Gestaltung eigener und ausgelagerter Systeme die neueste NZISM-Fassung verwenden (1.2.15). Ausgewertet ist hier Fassung 3.9 vom November 2025.

Was gesperrt ist

Nicht beschafft sind die PSR, auf deren Vorgaben GOV4, GOV5, INFOSEC1, INFOSEC2 und PERSEC1 bis PERSEC4 Abschnitt 2.2 für Drittanbieter verweist, der Inhalt formaler Vereinbarungen über eingestufte Informationen, eine Liste der Sicherheitsabkommen Neuseelands, das Verfahren der National Security Clearance, die Anhänge des Ombudsmen Act 1975 und des Official Information Act 1982 sowie neuseeländisches Vergabe- und Vertragsrecht. Aussagen daraus trifft dieser Artikel nicht.

Umsetzungsperspektive

1. Konstellation bestimmen. Für jeden neuseeländischen Auftrag festhalten, ob das Unternehmen Systeme im Auftrag einer Regierungsstelle betreibt, ob eine formale Vereinbarung über eingestufte Informationen besteht oder angestrebt wird, ob es sich um Outsourcing im Sinne von 2.2 oder um eine bloß bezogene Leistung handelt und ob Cloud-Dienste beteiligt sind.
2. Umfang und Einstufung schriftlich klären. Vom Kunden den Systemumfang, die Einstufung der Informationen, Vermerke wie NZEO oder Freigabevermerke und die maßgebliche NZISM-Fassung schriftlich festhalten lassen.
3. Standort- und Personalfragen früh prüfen. Klären, ob Leistungen aus Deutschland, von Standorten außerhalb der Kontrolle der neuseeländischen Regierung oder durch nicht neuseeländisches Personal erbracht werden sollen, und ob der Kunde dafür ein Sicherheitsabkommen, Überprüfungen oder eine Abweichungsentscheidung voraussetzt.
4. Abweichungen vorbereiten statt zusagen. Für jede Control im Systemumfang, die nicht oder anders umgesetzt wird, die Gründe, die Ersatzmaßnahmen und ihre Stärke dokumentieren, damit der System Owner des Kunden die Dispensation oder die Anerkennung des Restrisikos beantragen kann.
5. Assurance-Paket zuschneiden. Mit dem Kunden klären, welche Art und welches Maß unabhängiger Assurance seine Risikobewertung verlangt, und vorhandene Berichte (ISAE 3402 oder SOC 2 Type 2, ISO/IEC-27001-Zertifikat) um die Teile ergänzen, die nach dem NZISM kein einzelnes Schema und die gängigen ausgereiften Schemata nicht abdecken.
6. Vertrag passend gestalten. Berichts-, Prüf- und Informationsrechte, Ansprechstelle für Informationssicherheit und Fassungswechsel im Vertrag regeln, weil die Assurance des Kunden nach dem NZISM vom Vertrag abhängt.

Typische Fehler

1. Das NZISM wird als gesetzliche Pflicht des Unternehmens behandelt, obwohl es nicht kraft Gesetzes gilt und die Pflichten erst über Vertrag oder Vereinbarung entstehen.
2. Ein "NZISM-Zertifikat" wird angeboten oder verlangt, obwohl das NZISM kein Verfahren zur Zertifizierung eines Unternehmens als Ganzes beschreibt; Zertifizierung und Akkreditierung betreffen Systeme und Dienste und liegen beim Kunden.
3. Ein ISO/IEC-27001-Zertifikat oder ein SOC-2-Bericht wird als vollständiger NZISM-Nachweis dargestellt, obwohl nach dem NZISM kein einzelnes Schema alle seine Anforderungen und keines der gängigen ausgereiften Schemata die spezifischen Regierungsanforderungen etwa zu Personalüberprüfung und Datenhoheit abdeckt.
4. Ein Type-1-Bericht wird als gleichwertig mit einem Type-2-Bericht angeboten, obwohl das NZISM ihn mangels Aussage zur Wirksamkeit im Betrieb nur als begrenzt nützlich ansieht.
5. Der Dienstleister sagt Abweichungen zu oder "genehmigt" sie selbst, obwohl nur die Accreditation Authority des Kunden über Dispensationen entscheidet.
6. Die SHOULD-NOT-Empfehlung zu Ländern ohne Sicherheitsabkommen wird entweder als absolutes Verbot oder als bedeutungslos gelesen; tatsächlich ist sie eine Empfehlung, von der die Stelle nur begründet abweicht, und ob ein Abkommen mit Deutschland besteht, sagt das NZISM nicht.
7. NZEO und Freigabevermerke werden übersehen. Für NZEO-Informationen sind Zugang durch ausländische Staatsangehörige, also auch deutsches Personal, und Zugriff von Systemen und Einrichtungen, die nicht allein unter Kontrolle der neuseeländischen Regierung und neuseeländischer Staatsangehöriger stehen, ausgeschlossen; Betriebsmodelle mit deutschem Personal scheiden dort deshalb aus, ebenso ein Zugriff aus Einrichtungen, die nicht allein unter Kontrolle der neuseeländischen Regierung stehen; entscheidend ist nach 16.2.7 die alleinige Kontrolle, nicht das Eigentum an der Einrichtung. Bei Freigabevermerken nach Staatsangehörigkeit entscheidet der Vermerk: Deutsches Personal darf nur auf Informationen zugreifen, die für Deutschland freigegeben sind.
8. Cloud-Dienste werden als bloßer Einkauf behandelt, obwohl das NZISM Cloud Computing als Outsourcing einordnet; als bloß bezogene Leistung ohne Akkreditierungsbedarf nennt es nur Leistungen wie Strom, Wasser, Gebäudeunterhalt, Büromaterial und Telekommunikation.

Risiken und Trade-offs

Ein Dienstleister, der "volle NZISM-Erfüllung" zusagt, übernimmt ein Risiko, das er nicht steuern kann: Umfang, Einstufung, Abweichungen und Akkreditierung entscheidet der Kunde, und das NZISM verpflichtet Regierungsstellen, bei neuer Systemgestaltung die neueste Fassung zu verwenden. Eine enge Zusage auf eine Fassung und einen vereinbarten Umfang ist sicherer, kann aber im Wettbewerb schwächer wirken.

Beim Nachweis steht Wiederverwendung gegen Passgenauigkeit. Vorhandene ISAE-3402-, SOC- oder ISO/IEC-27001-Nachweise sind schnell verfügbar und vom NZISM als Mittel anerkannt, decken aber nach dem NZISM nicht alles ab. Eine eigene Prüfung gegen die NZISM-Controls des konkreten Systems ist passgenauer, aber teurer und mit jedem Fassungswechsel neu zu bewerten.

Beim Betriebsmodell steht Effizienz gegen Zulässigkeit: Eine Leistungserbringung aus Deutschland oder durch ein internationales Team ist günstig, kann aber für eingestufte Informationen von einem Sicherheitsabkommen, von Freigabevermerken für die betroffenen Staatsangehörigkeiten oder von einer Abweichungsentscheidung des Kunden abhängen. Für NZEO-Informationen ist sie ausgeschlossen, soweit ausländische Staatsangehörige Zugang hätten oder der Zugriff von Systemen und Einrichtungen erfolgte, die nicht allein unter Kontrolle der neuseeländischen Regierung und neuseeländischer Staatsangehöriger stehen. Eine neuseeländische Betriebseinheit mit überprüftem Personal ist teurer, aber für eingestufte Informationen oft die tragfähigere Lösung; für NZEO-Informationen genügt auch sie nur, soweit die Vorgaben zur Kontrolle durch einen neuseeländischen Staatsangehörigen im Regierungsdienst und zu Einrichtungen unter alleiniger Kontrolle der neuseeländischen Regierung und neuseeländischer Staatsangehöriger erfüllt sind.

Entscheidungspunkte

• In welcher Konstellation stehen wir bei jedem neuseeländischen Auftrag: Betrieb im Auftrag, formale Vereinbarung über eingestufte Informationen, Outsourcing nach 2.2, bloß bezogene Leistung oder Cloud-Dienst?
• Hat der Kunde Systemumfang, Einstufung, Vermerke und NZISM-Fassung schriftlich festgelegt?
• Erbringen wir Leistungen aus Deutschland oder mit nicht neuseeländischem Personal, und hat der Kunde geklärt, ob das für seine Informationen zulässig ist?
• Welche Nachweise bieten wir standardmäßig an, und wie schließen wir die Lücken, die nach dem NZISM kein einzelnes Assurance-Schema und die gängigen ausgereiften Schemata nicht abdecken?
• Wer bei uns liefert dem System Owner des Kunden die Unterlagen für Abweichungsentscheidungen, und wer verfolgt deren jährliche Überprüfung?

Praktische Empfehlungen

• In Angeboten keine pauschale "NZISM-Konformität" zusagen, sondern Fassung, Systemumfang, Einstufung und die angebotenen Nachweise benennen.
• Für jede nicht oder abweichend umgesetzte Control eine kurze Begründung mit Ersatzmaßnahme vorhalten, die der Kunde in seine Risikobewertung übernehmen kann.
• Type-2-Berichte bevorzugen, wenn der Kunde Aussagen zur Wirksamkeit im Betrieb braucht, und den Berichtszeitraum mit dem Vertragsbeginn abstimmen.
• Eine zentrale Ansprechstelle für Informationssicherheit benennen; das NZISM empfiehlt Regierungsstellen, sie vom Dienstleister zu verlangen.
• Prüf- und Berichtsrechte vertraglich regeln, statt sie im Konfliktfall nachzuverhandeln.
• Fragen zu Sicherheitsabkommen, Überprüfungen und neuseeländischem Vertragsrecht an den Kunden oder an neuseeländische Rechtsberatung geben; das NZISM beantwortet sie nicht.

Relevante Normreferenzen

• GCSB/GCISO, New Zealand Information Security Manual, Fassung 3.9 (November 2025): Abschnitt 1.1 (Interpretation of controls, Non-compliance, Key definitions), Abschnitt 1.2 (Applicability, Authority and Compliance), Abschnitt 2.2 (Non-Government Engagement and Outsourcing), Abschnitt 5.8 (Independent Assurance Reports); ergänzend 1.1.34, 1.1.39, 3.4.3, 4.4.1, 4.4.11, 9.2.3, 9.2.15, 9.2.16 und 16.2.7.
• Im NZISM genannt, Inhalt nicht im Quellensatz: Protective Security Requirements (u. a. GOV4, GOV5, INFOSEC1, INFOSEC2, PERSEC1 bis PERSEC4), Ombudsmen Act 1975, Official Information Act 1982, NZ Government Security Classification System; ISAE 3402, ISAE (NZ) 3402, ISAE (NZ) 3000, SSAE 16, SOC-Berichte, ISO/IEC 27001, CSA STAR.
• Abgrenzung: Das australische Gegenstück steht im Track ism-australien; eine ASD-Zertifizierung beruht nach NZISM 5.8.46 auf dem australischen ISM mit anderer Rechtsgrundlage, ein Vergleich steht in diesem Track nicht. Die NIST-Rahmenwerke stehen im Track nist, IT-Grundschutz im Track it-grundschutz und die CIS Controls im Track cis; Zuordnungstabellen zum NZISM enthält dieser Track nicht. SOC 2 als solches behandelt der Track soc2, ISO/IEC 27001 der Track core-iso27001; hier steht nur, was das NZISM über diese Nachweise sagt.