NZISM: Rollen, Certification and Accreditation und Pflichtdokumente, und was ein deutscher Dienstleister neuseeländischer Regierungsstellen daraus erwarten muss

Problem in der Praxis

Die erste Fehlannahme ist sprachlich. Wer "certification" liest, denkt an ein ISO/IEC-27001-Zertifikat einer akkreditierten Zertifizierungsstelle. Im NZISM ist Zertifizierung ein Schritt innerhalb der Regierungsstelle: Ihr CISO (oder ein vom Agency Head bestimmter Delegierter) stellt nach einem Audit fest, ob die Controls eines bestimmten Systems angemessen, umgesetzt und wirksam sind. Ein ISO-Zertifikat ist nach Abschnitt 5.8 ein mögliches Mittel, Vertrauen in einen Dienstleister zu gewinnen, aber kein Ersatz für diese Feststellung.

Die zweite Fehlannahme lautet: "Wir sind akkreditiert." Die Akkreditierung im Sinne des NZISM ist keine Eigenschaft eines Anbieters, sondern die förmliche Betriebserlaubnis eines Systems durch die Accreditation Authority der Regierungsstelle. Ein Dienstleister kann Beiträge liefern, die diese Entscheidung tragen; erteilen kann er sie nicht. Wer sich in Angeboten als "NZISM-akkreditiert" bezeichnet, behauptet etwas, das nach dem Begriffssystem des NZISM nur der Kunde für sein System erklären kann.

Die dritte Fehlannahme betrifft den Zeithorizont. Viele Anbieter rechnen mit einer einmaligen Prüfung beim Projektstart. Das NZISM sieht dagegen wiederkehrende Akkreditierungen vor, eine erneute Akkreditierung, wenn eine Konfigurationsänderung das Gesamtrisiko des Systems verändert, und eine Fortschreibung der Dokumentation. Wer den Betrieb übernimmt, wird damit Teil eines laufenden Nachweiszyklus.

CISO-Einordnung

Rechtsnatur und Wirkungsweg. Das NZISM wird vom Government Chief Information Security Officer (GCISO) veröffentlicht (NZISM 1.2.8) und ist Teil der Beratung und Unterstützung des GCSB (1.2.4). Es gilt für Informationen und Systeme, die von den in den Anhängen von Ombudsmen Act 1975 und Official Information Act 1982 genannten Regierungsstellen oder in deren Auftrag ("on behalf of") betrieben werden, sowie für Organisationen mit formaler Vereinbarung mit der Regierung über den Zugang zu eingestuften Informationen (1.2.3). Ob ein konkreter Auftrag darunterfällt und was daraus vertraglich folgt, behandelt nzism-002. Für diesen Artikel gilt: Die Controls der Kapitel 3 bis 5 adressieren die Stelle und ihre Funktionsträger; das deutsche Unternehmen trifft, was der Vertrag daraus macht.

Agency Head. Der Leiter der Stelle ist für die Informationssicherheit verantwortlich (3.1.1) und muss Entwicklung, Umsetzung und Pflege der Sicherheitsprozesse unterstützen (3.1.9). Er ist zugleich Accreditation Authority (3.1.5). Delegiert er diese Befugnis, muss der Delegierte mindestens dem Senior Executive Team oder einer gleichwertigen Führungsposition angehören (3.1.8); der Agency Head bleibt für die Entscheidungen seines Delegierten verantwortlich. Kleinere Stellen, die die Funktionstrennung nicht vollständig einhalten können, sollen Interessenkonflikte offenlegen und aktiv steuern.

