• security executives;
• security and information assurance practitioners;
• IT Security Managers; 
• Departmental Security Officers; and
• service providers.

• Objective – the desired outcome when controls within a section are implemented.
• Context – the scope, applicability and any exceptions for a section.
• References – references to external sources of information that can assist in the interpretation or implementation of controls.
• Rationale & Controls 
  • Rationale – the reasoning behind controls and compliance requirements.
  • Control – risk reduction measures with associated compliance requirements.

1. A control is not relevant in the agency;
2. A system or ICT capability does not exist in the agency; or 
3. A process or control(s) of equal strength has been substituted.

1. Is the agency willing to accept additional risk?
2. Have any implications for All-of-Government systems been considered?
3. If, so, what is the justification?

• the reason(s) for not being able to comply with this manual;
• the effect on any of their own, multi-agency or All-of-Government system;
• the alternative mitigation measure(s) to be implemented;
• The strength and applicability of the alternative mitigations;
• an assessment of the residual security risk(s); and
• a date by which to review the decision.

• New Zealand Government departments, agencies and organisations as listed in:
  • Parts 1 and 2 of Schedule 1 to the Ombudsmen Act 1975 (as amended); and
  • Schedule 1 to the Official Information Act 1982.
• any other organisations that have entered into a formal Agreement with the New Zealand Government to have access to classified information.

• The national security of New Zealand; and
• The international relations and well-being of New Zealand; and
• The economic well-being of New Zealand.

• confirms the GCISO's ability to set information security standards for GCISO mandated agencies;
• clarifies the expectation for the GCISO to set assurance activities, and develop assurance methodologies, to meet standards and guidelines;
• confirms GCISO access to information security investment information (along with joint System Leads for Data and Digital) from GCISO mandated agencies, including baseline spending; and
• confirms the expectation of the GCISO to provide investment advice and guidance to the government on cyber security matters for the public sector.

The GCSB uses signals intelligence collection capabilities to produce intelligence that provides decision advantage to government agencies in conduct of their legislatively mandated functions. The provision of this intelligence is one way that the GCSB contributes to the safety and security of New Zealand and New Zealand’s interests.

New Zealand needs cyber security to: 

• protect and maintain the digital services that the country relies on;  
• protect its intellectual property;  
• maintain its reputation as a stable and secure place to do business; and 
• ensure that governmental and democratic processes remain free from interference.

• promoting standards and policy. 
• providing guidance. 
• promoting secure by design. 
• technical advice. 
• increasing service delivery.  
• building assurance; and  
• supporting the information security workforce.

The GCDO is the government system lead for digital. This role oversees the development and management of digital for the state sector.  

• setting digital policy and standards, 
• improving investments, 
• establishing and managing services, 
• developing capability, and 
• system assurance (assuring digital government outcomes). 

The GCDS is the government system lead for data. This role supports the use of data as a resource across government to help deliver better services to New Zealanders. 

The Government Protective Security Lead (GPSL) is the functional lead for protective security. 

The Government Chief Privacy Officer (GCPO) is the government practice lead for privacy. This role leads an all-of-government approach to privacy to raise public sector privacy maturity and capability.

• providing leadership by setting the vision for privacy across government, 
• building capability by supporting agencies to lift their capability to meet their privacy responsibilities,  
• providing assurance on public sector privacy performance, and 
• engaging with the Office of the Privacy Commissioner and New Zealanders about privacy.  

The Government Procurement Lead is responsible for strengthening leadership and oversight of suppliers and agencies in key procurement sectors.  A core part of this role is helping to ensure that agencies collaborate around sourcing and purchasing common goods and services.  New Zealand Government Procurement and Property supports the Chief Executive of MBIE in their role as Procurement system lead.

• make it easy for government agencies and suppliers to work together.
• lift procurement capability.
• improve the visibility of procurement activities and system performance; and
• facilitate and coordinate cross-agency collaboration.

Archives NZ is the regulator of information created by the public sector, and reports to Cabinet on the state of Government recordkeeping.

The Controller and Auditor-General has two business units, the Office of the Auditor-General, and Audit NZ. Together they give Parliament and the public an independent view of how public organisations are operating.

The Department of Internal Affairs has a range of relevant functions, including digital identity and digital safety, and regulatory functions including spam prevention and messaging compliance and money laundering. DIA provides guidance to support government organisations to use generative AI, cloud, enterprise architecture, government domain names, and APIs.

The Department of the Prime Minister and Cabinet’s purpose is to advance an ambitious, resilient, and well-governed New Zealand. The National Security Group business unit provides leadership across New Zealand’s national security community towards a secure and resilient Aotearoa New Zealand. The DPMC works on the Christchurch Call, critical infrastructure, and the National Security Intelligence Priorities.

The MBIE works to ensure that telecommunications markets operate efficiently, and the commerce and ICT infrastructure is well developed. It is responsible for maintaining a robust regulatory environment for the ICT sector, and works to improve broadband and mobile connectivity for New Zealanders.

MFAT ensures that New Zealander’s can live, do business, travel and communicate more safely at home and offshore.

The Police can investigate cybercrime and harmful digital communications. 

NZSIS’ mission is to keep NZ and New Zealanders safe and secure. The Director-General is the Government Protective Security Lead, and the NZSIS manages the Protective Security Requirements framework and maintains the Information Security Classification System.

