<section title="4.4. Accreditation Framework"><subsection title="Objective"><paragraph
    title="4.4.1."


><![CDATA[<p>Accreditation is the formal authority for a system to operate, and an important element in fundamental information system governance. Accreditation requires risk identification and assessment, selection and implementation of baseline and other appropriate controls and the recognition and acceptance of residual risks relating to the operation of a system including any outsourced services such as Telecommunications or Cloud. Accreditation relies on the completion of system certification procedures.</p>]]></paragraph>
 </subsection>
<subsection title="Context"> <block title="Scope"><paragraph
    title="4.4.2."


><![CDATA[<p>This section covers information on the accreditation framework for systems.</p>]]></paragraph>
<paragraph
    title="4.4.3."


><![CDATA[<p>All types of government held information are covered, including Official Information and information subject to privacy requirements.</p>]]></paragraph>
</block>
</subsection>
<subsection title="Rationale &amp; Controls"> <block title="Accreditation framework"><paragraph
    title="4.4.4.R.01."

    tags="Governance,Accreditation"


><![CDATA[<p>The development of an accreditation framework within the agency will ensure that accreditation activities are conducted in a repeatable and consistent manner across the agency and that consistency across government systems is maintained. This requirement is a fundamental part of a robust governance model and provides a sound process to demonstrate good governance of information systems.</p>]]></paragraph>
<paragraph
    title="4.4.4.C.01."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must"
    cid="595"
><![CDATA[<p>Agencies MUST develop an accreditation framework for their agency.</p>]]></paragraph>
</block>
<block title="Accreditation"><paragraph
    title="4.4.5.R.01."

    tags="Governance,Accreditation"


><![CDATA[<p>Accreditation ensures that either sufficient security measures have been put in place to protect information that is processed, stored or communicated by the system or that deficiencies in such measures have been identified, assessed and acknowledged by an appropriate authority. As such, when systems are awarded accreditation the Accreditation Authority accepts that the residual security risks relating to the system are appropriate for the information that it processes, stores or communicates.</p>]]></paragraph>
<paragraph
    title="4.4.5.R.02."

    tags="Governance,Accreditation"


><![CDATA[<p>Once systems have been accredited, conducting on-going monitoring activities will assist in assessing changes to its environment and operation and to determine the implications for the security risk profile and accreditation status of the system.</p>]]></paragraph>
<paragraph
    title="4.4.5.C.01."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must"
    cid="599"
><![CDATA[<p>Agencies MUST ensure that each of their systems is awarded accreditation.</p>]]></paragraph>
<paragraph
    title="4.4.5.C.02."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must"
    cid="600"
><![CDATA[<p>Agencies MUST ensure that all systems are awarded accreditation before they are used operationally.</p>]]></paragraph>
<paragraph
    title="4.4.5.C.03."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must"
    cid="601"
><![CDATA[<p>Agencies MUST ensure that all systems are awarded accreditation prior to connecting them to any other internal or external system.</p>]]></paragraph>
<paragraph
    title="4.4.5.C.04."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Should"
    cid="602"
><![CDATA[<p>Agencies SHOULD ensure information security monitoring, logging and auditing is conducted on all accredited systems.</p>]]></paragraph>
</block>
<block title="Determining authorities"><paragraph
    title="4.4.6.R.01."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>Determining the certification and accreditation authorities for multi-national and multi-agency systems via a formal agreement between the parties will ensure that the system owner has identified appropriate points of contact and that risk is appropriately managed. See Section 4.5 – Conducting Accreditations.</p>]]></paragraph>
<paragraph
    title="4.4.6.C.01."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Should"
    cid="605"
><![CDATA[<p>For multi-national and multi-agency systems, the Certification and Accreditation Authorities SHOULD be determined by a formal agreement between the parties involved.</p>]]></paragraph>
</block>
<block title="Notifying authorities"><paragraph
    title="4.4.7.R.01."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>In advising the certification and accreditation authorities of their intent to seek certification and accreditation for a system, the system owner can request information on the latest processes and requirements for their system.</p>]]></paragraph>