CISO. Die Stelle soll einen CISO bestellen oder die Rolle einer vorhandenen Person übertragen, und zwar möglichst einem Mitglied der obersten Führungsebene (3.2.8). Als MUST formuliert ist nur, dass der CISO für alle eingestuften Informationen der Systeme der Stelle ermächtigt und in abgeschottete Informationen (compartmented information) einweisbar sein muss. Als SHOULD beschreibt das NZISM unter anderem die direkte Berichtslinie zum Agency Head, das strategische Sicherheits- und Risikoprogramm, ein fortlaufendes Programm der Zertifizierung und Akkreditierung aller Systeme, volle Kenntnis aller Vorfälle und die Koordination externer Sicherheitsressourcen einschließlich Vertragsschluss und Steuerung (3.2.9 bis 3.2.16). Wird die CISO-Funktion ausgelagert, weist das NZISM auf Interessenkonflikte hin, wenn dieser CISO zugleich mit anderen Anbietern zu tun hat, und auf Verfügbarkeit und Reaktionszeiten (3.2.8).

IT Security Manager. Die Stelle muss mindestens einen ITSM bestellen, und ITSMs müssen wie der CISO ermächtigt und einweisbar sein (3.3.4). Lagert die Stelle IT-Leistungen aus, sollen ihre ITSMs nach dem erläuternden Text von jedem IT-Dienstleister unabhängig sein, um Interessenkonflikte zu vermeiden (3.3.4; die zugehörige SHOULD-Control steht in Abschnitt 2.2). Der ITSM muss System Owner bei Erlangung und Erhalt der Akkreditierung unterstützen (3.3.6) und muss dafür verantwortlich sein, dass Security Risk Management Plans, System Security Plans und Standard Operating Procedures für alle Systeme entwickelt, gepflegt, aktualisiert und umgesetzt werden (3.3.8). Er soll mit Anbietern sowie Einkauf und Rechtsabteilung Sicherheitsverträge und Service Level Agreements aushandeln (3.3.7) und die Accreditation Authority über wesentliche Änderungen informieren, die die Akkreditierung berühren können (3.3.6). Für einen Dienstleister ist der ITSM daher meist der operative Gegenüber.

System Owner. Jedes System muss einen System Owner haben (3.4.10). Er ist für den Gesamtbetrieb verantwortlich, ausdrücklich einschließlich ausgelagerter Leistungen wie Support, Telekommunikation und Cloud (3.4.3), muss die Akkreditierung seines Systems erlangen und erhalten (3.4.11), muss für vollständige, zutreffende und aktuelle Sicherheitsdokumentation sorgen und dabei den ITSM einbeziehen (3.4.12). Abschnitt 3.4 führt zudem den Begriff der Zusicherung (assertion) ein: förmliche Erklärungen der Leitung oder des System Owners über Vollständigkeit, Richtigkeit und Gültigkeit der Angaben im Zertifizierungs- und Akkreditierungsverfahren. Wer als Dienstleister Angaben zuliefert, liefert damit Material für diese Zusicherungen.

Nutzer. Alle Systemnutzer, allgemeine wie privilegierte, müssen die einschlägigen Sicherheitsrichtlinien und Verfahren einhalten und müssen mit Zugangsdaten und Konten so umgehen, wie 3.5.4 es vorgibt; wer Richtlinien oder Mechanismen umgehen muss, braucht vorher eine förmliche Genehmigung des CISO oder eines dazu ausdrücklich ermächtigten ITSM. Erhalten Mitarbeiter eines Dienstleisters Konten auf Systemen der Stelle, sind sie in diesem Sinne Nutzer; ob und wie der Kunde diese Regeln vertraglich an sie weitergibt, ist im Vertrag zu prüfen.

Certification and Accreditation im Überblick. Nach Abschnitt 4.1 hat das Verfahren zwei Stufen, und im Regelfall muss die Zertifizierung vor der Akkreditierung abgeschlossen sein (4.1.5, 4.2.4); die Ausnahme nach 4.5.15 und 4.5.16 ist unten unter Akkreditierung beschrieben. Es beruht auf einer Risikobewertung, der Anwendung der NZISM-Controls und der Bestimmung des Restrisikos. Beteiligt sind vier Gruppen: der System Owner, die Certification Authority, der Assessor oder Auditor und die Accreditation Authority (4.1.10). Certification Authority, System Owner und Accreditation Authority sind voneinander unabhängig; in kleineren Stellen kann der Assessor zugleich Certification Authority sein (4.1.25). Die Annahme des Restrisikos liegt beim Chief Executive der Stelle oder bei der federführenden Stelle gemeinsamer Systeme (4.1.7).