The Office of the Privacy Commissioner works to develop and promote a culture in which personal information is protected and respected.

The Public Services Commission monitors Public Service organisations and Chief Executives’ performance.

Outsourcing may present elevated levels of risk and additional risks. Outsourcing therefore, requires greater consideration, demonstrable governance, and higher levels of assurance before committing to such contracts.

Purchased services, as identified above, do NOT require accreditation or a third party review as defined in the NZISM. However, normal contract due diligence should be exercised before committing to these supply contracts.

• Chapter 4 – System Certification and Accreditation
• Chapter 5 – Information Security Documentation
• Chapter 13 – Decommissioning and Disposal
• Chapter 16 – Access Control
• Chapter 17 – Cryptography
• Chapter 19 – Gateway Security
• Chapter 20 – Data Management
• Chapter 22 – Enterprise Systems Security

• The dynamic nature of the cloud and its related infrastructure;
• No customer ownership or control of infrastructure;
• Limited visibility of architectures and transparency of operations; 
• Shared (multi-tenanted) physical and virtual environments; and
• May require re-architecting of agency system to optimise use of cloud services.

• Authentication;
• Authorisation; and
• Non-repudiation.

• where information is located;
• where it is able to be accessed from;
• who is able to access information; and
• how ICT services are funded and sustained.

• Outcomes and benefits that the adoption of cloud technologies will bring;
• Risks introduced or mitigated through the use of cloud, and the agency’s risk tolerance;
• Financial and cost accounting models;
• Shared responsibility models;
• Cloud deployment models;
• Cloud security strategy;
• Resilience and recovery approaches;
• Data recovery on contract termination;
• Cloud exit strategy and other contractual arrangements; and
• A high level description of the foundation services that enable cloud adoption, including:
  • User, device and system identity;
  • Encryption and key management;
  • Information management;
  • Logging and alerting;
  • Incident management;
  • Managing privileged activities; and
  • Cost management.

Zero Trust is a set of principles and outcomes, not an architecture or a solution.  You cannot ‘buy’ Zero Trust.

Zero Trust is compatible with other ICT outcomes, such as improved access to information, increased agility and better security.

Key aspects of Zero Trust focus on:

• Visibility (through telemetry) and analytics of how services are functioning – this comes through as focus on monitoring, event gathering and machine learning based analysis; and
• Automation of service delivery and security actions.

• Is the system a high value asset based on agency requirements?
• Does the system protect sensitive information (e.g., key stores, passwords, root keys, signing keys, personal information, and classified information)?
• Do other systems (internal or external to the agency) depend on the cryptographic protections in place on the quantum vulnerable system?
• How long does the data need to be protected?

• cleared for access to all classified information processed by the agency’s systems, and
• able to be briefed into any compartmented information on the agency’s systems.

• cleared for access to all classified information processed by the agency’s systems; and
• able to be briefed into any compartmented information on the agency’s systems.

Transactions and events

• Occurrence — the activities recorded have actually taken place.
• Completeness — all aspects are properly recorded.
• Accuracy — the assets and activities are accurately allocated and recorded.
• Cutoff — the activities have been recorded in the correct time period.
• Classifications — are accurate and appropriate.

Position on project completion

• Existence — assets, liabilities and equity balances exist.
• Rights and Obligations — the entity legally controls rights to its assets and its liabilities and accurately records obligations.
• Completeness — all aspects are properly recorded.
• Valuation and Allocation — costs and assets appropriately valued and allocated.

Presentation and disclosure

• Occurrence — the events and implementations have actually occurred.
• Rights and Obligations — contracts, licences, support and supply agreements
• Completeness — all disclosures have been included in the statements.
• Classification — statements are clear and appropriately presented.
• Accuracy and Valuation — information is disclosed at the appropriate amounts.

• protect account authenticators at the same classification of the system it secures;
• not share authenticators for accounts without approval;
• be responsible for all actions under their accounts; and
• use their access to only perform authorised tasks and functions.

• System Owners, responsible for the design, development, system documentation and system maintenance, including any requests for recertification or reaccreditation.
• The Certification Authority, responsible for the review of information and documentation provided by the system owner to ensure the ICT system complies with minimum standards and the agreed design.
• The Assessor or Auditor, who will conduct inspections, audits and review as instructed by the Certification Authority.
• The Accreditation Authority will consider the recommendation of the Certification Authority. If the level of residual risk is acceptable, the Accreditation Authority will issue the system accreditation (the formal authority to operate a system).

• development and review of security documentation;
• assurance over externally provided services such as Telecommunications and Cloud;
• a physical inspection;
• a technical review of the system and environment; and/or
• technical testing.

• the risk identification and assessment;
• design and complexity (including the system and security architectures);
• any available assurance reports on support or outsourced services;
• controls selection;
• actual implementation and effectiveness of controls for a system; and
• supporting information security documentation.

• The NZSIS for Physical Security;
• GCSB for TOP SECRET sites and Sensitive Compartmented Information Facilities (SCIFs);
• MFAT for systems located at overseas posts and missions;
• The Chief Security Officer (CSO) may be consulted on personnel and physical security aspects of information security;
• The CISO, ITSM or communications security officer may be consulted on COMSEC aspects of information security; and
• The ITSM and System Owner on aspects of secure system design configuration and operation.