<paragraph
    title="4.4.7.C.01."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Should"
    cid="608"
><![CDATA[<p>Prior to beginning the accreditation process the system owner SHOULD advise the certification and accreditation authorities of their intent to seek certification and accreditation for their system.</p>]]></paragraph>
<paragraph
    title="4.4.7.C.02."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Should"
    cid="609"
><![CDATA[<p>Agencies SHOULD confirm governance arrangements with the certification authorities, and with the accreditation authorities.</p>]]></paragraph>
</block>
<block title="Due diligence"><paragraph
    title="4.4.8.R.01."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>When an agency is connecting a system to another party they need to be aware of the security measures the other party has implemented to protect their information. More importantly, the agency needs to know where the other party may have varied from controls in this manual. This is vital where different classification systems are applied, such as in the use of multiple national classification systems.</p>]]></paragraph>
<paragraph
    title="4.4.8.R.02."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>Methods that an agency may use to ensure that other agencies and third parties comply with the agency’s information security expectations include:</p><ul>
<li>assurance and confirmation that the certification and accreditation process described in the NZISM is adhered to;</li>
<li>conducting or utilising any third party reviewed assurance reports;</li>
<li>conducting an accreditation of the system being connected to; and/or</li>
<li>seeking a copy of existing accreditation deliverables in order to make their own accreditation determination.</li>
</ul>]]></paragraph>
<paragraph
    title="4.4.8.R.03."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>Ultimately, the agency MUST accept any security risks associated with connecting their system to the other party’s system. This includes the risks of other party’s system potentially being used as a platform to attack their system or “spilling” information requiring subsequent clean up processes.</p>]]></paragraph>
<paragraph
    title="4.4.8.R.04."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>Special care MUST be taken for multi- national, multi-agency and All-of-Government systems.</p>]]></paragraph>
<paragraph
    title="4.4.8.C.01."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Must"
    cid="615"
><![CDATA[<p>Where an agency’s system exchanges information with a third-party system, the agency MUST ensure that the receiving party has appropriate measures in place to provide a level of protection commensurate with the classification or privacy requirements of their information and that the third party is authorised to receive that information.</p>]]></paragraph>
<paragraph
    title="4.4.8.C.02."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Must"
    cid="616"
><![CDATA[<p>An agency MUST ensure that a third party is aware of the agency’s information security expectations and national security requirements by defining expectations in documentation that includes, but is not limited to:</p><ul>
<li>contract provisions; </li>
<li>a memorandum of understanding;</li>
<li>non-disclosure agreements.</li>
</ul>]]></paragraph>
<paragraph
    title="4.4.8.C.03."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Must"
    cid="617"
><![CDATA[<p>An agency MUST ensure that a third party complies with the agency’s information security expectations through a formal process providing assurance to agency management that the operation of information security within the third party meets, and continues to meet, these expectations.</p>]]></paragraph>
<paragraph
    title="4.4.8.C.04."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Should"
    cid="618"
><![CDATA[<p>Agencies SHOULD review accreditation deliverables when determining whether the receiving party has appropriate measures in place to provide a level of protection commensurate with the classification of their information.</p>]]></paragraph>
</block>
<block title="Processing restrictions"><paragraph
    title="4.4.9.R.01."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>When security is applied to systems, protective measures are put in place based on the highest classification that will be processed, stored or communicated by the system. As such, any classified information placed on the system above the level for which it has been accredited will receive an inappropriate level of protection and could be exposed to a greater risk of compromise.</p>]]></paragraph>
<paragraph
    title="4.4.9.C.01."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Must Not"
    cid="621"
><![CDATA[<p>Agencies MUST NOT allow a system to process, store or communicate classified information above the classification for which the system has received accreditation.</p>]]></paragraph>
</block>
<block title="Accrediting systems bearing a compartment marking"><paragraph
    title="4.4.10.R.01."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>When processing compartmented information on a system, agencies need to ensure that the system has received accreditation.</p>]]></paragraph>