Zuständigkeiten, wo ein Dienstleister beteiligt ist. Für externe Organisationen und Dienstleister, die eine Stelle unterstützen, ist Certification Authority der CISO der Stelle (4.1.14, 4.2.7). Accreditation Authority für Organisationen, die eine Stelle unterstützen, ist der Leiter der unterstützten Stelle oder sein Delegierter (4.5.6). Für Systeme mehrerer Staaten oder Stellen werden beide Rollen durch förmliche Vereinbarung bestimmt (4.1.15, 4.5.7). Werden High Assurance Cryptographic Equipment (HACE, hochsichere Kryptogeräte) eingesetzt oder abgeschottete, indossierte oder mit Zusatzvermerk versehene Informationen verarbeitet, nennt das NZISM den Director-General GCSB als Accreditation Authority (4.1.8, 4.5.8); Systeme mit abgeschotteten Informationen muss der GCSB akkreditieren (4.4.10). Für Informationen mit dem Vermerk New Zealand Eyes Only (NZEO) nennt 1.1.17 ebenfalls den Director-General GCSB.

Audit und Zertifizierung. Jedes System muss im Rahmen der Zertifizierung ein Audit durchlaufen (4.2.10). Die erste Auditstufe prüft Architektur und Dokumentation; der Auditor muss dabei Information Security Policy, Security Risk Management Plan, System Security Plan, Standard Operating Procedures und Incident Response Plan prüfen, System- und Sicherheitsarchitektur soll er prüfen (4.3.18). Der System Owner muss Architektur und Dokumentation vor dem Audit freigeben (4.3.17) und soll eine Anwendbarkeitserklärung (statement of applicability) vorlegen, die unter anderem anwendbare, nicht anwendbare und nicht eingehaltene Controls ausweist. Vor der Systemprüfung muss er die Controls umsetzen (4.3.19); die zweite Stufe muss Umsetzung und Wirksamkeit prüfen (4.3.20). Wo einschlägig, muss eine physische Sicherheitszertifizierung vorliegen, die zum Auditzeitpunkt jünger als drei Jahre sein soll. Der Auditor muss einen Bericht über Einhaltung und Abweichungen mit Vorschlägen zur Behebung erstellen (4.3.21). Auditoren sollen nachweislich unabhängig und weder System Owner noch Certification Authority sein (4.3.16); ein Audit kann durch eigene Auditoren oder eine unabhängige Sicherheitsorganisation erfolgen (4.3.8). Das NZISM bevorzugt die Prüfung gegen Risikobewertung und Control-Auswahl gegenüber einem Checklistenansatz über alle Controls (4.3.18). Als Audit-Nachweise nennt es neben der Dokumentation aus Kapitel 5 unter anderem Verträge mit Drittdienstleistern, unabhängige Risikobewertungen und Penetrationstests (4.3.9); Nachweise von außen gelten ihm dabei grundsätzlich als verlässlicher als selbst erzeugte (4.3.10). Penetrationstests beschreibt Kapitel 4 nur im erläuternden Text als wirksames Mittel, eine eigene Control dazu enthält es nicht (Volltextsuche siehe Quellenmatrix).

Die Certification Authority muss für die Zertifizierung anerkennen, dass die Controls angemessen und wirksam sind und den Protective Security Requirements (PSR) sowie den einschlägigen NZISM-Bestandteilen entsprechen (4.2.11). Die Zertifizierung bedeutet ausdrücklich nicht, dass das Restrisiko annehmbar oder eine Betriebserlaubnis erteilt ist. Danach soll die Certification Authority der Accreditation Authority eine Bewertung des Restrisikos mit Empfehlung vorlegen (4.2.12).