• Risk owners have been identified; and
• Each risk owner has sufficient accountability and authority to manage their identified risks.

• Materiality.  Materiality is the threshold where any distorted, missing and incorrect information is likely to have an impact on the risk and security of a system.  Where it becomes clear that there are material deficiencies in the evidence presented more substantive tests may be required or the audit suspended until corrective action has been taken by the agency.
• Risk assessment: It is almost impossible to validate every risk identification and selection of risk treatments.  For larger systems a more practical approach may be to validate the identification and treatment of major risks and use sampling techniques for the balance.
• Economy: Before gathering or requesting additional audit evidence, it is important to consider whether or not it is feasible or cost-effective to generate this evidence against the benefits, assessed value and time required.

• the baseline of this manual used for determining controls;
• controls that are, and are not, applicable to the system;
• controls that are applicable but are not being complied with; and
• any additional controls implemented as a result of the SRMP.

• assurance and confirmation that the certification and accreditation process described in the NZISM is adhered to;
• conducting or utilising any third party reviewed assurance reports;
• conducting an accreditation of the system being connected to; and/or
• seeking a copy of existing accreditation deliverables in order to make their own accreditation determination.

• contract provisions; 
• a memorandum of understanding;
• non-disclosure agreements.

• changes in the agency’s information security policies or security posture;
• detection of new or emerging threats to agency systems;
• the discovery that controls are not operating as effectively as planned; 
• a major information security incident; and
• a significant change to systems, configuration or concept of operation for the accredited system.

• examines the risks to systems identified in the certification process;
• reviews the controls applied to manage those risks; and then
• determines the acceptability of any residual risk.

• Information Security Documentation as described in Chapter 5;
• any interaction with systems of other agencies or All-of-Government systems;
• compliance audit reports;
• the accreditation recommendation from the certification authority;
• supporting documentation for any decisions to be non-compliant with any controls specified in this manual; 
• any additional security risk reduction strategies that have been implemented; and
• any third party reviews or assurance reports available.

Note: For smaller agencies and smaller systems it is acceptable that all documentation elements are combined into a single document provided each documentation element is clearly identifiable.

Note: Agencies may choose to name the documentation in different terms. This is acceptable provided the required level of detail is captured.  Naming conventions presented in the NZISM are not mandatory.

• Highest classification of information stored, processed or communicated over that system;
• Sensitivity including existence of the facility;
• Inclusion of vulnerability information, security mechanisms or special processing capability in the systems documentation;
• Potential data aggregation;
• Risk and threat levels; and
• Scope and use of the system.

• review the documents for suitability;
• retain control over the content; and
• ensure that all policy requirements are met.

• all high-level information security documentation is approved by the CISO and the agency head or their delegate; and
• all system-specific documents are reviewed by the ITSM and approved by the system owner.

• at least annually; or
• in response to significant changes in the environment, business or system; and
• with the date of the most recent review being recorded on each document.

• policy objectives;
• how the policy objectives will be achieved;
• the guidelines and legal framework under which the policy will operate;
• stakeholders;
• education and training;
• what resourcing will be available to support the implementation of the policy; 
• what performance measures will be established to ensure that the policy is being implemented effectively; and
• a review cycle.

• accreditation processes;
• personnel responsibilities;
• configuration control;
• access control;
• networking and connections with other systems;
• physical security and media control;
• emergency procedures and information security incident management;
• vulnerability disclosure;
• change management; and
• information security awareness and training.

• How risks are found, recognised and described; and
• How sources of possible risks are to be considered.

The Protective Security Requirements requires that agencies adopt risk management approaches in accordance with ISO 31000:2018. Refer to PSR governance requirement GOV2.

• project, who MUST deliver the capability (including contractors);
• owners of the information to be handled;
• system users for whom the capability is being developed;
• management audit authority;
• CISO, ITSM and system owners;
• system certifiers and accreditors;
• information management planning areas; and
• infrastructure management.

• ITSM;
• system administrator; and
• system user.

• broad guidelines on what constitutes an information security incident;
• the minimum level of information security incident response and investigation training for system users and system administrators;
• the authority responsible for initiating investigations of an information security incident;
• the steps necessary to ensure the integrity of evidence supporting an information security incident;
• the steps necessary to ensure that critical systems remain operational; 
• when and how to formally report information security incidents; and
• national policy requirements for incident reporting (see Chapter 7 – Information Security Incidents).

• clear definitions of the types of information security incidents that are likely to be encountered;
• the expected response to each information security incident type;
• the authority within the agency that is responsible for responding to information security incidents;
• the criteria by which the responsible authority would initiate or request formal, police investigations of an information security incident;
• which other agencies or authorities need to be informed in the event of an investigation being undertaken; and
• the details of the system contingency measures or a reference to these details if they are located in a separate document.

• Business owners to identify and understand the risks associated with the service delivery;
• System owners to more fully assess system risks;
• System designers and security architects to make informed judgements on system structures, controls, defensive measures, and enterprise integration; and
• Regulators, certifiers and accreditors to obtain assurance over the service providers internal control structures and assess the suitability of system structures, controls and defensive measures.