<paragraph
    title="4.4.10.R.02."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>Compartments are invariably established for the additional protection of information of National security significance, over and above the protection provided by the primary classification.  It is extremely unlikely that such compartments would be established at a classification below CONFIDENTIAL.</p>]]></paragraph>
<paragraph
    title="4.4.10.C.01."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Must"
    cid="624"
><![CDATA[<p>A system that processes, stores or communicates compartmented information MUST be accredited by the GCSB.</p>]]></paragraph>
</block>
<block title="Requirement for New Zealand control"><paragraph
    title="4.4.11.R.01."

    tags="Governance,Accreditation,Certification"


><![CDATA[<p>NZEO systems process, store and communicate information that is particularly sensitive to the government of New Zealand. When agencies are dealing with New Zealand Eyes Only (NZEO) information they need to be aware of the requirement for a New Zealand national to remain in control of the system and information at all times. It is, therefore, essential that control of such systems is maintained by New Zealand citizens working for the government of New Zealand.</p>]]></paragraph>
<paragraph
    title="4.4.11.C.01."

    tags="Governance,Accreditation,Certification"


    classification="All Classifications"
    compliance="Must"
    cid="627"
><![CDATA[<p>Agencies MUST ensure that systems processing, storing or communicating NZEO information remain under the control of a New Zealand national working for the New Zealand government, at all times.</p>]]></paragraph>
</block>
<block title="Reaccreditation"><paragraph
    title="4.4.12.R.01."

    tags="Governance,Accreditation"


><![CDATA[<p>Agencies should reaccredit their systems at least every two years; however, they can exercise an additional one year’s grace if they follow the procedures in this manual for non-compliance with a ‘SHOULD’ requirement, namely conducting a comprehensive security risk assessment, obtaining sign-off by senior management and formal acceptance of residual risk.</p>]]></paragraph>
<paragraph
    title="4.4.12.R.02."

    tags="Governance,Accreditation"


><![CDATA[<p>Accreditations should be commenced at least six months before due date to allow sufficient time for the certification and accreditations processes to be completed. Once three years has elapsed between accreditations, the authority to operate the system (the accreditation) will lapse and the agency will need to either reaccredit the system or request a dispensation to operate without accreditation. It should be noted that operating a system without accreditation is considered extremely risky. This will be exacerbated when multiple agency or All-of-Government systems are involved.</p>]]></paragraph>
<paragraph
    title="4.4.12.R.03."

    tags="Governance,Accreditation"


><![CDATA[<p>Additional reasons for conducting reaccreditation activities could include:</p><ul>
<li>changes in the agency’s information security policies or security posture;</li>
<li>detection of new or emerging threats to agency systems;</li>
<li>the discovery that controls are not operating as effectively as planned; </li>
<li>a major information security incident; and</li>
<li>a significant change to systems, configuration or concept of operation for the accredited system.</li>
</ul>]]></paragraph>
<paragraph
    title="4.4.12.C.01."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must"
    cid="632"
><![CDATA[<p>Agencies MUST ensure that the period between accreditations of each of their systems does not exceed three years.</p>]]></paragraph>
<paragraph
    title="4.4.12.C.02."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must"
    cid="633"
><![CDATA[<p>Agencies MUST notify associated agencies where multiple agencies are connected to agency systems operating with expired accreditations.</p>]]></paragraph>
<paragraph
    title="4.4.12.C.03."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must"
    cid="634"
><![CDATA[<p>Agencies MUST notify the Government Chief Digital Officer (GCDO) where All-of-Government systems are connected to agency systems operating with expired accreditations.</p>]]></paragraph>
<paragraph
    title="4.4.12.C.04."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Must Not"
    cid="635"
><![CDATA[<p>Agencies MUST NOT operate a system without accreditation or with a lapsed accreditation unless the accreditation authority has granted a dispensation.</p>]]></paragraph>
<paragraph
    title="4.4.12.C.05."

    tags="Governance,Accreditation"


    classification="All Classifications"
    compliance="Should"
    cid="636"
><![CDATA[<p>Agencies SHOULD ensure that the period between accreditations of each of their systems does not exceed two years.</p>]]></paragraph>
</block>
</subsection>
</section>