Akkreditierung. Die Stelle muss ein Akkreditierungsrahmenwerk entwickeln (4.4.4) und sicherstellen, dass jedes System akkreditiert ist, und zwar vor dem operativen Einsatz und vor der Anbindung an andere interne oder externe Systeme (4.4.5). Die Accreditation Authority muss das Restrisiko akzeptieren, um zu akkreditieren (4.5.18); sie kann kürzere Fristen bis zur erneuten Akkreditierung festlegen oder die Nutzung beschränken (4.5.14) und eine Überarbeitung von Risikoplan und System Security Plan verlangen (4.5.13). Ein System darf keine eingestuften Informationen oberhalb der Stufe verarbeiten, für die es akkreditiert ist (4.4.9). Systeme mit NZEO-Informationen müssen jederzeit unter der Kontrolle eines neuseeländischen Staatsangehörigen bleiben, der für die neuseeländische Regierung arbeitet (4.4.11). Die Anforderung knüpft an Staatsangehörigkeit und Tätigkeit der kontrollierenden Person an, nicht an die Herkunft eines Unternehmens. Ob eine konkrete Dienstleisterkonstellation diese personenbezogene Voraussetzung erfüllt, regelt das NZISM nicht näher; das ist mit dem Kunden zu klären. In außergewöhnlichen Fällen kann die Accreditation Authority vor einer Akkreditierungsentscheidung auf die Zertifizierung verzichten, wenn ein nicht sofortiger Betrieb verheerende und möglicherweise lang anhaltende Folgen für die Stelle hätte; diese Ausnahme muss förmlich festgehalten und angenommen werden, und die Zertifizierung muss so bald wie möglich nachfolgen (4.5.15, 4.5.16).

Erneute Akkreditierung. Zwischen zwei Akkreditierungen eines Systems dürfen höchstens drei Jahre liegen (MUST), empfohlen sind höchstens zwei Jahre (SHOULD, 4.4.12). Nach dem erläuternden Text kann eine Stelle ein zusätzliches Jahr nutzen, wenn sie das Verfahren für Abweichungen von einer SHOULD-Control einhält, also umfassende Risikobewertung, Freigabe durch die Leitung und förmliche Annahme des Restrisikos; Akkreditierungen sollen mindestens sechs Monate vor Fälligkeit beginnen. Nach drei Jahren erlischt die Betriebserlaubnis; ohne oder mit erloschener Akkreditierung darf ein System nur betrieben werden, wenn die Accreditation Authority eine Dispensation erteilt hat, also eine förmliche Befreiung. Weitere Anlässe nennt das NZISM unter anderem bei neuen Bedrohungen, unwirksamen Controls, einem schweren Vorfall oder einer wesentlichen Änderung. Ändert eine Konfigurationsänderung die Sicherheit und wird dadurch das Gesamtrisiko als verändert bewertet, muss das System erneut akkreditiert werden (6.3.8, Einzelheiten zum Änderungsmanagement in nzism-004).

Sorgfalt gegenüber Dritten. Tauscht ein System der Stelle Informationen mit dem System eines Dritten aus, muss die Stelle sicherstellen, dass der Empfänger einen der Einstufung oder den Datenschutzanforderungen entsprechenden Schutz hat und zum Empfang berechtigt ist (4.4.8). Sie muss ihre Sicherheitserwartungen und nationale Sicherheitsanforderungen in Dokumenten festhalten, wozu das NZISM unter anderem Vertragsbestimmungen, Absichtserklärungen (memorandum of understanding) und Vertraulichkeitsvereinbarungen zählt, und muss über einen förmlichen Prozess Gewissheit erlangen, dass der Dritte diese Erwartungen erfüllt und weiter erfüllt. Sie soll dazu Akkreditierungsunterlagen des Empfängers prüfen. Für den Dienstleister ist das der Kern seiner Nachweislast.