• A description of the service provider’s business and control environment;
• Terms and conditions of the service contract or other legally binding agreement;
• Assertions supplied by the service provider (self-assessments);
• An independent validation of service provider assertions;
• Independent testing of controls implementation and effectiveness;
• Assurance in the service design and security architecture; and
• Assurance in the service components.

• The service organisation’s description of its system fairly presents the system as designed and implemented throughout a specified period or a specific date;
• The controls related to the control objectives stated in the service organisation’s description of its system were suitably designed throughout the specified period or at the specified date;
• Where included in the scope of the engagement, the controls were implemented and operated effectively to provide reasonable assurance that the control objectives stated in the service organisation’s description of its system were achieved throughout the specified period.

• reporting only whether controls at a service organisation operated as described; or
• reporting on controls at a service organisation other than those related to a service relevant to user entities.

• The service auditor’s report;
• Assertions by the service provider;
• A description of control objectives and controls provided by the service organisation;
• Results of any tests and other information provided by the independent auditor; and
• Any other information provided by the service provider.

• Intentional acts by the service providers staff;
• Anomalies;
• Direct assistance;
• Subsequent events;
• Statement restricting use of the service auditor’s report;
• Disclaimer of Opinion;
• Documentation completion;
• Engagement acceptance and continuance; and
• Elements of the SSAE 16 report that are not required in the ISAE 3402 report.

SOC 1 Report – Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting. Reporting on controls relevant to internal control over financial reporting and usually conducted in accordance with Statement on Standards for Attestation Engagements (SSAE) No. 16 and AT 801 – Reporting on Controls at a Service Organization. A SOC 1 report can be based on a Type 1 or a Type 2 audit.

SOC 2 Report— Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy. SOC 2 Reporting follows the AICPA AT Section 101 (not SSAE 16) and encompasses controls at service organisations on security, availability, processing Integrity, confidentiality and privacy. SOC 2 reports assist in comparing two or more data centres or service providers.

SOC 3 Report— Trust Services Report for Service Organizations. As well as reporting on controls relevant to security, availability, processing integrity, confidentiality and privacy a SOC 3 report provides the same level of assurance about controls over security, availability, processing integrity, confidentiality and/or privacy as a SOC 2 report. The key difference is that a SOC 3 report is intended for general release and does not include the detailed description of the testing performed by the auditor. In place of the detailed description a summary opinion regarding the effectiveness of the controls in place at the data centre or service organisation is provided.

SOC Reports Summary

• The description fairly presents the service organisation's system;
• That the control objectives were suitably designed (SSAE 16 Type 1) and operating effectively (SSAE 16 Type 2) during the dates and/or periods covered by the report; and
• The criteria used for making these assertions, (which are additional statements with supporting matter regarding risk factors relating to control objectives and underlying controls) were in place (Type 1) and were consistently applied (Type 2).

• Stage 1 audit (also called Documentation review) checking the systems documentation is compliant with ISO 27001;
• Stage 2 audit (also called Main audit) checking that all the organisation’s activities are compliant with both ISO 27001 and the systems documentation.

1. Self-assessment;
2. Third party assessment based attestation or certification; and
3. Continuous monitoring based certification.

Note: Agencies should note that a self-assessment does not necessarily provide substantive assurance.

• Greater dependency on third parties;
• Increased complexity of compliance with national and international laws and regulations;
• Reliance on the Internet as the primary conduit to the enterprise’s data; and
• Risk due to the dynamic nature of cloud computing.

• The governance affecting cloud computing;
• The contractual compliance between the service provider and customer;
• Privacy and regulation issues concerning cloud computing; and
• Cloud computing specific attention points.

The FedRAMP programme is run by the FedRAMP Program Management Office as part of the GSA.

1. Security Assessment: The security assessment process uses a standardised set of requirements in accordance with FISMA using a baseline set of NIST 800-53 controls with additional controls specific to cloud deployments, in order to grant security authorisations. Cryptographic elements are governed by the FIPS 140-2 standards.
   
   
2. Leveraging and Authorisation: Federal agencies view security authorisation packages in the FedRAMP repository and leverage the security authorisation packages to grant a security authorisation at their own agency.
   
   
3. Ongoing Assessment & Authorisation: Once an authorisation is granted, ongoing assessment and authorisation activities are required to maintain the security authorisation.

Understanding the business and technical risk context will drive the size and depth of a risk assessment, and the associated assurance process. Though even a lighter-weight risk assurance process will follow the C&A process model, such that the CE or authorised delegate is still formally accountable and responsible.

Re-use of assessments completed by other agencies is encouraged, noting the business or information value context may differ. To assist agencies and promote efficiency, the Government Chief Digital Officer (GCDO) facilitates the sharing and re-use of existing cloud assessment materials among agencies.

1. The sensitivity of information on the agency’s systems, including financial data, medical information, proprietary information, customer data or other personal information.
2. Security safeguards that are already in place on the system, such as encryption of data at rest.
3. The agency’s ability to segment its network or otherwise segregate sensitive information stored on its systems.
4. Regulatory, contractual, privacy or other restrictions placed on disclosure of protected classes of information (such as within the New Zealand Classification System).

