Policy 7230A - Department of Administration

Policy 7230A - Department of Administration Policy 7230A - Department of Administration

10.10.2014 Views

• Adjust baseline impacts according to organization specific requirements. 5.1.2.4 Assign Security Categorization to Each Information Type Complete information categorization by aggregating the security impact level for each information type across all three factors according to the highest impact level assigned: 5.1.2.5 Assign Aggregate Security Categorization to Each Information System Finalize the categorization process by assigning a security categorization to each information system according to the security categorization of the information stored or processed by the system: • For systems that house only a single type of information, assign a security categorization equivalent to that assigned to the information type. • For information systems that house multiple types of information, assign a security categorization equivalent to the highest assigned to any of the information types. 5.1.3. Follow Process for Change Control To ensure that the security that is engineered into systems and system components is maintained long term, Agencies should perform changes to those systems and components in a controlled manner: 5.1.3.1 Initiate Changes via Formal Request To properly control changes, requests must be made formally to allow for thorough review as well as the updating of both systems and documentation: • Ensure that appropriate documentation is assembled prior to request initiation including release notes, installation guides and any documented test results. • Submit a change request indicating the nature of the change and appropriate consent. 5.1.3.2 Perform Impact Analysis on Change Prior to completing implementation plans, risks associated with the change must be assessed and any inappropriate risks must be then mitigated: • Establish the existence of any dependencies that may have an impact on or be impacted by the change. • Identify and mitigate risks associated with the change. 14

5.1.3.3 Provide Implementation Documentation To ensure that changes are executed in a controlled manner, formal documentation that outlines roles, responsibilities and required tasks must be created and vetted by all stakeholders (see section 6.3.1 of these Non-Mandatory Procedures). 5.1.3.4 Execute Controlled Test of the Change Where appropriate test and development facilities exist, the change should be executed in this environment to validate the plan and identify any gaps: • Configure the test environment to mimic the to be changed production environment as much as possible including up and down stream dependent systems. • Execute the implementation in the controlled environment, noting any deficiencies with the set plan. • Update the plan as required reflecting lessons learned from the test implementation. 5.1.3.5 Implement the Change per the Plan Execute the change according to the outlined and vetted plan: • Implement tasks and communications as outlined in the plan. • Escalate where implementation errors or plan deficiencies are noted. • Upon completion of change update the Systems Inventory (see section 5.1.1 of these Non-Mandatory Procedures). 5.1.3.6 Perform Post-Implementation Validation and Review Once the change is finished, all systems impacted must be verified as appropriately functional and a post-implementation review completed: • Validate that the implementation has achieved the required change and has not yielded any unexpected results. • Perform a post implementation review to identify any lessons learned and to debrief staff around any deficiencies in the plan that had to be addressed during the implementation. 5.2. Systems Protection No applicable Non-Mandatory Procedures. 15

5.1.3.3 Provide Implementation Documentation<br />

To ensure that changes are executed in a controlled manner, formal<br />

documentation that outlines roles, responsibilities and required tasks<br />

must be created and vetted by all stakeholders (see section 6.3.1 <strong>of</strong><br />

these Non-Mandatory Procedures).<br />

5.1.3.4 Execute Controlled Test <strong>of</strong> the Change<br />

Where appropriate test and development facilities exist, the change<br />

should be executed in this environment to validate the plan and<br />

identify any gaps:<br />

• Configure the test environment to mimic the to be changed<br />

production environment as much as possible including up and<br />

down stream dependent systems.<br />

• Execute the implementation in the controlled environment,<br />

noting any deficiencies with the set plan.<br />

• Update the plan as required reflecting lessons learned from<br />

the test implementation.<br />

5.1.3.5 Implement the Change per the Plan<br />

Execute the change according to the outlined and vetted plan:<br />

• Implement tasks and communications as outlined in the plan.<br />

• Escalate where implementation errors or plan deficiencies are<br />

noted.<br />

• Upon completion <strong>of</strong> change update the Systems Inventory<br />

(see section 5.1.1 <strong>of</strong> these Non-Mandatory Procedures).<br />

5.1.3.6 Perform Post-Implementation Validation and Review<br />

Once the change is finished, all systems impacted must be verified as<br />

appropriately functional and a post-implementation review<br />

completed:<br />

• Validate that the implementation has achieved the required<br />

change and has not yielded any unexpected results.<br />

• Perform a post implementation review to identify any lessons<br />

learned and to debrief staff around any deficiencies in the<br />

plan that had to be addressed during the implementation.<br />

5.2. Systems Protection<br />

No applicable Non-Mandatory Procedures.<br />

15

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!