Pflichtdokumente. Abschnitt 5.1 fasst den Dokumentensatz zusammen. Als MUST gefasst sind: eine Information Security Policy (SecPol) der Stelle, eine dokumentierte Systems Architecture für jedes System (sie schließt ausgelagerte Leistungen und die Sicherheitsarchitektur ein), ein Security Risk Management Plan (SRMP) für jedes System mit Benennung der Risikoeigner, ein System Security Plan (SSP) für jedes System, Standard Operating Procedures (SOPs) und ein Incident Response Plan (IRP) mit unterstützenden Verfahren, in dem das Personal geschult wird und den es regelmäßig übt (5.1.7 bis 5.1.12). Die Dokumente müssen angemessen eingestuft sein (5.1.18). Notfallverfahren soll die Stelle dokumentieren (5.1.13); dass vor einer Räumung eingestufte Informationen und Systeme zu sichern sind, muss in den Räumungsverfahren stehen, wobei die Sicherheit der Menschen Vorrang hat (5.7). Kleinere Stellen und Systeme dürfen alle Dokumente in einem zusammenfassen, wenn jedes Element erkennbar bleibt; die Bezeichnungen sind nach einem Hinweis in 5.1.4 nicht zwingend, doch sollen Stellen ohne eigenes Dokumentationsgerüst und Stellen mit abweichenden Namen nach 5.1.16 und 5.1.17 die NZISM-Bezeichnungen verwenden.

Inhaltlich gilt: Der SSP muss die Controls aus dem NZISM nach dem Umfang des Systems auswählen und um systemspezifische Controls aus dem SRMP ergänzen; er soll die jeweils neueste Fassung des NZISM zugrunde legen und einen Key Management Plan enthalten (5.4.5). Unter den Beteiligten am SSP nennt 5.4.4 ausdrücklich das Projekt, das die Fähigkeit liefert, einschließlich Auftragnehmern. Der SRMP soll Risikobewertung und Behandlungsstrategie enthalten und nach internationalen Risikomanagementnormen erstellt werden; nach Angabe des NZISM verlangen die PSR dafür ISO 31000:2018 (5.3.9). SOPs soll es für ITSM, Systemadministratoren und Nutzer geben, und diese sollen schriftlich bestätigen, sie gelesen zu haben und einzuhalten (5.5). Der IRP muss einen Mindestinhalt haben, darunter Leitlinien, was ein Vorfall ist, die Sicherung der Beweisintegrität, den Weiterbetrieb kritischer Systeme und wann und wie förmlich gemeldet wird (5.6.3). Die Dokumentation soll mindestens jährlich oder nach wesentlichen Änderungen überprüft und mit dem Datum der letzten Prüfung versehen werden (5.1.21). Lagert die Stelle die Erstellung der Dokumente aus, soll sie diese auf Eignung prüfen, die Kontrolle über den Inhalt behalten und die Erfüllung aller Vorgaben sicherstellen (5.1.19).

Vulnerability Disclosure Policy. Die Stelle muss eine Vulnerability Disclosure Policy (VDP), also Regeln für die Meldung von Schwachstellen durch Dritte, entwickeln und veröffentlichen; welche öffentlich erreichbaren Systeme sie umfasst, muss eine Risikobewertung bestimmen (5.9.23, 5.9.24). Die VDP muss einen Kerninhalt haben, darunter Geltungsbereich, Kontakt und sichere Übermittlungswege, Bestätigung und Reaktionszeit, eine Vertraulichkeitsabrede bis zum Ende der Offenlegungsfrist und eine Aussage zu Bug Bounties. Die Stelle muss zusagen, gemeldete Schwachstellen innerhalb der selbst gesetzten Frist zu behandeln; diese Frist soll höchstens 90 Tage betragen (5.9.26). Eine security.txt soll sie veröffentlichen, und die VDP muss mit den übrigen Sicherheitsrichtlinien verzahnt sein. Für Hersteller wichtig: Nach 5.9.10 soll die VDP klarstellen, dass die Stelle Meldungen zu Software oder Diensten Dritter entgegennimmt, aber gegebenenfalls mit dem Meldenden die Meldung an den zuständigen Anbieter weitergeben muss. Ein deutscher Softwareanbieter kann auf diesem Weg Schwachstellenmeldungen einer neuseeländischen Stelle erhalten.