• Chapter 4 - System Certification and Accreditation;
• Chapter 5 – Information Security Documentation;
• Section 6.2 - Vulnerability Analysis;
• Section 6.3 - Change Management;
• Chapter 7 – Information Security Incidents;
• Section 12.4 – Product Patching and Updating;
• Chapter 14 - Software Security.

• A scoping statement setting out which systems the policy applies to (e.g. the agency’s website and other public-facing systems);
• Details of how finders can contact the agency’s security team (including any public keys for encrypting reports);
• Permitted activities;
• Acknowledgement of reports and a response time (typically 60 or 90 days) for corrections, adjustments, or other “fixes”;
• Reporters/finders agreeing to not share information about the vulnerability until the end of the disclosure period, to let the organisation fix the issues before it becomes public;
• Illegal activities are not permitted (specifying any relevant legislation, such as the Crimes Act, the Privacy Act etc.); and
• Either a statement that bug bounties will not be paid for any discoveries, or information about the agency’s bug bounty programme.

• the scope of public-facing systems covered by its VDP; and
• the nature of vulnerabilities which can be reported under its VDP.

• A scoping statement listing the systems the policy applies to;
• Contact details;
• Secure communication options (including any public keys);
• Information the finder should include in the report;
• Acknowledgement of reports and a response time;
• Guidance on what forms of vulnerability testing are out of scope for reporters/finders (permitted activities);
• Reporters/finders agreeing to not share information about the vulnerability until the end of the disclosure period, in order to allow the agency to address any issues before they become public;
• Illegal activities are not permitted (specifying the relevant legislation, such as the Crimes Act); and
• Either that “Bug bounties” will not be paid for any discoveries, or it should provide information about the agency’s bug bounty programme.

• identifies any changes to the business requirements or concept of operation for the subject of the review;
• identifies any changes to the security risks faced by the subject of the review;
• assesses the effectiveness of the existing counter-measures;
• validates the implementation of controls and counter-measures; and
• reports on any changes necessary to maintain an effective security posture.

• as a result of a specific information security incident;
• because a change to a system or its environment that significantly impacts on the agreed and implemented system architecture and information security policy; or
• as part of a regular scheduled review.

• agency priorities, business requirements and/or concept of operations;
• threat data;
• risk likelihood and consequence estimates;
• effectiveness of existing counter-measures;
• other possible counter-measures; 
• changes to standards, policies and guidelines;
• recommended good practices; and
• significant system incidents and changes.

• monitoring public domain information about new vulnerabilities in operating systems and application software;
• considering the use of automated tools to perform vulnerability assessments on systems in a controlled manner;
• running manual checks against system configurations to ensure that only allowed services are active and that disallowed services are prevented; 
• using security checklists for operating systems and common applications; and
• examining any significant incidents on the agency’s systems.

• before a system is first used;
• after any significant incident;
• after a significant change to the system;
• after changes to standards, policies and guidelines; 
• when specified by an ITSM or system owner.

• system users identifying problems or enhancements;
• vendors notifying of upgrades to software or IT equipment;
• vendors notifying of the end of life to software or IT equipment;
• advances in technology in general;
• implementing new systems that necessitate changes to existing systems;
• identifying new tasks or functionality requiring updates or new systems;
• organisational change;
• business process or concept of operation change;
• standards evolution;
• government policy or Cabinet directives;
• threat or vulnerability identification and notifications received or issued; and
• other incidents or continuous improvement activities.

• an upgrade to, or introduction of IT equipment;
• an upgrade to, or introduction of software;
• environment or infrastructure change; or
• major changes to access controls.

• the change management process, as defined in the relevant information security documentation, is followed;
• the proposed change is approved by the relevant authority;
• any proposed change that could impact the security or accreditation status of a system is submitted to the Accreditation Authority for approval; and
• all associated information security documentation is updated to reflect the change.

• the change management process, as defined in the relevant information security documentation, is followed;
• the proposed change is approved by the relevant authority;
• any proposed change that could impact the security of a system or accreditation status is submitted to the Accreditation Authority for approval; and
• all associated information security documentation is updated to reflect the change.

• produce a written change request;
• submit the change request to all stakeholders for approval;
• document the changes to be implemented;
• test the approved changes;
• notification to user of the change schedule and likely effect or outage;
• implement the approved changes after successful testing;
• update the relevant information security documentation including the SRMP, SSP and SOPs
• notify and educate system users of the changes that have been implemented as close as possible to the time the change is applied; and
• continually educate system users in regards to changes.

• Identify vital records;
• backup all vital records;
• store copies of critical information, with associated documented recovery procedures, offsite and secured in accordance with the requirements for the highest classification of the information; and
• test backup and restoration processes regularly to confirm their effectiveness.

• Section 5.9 - Vulnerability Disclosure Policy;
• Section 6.1 - Information Security Reviews;
• Section 6.2 - Vulnerability Analysis;
• Section 7.2 – Reporting Information Security Incidents;
• Section 7.3 – Managing Information Security Incidents;
• Section 9.1 - Information Security Awareness and Training;
• Section 16.6 - Event Logging and Auditing;
• Section 17.9 – Key Management; and
• Section 18.4 - Intrusion Detection and Prevention.