Unabhängige Prüfberichte. Abschnitt 5.8 betont, dass Risikoeigentum und Verantwortlichkeit bei der Stelle bleiben, auch wenn Funktionen ausgelagert sind (5.8.3). Die Stelle muss durch eine Risikobewertung bestimmen, welche Art und welches Maß an unabhängiger Zusicherung sie für Zertifizierung und Akkreditierung braucht, und muss die Ergebnisse unabhängiger Prüfberichte in ihre Zertifizierung einbeziehen (5.8.61, 5.8.62). Wo sie die Leistung eines Anbieters nicht selbst prüfen kann, soll sie unabhängige Prüfberichte einholen. Das NZISM beschreibt als Beispiele unter anderem ISAE 3402 und ISAE (NZ) 3402 mit Typ-1- und Typ-2-Berichten, SOC-Berichte, die ISO/IEC-27001-Zertifizierung und CSA STAR; einen Typ-1-Bericht hält es für begrenzt aussagekräftig, weil er die operative Wirksamkeit der Controls nicht abdeckt (5.8.16); er prüft nach 5.8.26 die Gestaltung und Entwurfswirksamkeit zu einem Zeitpunkt. Nach 5.8.61 deckt kein einzelnes Schema die Anforderungen des NZISM vollständig ab, und keines der gängigen Schemata erfasst spezifische Regierungsanforderungen wie Überprüfung und Sicherheitsermächtigung des Personals oder die Datenhoheit. Für ausgelagerte IT-Leistungen außerhalb der Stelle verlangt Abschnitt 2.2 zusätzlich, die Systeme des Auftragnehmers mindestens auf dem Standard der Stelle zu akkreditieren, was auch über einen ISAE-3402-Bericht geschehen kann; Einzelheiten aus Sicht des Dienstleisters in nzism-002.

Umsetzungsperspektive

1. Rolle im Verfahren klären. Mit dem Kunden festhalten, welches System akkreditiert wird, wer System Owner, Certification Authority und Accreditation Authority ist und welcher ITSM der operative Ansprechpartner ist. Ohne diese Zuordnung lässt sich kein Nachweis gezielt liefern.
2. Einstufung erfragen. Die Einstufung des Systems entscheidet, welche Controls gelten und ob der GCSB beteiligt ist; bei NZEO-Informationen müssen die Systeme jederzeit unter der Kontrolle eines neuseeländischen Staatsangehörigen bleiben, der für die neuseeländische Regierung arbeitet, und wie der eigene Einsatz dazu passt, ist mit dem Kunden zu klären. Die verbindliche Einstufung trifft der Kunde.
3. Nachweispaket nach Abschnitt 5.8 vorbereiten. Vorhandene Berichte (etwa ISAE 3402 Typ 2, SOC 2, ISO/IEC-27001-Zertifikat) mit Geltungsbereich, Zeitraum und Ausnahmen bereithalten und offen benennen, was sie nicht abdecken, insbesondere Personalüberprüfung und Datenhoheit.
4. Dokumentbeiträge planen. Beiträge zu Systems Architecture, SSP, SOPs und IRP so liefern, dass der Kunde die Kontrolle über den Inhalt behält; die Bezeichnungen des NZISM übernehmen, wenn der Kunde sie verwendet.
5. Auditfähigkeit herstellen. Auditzugang, Ansprechpartner und Belege für beide Auditstufen einplanen, einschließlich Antworten auf die Anwendbarkeitserklärung des System Owners und der Behebung festgestellter Abweichungen.
6. Akkreditierungszyklus einpreisen. Erneute Akkreditierung spätestens nach drei Jahren, empfohlen nach zwei, mit Beginn sechs Monate vorher, sowie anlassbezogen bei wesentlichen Änderungen oder schweren Vorfällen.
7. Schwachstellenkanal für NZ-Kunden einrichten. Einen Kontakt benennen, über den eine Stelle Meldungen aus ihrer VDP weitergeben kann, und eigene Behandlungsfristen so festlegen, dass der Kunde seine Zusage halten kann.