1. Personnel should be well trained and aware of information security issues.
2. Automated incident detection tools should be utilised to assist in developing use cases and a known baseline. Management and operation of the tools should be undertaken by experienced information security personnel.

• user awareness and training;
• counter-measures against malicious code, known attack methods and types;
• intrusion detection strategies;
• data egress monitoring & control;
• access control anomalies;
• audit analysis;
• system integrity checking; and
• vulnerability assessments.

• user awareness and training;
• counter-measures against malicious code, known attack methods and types;
• intrusion detection strategies;
• dynamic network defence (i.e. protective DNS and/or NGFW)
• data egress monitoring & control;
• access control anomalies;
• audit analysis;
• system integrity checking; and
• vulnerability assessments.

1. Critical: Incident affecting critical systems or information with potential to impact operations, revenue, customers or information disclosed in data breach.
   For example, distributed denial of service attack, unauthorised access to system, multi-system ransomware.
   
   
2. Serious: Incident affecting noncritical systems or information, impact on operations, revenue, customers or information disclosed in data breach.
   For example, execution of malware on a single system, potentially compromised credentials.
   
   
3. Low: Possible incident affecting noncritical systems.  Incidents or employee investigations that are not time sensitive. 
   For example, blocked phishing attempts.

• Whether the incident affects a single agency or multiple agencies;
• Functional impact of the incident (availability);
• Information impact of the incident (confidentiality, integrity);
• Recoverability from the incident;
• Whether a breach of personal information held by the agency has occurred;
• Whether unauthorised access to agency information systems may have occurred;
• Reputational risk to the agency;
• Impact on any MOUs, MOAs and similar formal agreements;
• Impact on the disclosure of information theft of data.

• encourage personnel to note and report any observed or suspected security weaknesses in, or threats to, systems or services;
• establish and follow procedures for reporting system, software or other malfunctions;
• put mechanisms in place to enable the types, volumes and costs of information security incidents and malfunctions to be quantified and monitored; and
• deal with the violation of agency information security policies and procedures by personnel through training and, where warranted, a formal disciplinary process.

The CISO is required to keep the CSO and/or Agency Head informed of information security incidents within their agency. 

Reporting on incidents categorised as Low can usually be adequately managed through periodic (weekly or monthly) reports. 

Reporting of Critical or Serious information security incidents to the NCSC through the appropriate channels ensures that appropriate and timely assistance can be provided to the agency.   In addition, it allows the NCSC to maintain an accurate threat environment view across government systems.

• Critical;
• Serious; or
• incidents related to multi-agency or government systems;

to the NCSC as soon as possible.

A Report Form is provided on the NCSC website under Reporting an Incident at Report an incident and request support | National Cyber Security Centre

A Report Form is provided on the NCSC website under Reporting an Incident at Report an incident and request support | National Cyber Security Centre

For example, Data Loss Prevention (DLP) techniques and tools such as network activity monitoring, endpoint DLP tools, data classification can aid in detecting and preventing data spills or data breaches.

• all personnel with access to systems; 
• notification to the ITSM of any data spillage or breaches; and
• notification to the ITSM of access to any data which they are not authorised to access.

1. Immediately seek the advice of an ITSM;
2. Segregate or isolate the affected system and/or data spill;
3. Personnel MUST NOT delete the higher classified information unless specifically authorised by an ITSM.

• the infection date/time of the machine;
• any observed effects and source details;
• the possibility that system records and logs could be compromised; and
• the period of infection.

• Isolation of infected systems to prevent further spread. Check connected systems and media for infections and isolate as required;
• Removal of the malicious code should be performed with appropriate malware removal tools; 
• Eradication and recovery in some cases would require restoring systems with original media.

•       isolate the infected system;
• decide whether to request assistance from NCSC;
• if such assistance is requested and agreed to, delay any further action until advised by NCSC;
• check connected systems and media including backups for malicious code; 
• isolate all infected systems and media to prevent reinfection;
• change all passwords and key material stored or potentially accessed from compromised systems, including any websites with password controlled access;
• advise system users of any relevant aspects of the compromise, including a recommendation to change all passwords on compromised systems;
• revoke all session tokens associated with user and/or device;
• use up-to-date anti-malware software to remove the malware from the systems or media;
• monitor network traffic for malicious activity;
• record and report the information security incident and perform any other activities specified in the IRP; and
• in certain scenarios rebuilding and reinitialising the system and/or user profile may be required.

• transfer a copy of raw audit trails and other relevant data onto media for secure archiving, as well as securing manual log records for retention; and
• ensure that all personnel involved in the investigation maintain a record of actions undertaken to support the investigation.

Typically the layers of security are:

• site;
• building;
• room;
• racks;
• approved containers;
• operational hours; and
• staffing levels.

• a summary of the security risk review for the facility the server or communications room is located in;
• roles and responsibilities of facility and security personnel;
• the administration, operation and maintenance of the electronic access control system or security alarm system;
• key management, the enrolment and removal of system users and issuing of personal identification number codes and passwords;
• personnel security clearances, security awareness training and regular briefings;
• regular inspection of the generated audit trails and logs;
• end of day checks and lockup;
• reporting of information security incidents; and
• what activities to undertake in response to security alarms.

• Section 11.2 - Fax Machines, Multifunction Devices and Network Printers;
• Chapter 12 - Product Security; and
• Chapter 13 – Decommissioning and Disposal.

• ensuring IT equipment always reside in an appropriate class of secure room;
• storing IT equipment during non-operational hours in an appropriate class of security container or lockable commercial cabinet;
• using IT equipment with removable non-volatile media which is stored during non-operational hours in an appropriate class of security container or lockable commercial cabinet as well as securing its volatile media;
• using IT equipment without non-volatile media as well as securing its volatile media;
• using an encryption product to reduce the physical storage requirements of the non-volatile media as well as securing its volatile media; or
• configuring IT equipment to prevent the storage of classified information on the non-volatile media when in use and enforcing scrubbing of temporary data at logoff or shutdown as well as securing its volatile media.

• assess the security risks associated with such a decision; and
• specify the processes and conditions for their application within the system’s SSP.

• an attacker gaining access to the IT equipment immediately after power is removed and accessing the contents of volatile media to recover encryption keys or parts thereof. This is sometimes described as a data remanence attack;
• extreme environmental conditions causing data to remain in volatile media for extended periods after the removal of power; and
• the physical security of the locations in which the IT equipment will reside.

• disconnect power from the equipment the media resides within;
• assess the security risks if not sanitising the media; and
• specify any additional processes and controls that will be applied within the system’s SSP.

• issue and usage details of seals and associated tools;
• serial numbers of all seals purchased; and
• the location or asset on which each seal is used.

• issue and usage details of seals and associated tools;
• serial numbers of all seals purchased; and
• the location or asset on which each seal is used.

• become familiar with their roles and responsibilities;
• understand any legislative or regulatory mandates and requirements;
• understand any national or agency policy mandates and requirements;
• understand and support security requirements; 
• assist in maintaining security; and
• learn how to fulfil their security responsibilities.

• the purpose of the training or awareness program;
• any legislative or regulatory mandates and requirements;
• any national or agency policy mandates and requirements;
• agency security appointments and contacts;
• the legitimate use of system accounts, software and classified information;
• the security of accounts, including shared passwords;
• authorisation requirements for applications, databases and data;
• the security risks associated with non-agency systems, particularly the Internet;
• reporting any suspected compromises or anomalies;
• reporting requirements for information security incidents, suspected compromises or anomalies;
• classifying, marking, controlling, storing and sanitising media;
• protecting workstations from unauthorised access;
• informing the support section when access to a system is no longer needed; 
• observing rules and regulations governing the secure operation and authorised use of systems; and
• supporting documentation such as SOPs and user guides.

• tamper with the system;
• bypass, strain or test information security mechanisms;
• introduce or use unauthorised IT equipment or software on a system;
• replace items such as keyboards, pointing devices and other peripherals with personal equipment;
• assume the roles and privileges of others;
• attempt to gain access to classified information for which they have no authorisation; or
• relocate equipment without proper authorisation.

1. for information classified CONFIDENTIAL and above; and
2. for information classified RESTRICTED and below.

• limit system access on a need-to-know/need-to-access basis;
• provide system users with the least amount of privileges needed to undertake their duties; and
• have any requests for access to a system authorised by the supervisor or manager of the system user.

• limit system access on a need-to-know/need-to-access basis;
• provide system users with the least amount of privileges needed to undertake their duties;
• have any requests for access to a system authorised by the supervisor or manager of the system user; and
• ensure a formal acknowledgement of the security briefing is obtained and recorded.

• maintain a secure record of:
  • all authorised system users;
  • their user identification;
  • why access is required;
  • role and privilege level,
  • who provided the authorisation to access the system;
  • when the authorisation was granted; and
• keep a copy of the acknowledgement signed by the individual granted a clearance; and
• maintain the record, for the life of the system or information to which access is granted, or the length of employment, whichever is the longer.

• hold a security clearance or other authorisation appropriate for the system classification; or
• have been granted access in accordance with the requirements in the PSR for emergency access.

• the requirement to grant limited higher access is temporary in nature and is an exception rather than the norm;
• an ITSM has recommended the limited higher access;
• a cessation date for limited higher access has been set;
• the access period does not exceed two months;
• the limited higher access is granted on an occasional NOT non-ongoing basis;
• the system user is not granted privileged access to the system;
• the system user’s access is formally documented; and
• the system user’s access is approved by the CISO.

• the approval for access is formally acknowledged and recorded; and either
  • effective controls are in place to restrict access only to classified information that is necessary to undertake the system user’s duties; or
  • the system user is continually supervised by another system user who has the appropriate security clearances to access the system.

• the requirements to grant emergency access is due to an immediate and critical need to access classified information and there is insufficient time to complete clearance procedures;
• the agency head or their delegate has approved the emergency access;
• the system user’s access is formally documented;
• the system user’s access is reported to the CISO; 
• appropriate briefs and debriefs for the information and system are conducted;
• access is limited to information and systems necessary to deal with the particular emergency and is governed by strict application of the “need to know” principle; 
• emergency access is limited to ONE security clearance level higher than the clearance currently held; and
• the security clearance process is completed as soon as possible.

• photographs;
• past and present employment details;
• personal details, including DOB, family members, birthdays, address and contact details;
• schools and institutions;
• clubs, hobbies and interests;
• educational qualifications;
• current work duties;
• details of work colleagues and associates; and
• work contact details.