Typische Fehler

1. "Certification" wird mit einem ISO-Zertifikat gleichgesetzt, obwohl das NZISM darunter die Feststellung der Certification Authority der Stelle nach einem Audit versteht.
2. Der Anbieter erklärt sich selbst für "akkreditiert", obwohl die Akkreditierung die Betriebserlaubnis der Accreditation Authority des Kunden für ein bestimmtes System ist.
3. Ein ISO/IEC-27001-Zertifikat oder ein SOC-2-Bericht wird als vollständiger Nachweis angeboten, obwohl das NZISM festhält, dass kein einzelnes Schema seine Anforderungen vollständig abdeckt.
4. Ein Typ-1-Bericht wird vorgelegt, wo der Kunde Aussagen zur operativen Wirksamkeit über einen Zeitraum braucht.
5. SHOULD-Controls werden als unverbindlich abgetan, obwohl die Stelle nach dem NZISM die Nichtumsetzung festhalten und das daraus folgende Restrisiko von der Accreditation Authority anerkennen lassen muss und der Kunde dafür Angaben vom Dienstleister braucht.
6. Konfigurationsänderungen werden ohne den Kunden umgesetzt, obwohl eine risikoverändernde Änderung eine erneute Akkreditierung auslöst.
7. Der ausgelagerte ITSM oder CISO kommt vom selben Dienstleister, der die IT betreibt, und der Interessenkonflikt wird nicht offengelegt.
8. Die Vulnerability Disclosure Policy des Kunden wird nicht bedacht, sodass Schwachstellenmeldungen, die die Stelle weitergibt, beim Hersteller keinen Empfänger finden.

Risiken und Trade-offs

Der Grundkonflikt liegt zwischen Transparenz und Schutz eigener Informationen. Die Stelle muss sich vergewissern, dass der Dienstleister ihre Erwartungen erfüllt und weiter erfüllt, und das NZISM wertet extern erzeugte und dokumentierte Nachweise höher als Selbstauskünfte. Ein Anbieter, der Architekturunterlagen, Prüfberichte und Auditzugang großzügig gewährt, verkürzt die Zertifizierung, legt aber mehr über seine Umgebung offen. Wer zurückhaltend liefert, riskiert, dass die Certification Authority die Controls nicht als angemessen und wirksam anerkennen kann.

Bei den Prüfberichten steht Wiederverwendung gegen Passgenauigkeit. Ein vorhandener ISAE- oder SOC-Bericht ist günstig, beantwortet aber nicht die regierungsspezifischen Fragen, die das NZISM ausdrücklich ausnimmt. Ein auf den Kunden zugeschnittenes Audit beantwortet sie, kostet aber Zeit und wiederholt sich mit jeder erneuten Akkreditierung.

Bei Änderungen schließlich steht Geschwindigkeit gegen Akkreditierungsstatus. Ein Dienstleister, der Änderungen schnell ausrollt, kann die Akkreditierung des Kundensystems gefährden; einer, der jede Änderung vorlegt, verlangsamt den Betrieb. Eine vertraglich vereinbarte Einordnung, welche Änderungen der Kunde vorab sehen muss, löst diesen Konflikt besser als Einzelfallentscheidungen.

Entscheidungspunkte