• name;
• organisation;
• person visiting;
• contact details for person visiting; and
• date and time in and out.

Figure 2: Typical Ribbon Cable

Figure 3: Jacket Cable                                              Figure 4: Loose Tube Cable

Figure 5: Infrastructure (High Cable Count) Ribbon Cable

                    Figure 6 - Armoured Ribbon Fibre Cable

• transmission media;
• topology;
• security required;
• access control;
• transmission technique; 
• transmission speed and capability.

• A non-shared facility is a facility occupied solely by a single agency.
• A shared facility is a facility occupied by more than one agency.  A shared facility should have stricter physical and technical security controls than a non-shared facility. 

• A shared facility is a facility occupied by more than one agency.  A shared facility should have stricter physical and technical security controls than a non-shared facility. 
• A non-shared facility is a facility occupied solely by a single agency.

• conduit inspection boxes;
• outlet and junction boxes; and
• T-pieces.

• cable identification number;
• classification;
• socket number, equipment type, source or destination site/floor plan diagram; and
• seal numbers if applicable.

• cable identification number;
• classification;
• socket number, equipment type, source or destination site/floor plan diagram; and
• seal numbers if applicable.

• Section 8.5 – Tamper-evident seals;
• Section 10.1 – Cable management fundamentals;
• Section 10.7 – Emanation Security Threat Assessments.

• Chassis or frame;
• Drawer to facilitate access for installation and maintenance;
• Cassette;
• Coupler panels (adapter panels) – to hold the connector couplers;
• The connector couplers (connector adapters);
• Splice tray – organises and secures splice modules;
• Patch cable management trays.

• Accidently not being able to locate end points of network and patch cables without tracing the cable end to end.
• Physically impeding access to equipment.
• Positioning of equipment and cables such that airflow (cooling) is impeded.  As the density of equipment in racks increases, cooling becomes an increasingly important factor.  Poor rack design combined with dense rack utilization can contribute to internal rack temperatures significantly higher than ambient room temperatures.

Figure 11: Separation of RED/BLACK

This requirement should be identified before installation takes place and segregation measures implemented.  Ideally physical separation of BLACK from RED is the best solution, recognising however, this may not always be possible or practical. Other solutions may include, for example, a shared rack that has two doors with the RED door locked and alarmed so that BLACK equipment can be accessed without compromising the security of RED equipment.  Discussion with the GCSB may identify other practical solutions.

• inadvertent or deliberate access to information and systems by non-cleared personnel; and/or
• information spilling to a system of another classification.

• reduce or eliminate the chances of cross patching between the systems; and
• reduce or eliminate the possibility of unauthorised personnel or personnel gaining access to classified system elements.

Refer also to 10.1 – Cable Management Fundamentals for the discussion on RED/BLACK concept and cable separation.

• provide a physical barrier within the cabinet to separate patch panels;
• ensure that only personnel cleared to the highest classification of the circuits in the panel have access to the cabinet; and
• obtain approval from the relevant Accreditation Authority prior to installation.

• RED equipment at the top;
• BLACK equipment in the centre;
• Power equipment at the bottom.

• do not exceed 5m in length; or
• if they exceed 5m in length:
  • are run in the facility’s fixed infrastructure in a protective and easily inspected pathway;
  • are clearly labelled at the equipment end with the wall outlet designator; and
  • are approved by the Accreditation Authority.

• provide adequate room for patch cables and wire managers;
• provide adequate space for cable management at front, sides, and rear; and
• arrange switches and patch panels to minimize patching between cabinets & racks.

• Labelling is logical and consistent, across all locations, matching the project drawings;
• The labelling scheme identifies any associated physical locations (building, room, cabinet, rack, port, etc.);
• Labelling is easily read, durable, and capable of surviving for the life of the component that was labelled;
• The labelling system, and the identifiers used, are agreed upon by all stakeholders; and
• Labelling is all-encompassing and include cables, connecting hardware, conduits, firestops, grounding and bonding locations, racks, cabinets, ports, and telecommunications spaces.

• All labels use a permanent identifier;
• The labelling/numbering scheme is logical in its organisation, using alphanumeric characters for ease of reference;
• Each cable and each pathway is labelled on each end, and each label identifies the termination points of both ends of the cable;
• All labels are legible, defacement resistance, and have high adhesion characteristics and durability;
• Labels are placed so they can be read without disconnecting a cable;
• Labels for station connections may appear on the face plate;
• All jack, connector, and block hardware are be labelled on either the outlet or panel; and
• All labels match with the any installation and maintenance records.

• Label power cords at both ends to minimise the risk inadvertently disconnecting the wrong power cord;
• Colour code power cords and power strips;
• Use locking power cords, receptacles, or retention clips.

• agencies located outside New Zealand;
• secure facilities within New Zealand; and
• mobile platforms and deployable assets that process classified information.

• contact GCSB for guidance on conducting an emanation security threat assessment; and
• install cabling and equipment in accordance with this manual plus any specific installation criteria derived from the emanation security threat assessment.

• contact GCSB for guidance on conducting an emanation security threat assessment; and
• install cabling and equipment in accordance with this manual plus any specific installation criteria derived from the emanation security threat assessment.