• Für welche Kundensysteme liefern wir Beiträge zur Zertifizierung, und wer ist dort Certification Authority und Accreditation Authority?
• Welche unabhängigen Prüfberichte halten wir vor, und decken sie Zeitraum und Geltungsbereich ab, die der Kunde braucht?
• Wie beantworten wir Fragen nach Personalüberprüfung, Sicherheitsermächtigung und Datenhoheit, die gängige Prüfschemata nach dem NZISM nicht abdecken?
• Welche Änderungen legen wir dem Kunden vorab vor, damit seine Akkreditierung nicht berührt wird?
• Tragen wir den Aufwand wiederkehrender Akkreditierungen, und ist er im Preis enthalten?
• Bieten wir ausgelagerte CISO- oder ITSM-Leistungen an, und wie legen wir mögliche Interessenkonflikte offen?

Praktische Empfehlungen

• Im Angebot nicht von "NZISM-Zertifizierung" oder "NZISM-Akkreditierung" des Anbieters sprechen, sondern von Beiträgen zur Zertifizierung und Akkreditierung des Kundensystems.
• Ein Nachweisverzeichnis führen: welcher Bericht, welches Schema, welcher Zeitraum, welche Leistungen, welche Lücken gegenüber den Anforderungen des Kunden.
• Dokumentbeiträge versioniert und datiert liefern, damit der Kunde seine jährliche Überprüfung und die Fortschreibung bei Änderungen nachweisen kann.
• Für Auditoren des Kunden einen festen Ansprechpartner und einen Prozess für Nachforderungen einrichten.
• Den Akkreditierungstermin des Kundensystems im eigenen Servicekalender führen und rechtzeitig vorbereiten.
• Fragen zur Einstufung, zu PSR-Vorgaben oder zur Rolle des GCSB nicht selbst beantworten, sondern beim Kunden klären; Rechtsfragen zum neuseeländischen Recht gehören zu neuseeländischer Rechtsberatung.

Relevante Normreferenzen

• NZISM 3.9 (November 2025), Abschnitt 1.1 (Begriffe Accreditation Authority, Certification, Accreditation, Waiver und Exception; Verbindlichkeitssprache 1.1.40 bis 1.1.47; Abweichungsverfahren 1.1.64 bis 1.1.69) und 1.2 (Geltung 1.2.3, Rechtsnatur 1.2.6, Herausgeber 1.2.8, neueste Fassung 1.2.15).
• Kapitel 3 "Information security governance - roles and responsibilities": 3.1 Agency Head, 3.2 Chief Information Security Officer, 3.3 Information Technology Security Managers, 3.4 System Owners, 3.5 System Users.
• Kapitel 4 "System Certification and Accreditation": 4.1 Prozess, 4.2 Zertifizierung, 4.3 Audits, 4.4 Akkreditierungsrahmen, 4.5 Akkreditierungen.
• Kapitel 5 "Information security documentation": 5.1 Grundlagen, 5.2 SecPol, 5.3 SRMP, 5.4 SSP, 5.5 SOPs, 5.6 IRP, 5.7 Notfallverfahren, 5.8 unabhängige Prüfberichte, 5.9 Vulnerability Disclosure Policy; dazu 2.2 (Auslagerung) und 6.3.8 (erneute Akkreditierung nach Änderung) als Verweis.
• Abgrenzung: Das australische Gegenstück, das ISM des ASD mit eigenem Freigabemodell, steht im ism-australien-Track; Risikomanagement- und Autorisierungsverfahren der NIST-Rahmenwerke im nist-Track; das deutsche Rahmenwerk mit eigenem Zertifizierungsverfahren im it-grundschutz-Track; die CIS Controls im cis-Track. Hier steht nur, was das NZISM selbst zu Rollen, Certification and Accreditation und Dokumentation sagt; Überblick und Rechtsnatur in nzism-001, Betroffenheit und Abweichungsverfahren aus Sicht des Dienstleisters in nzism-002, Betrieb und Vorfälle in nzism-004.