Change Management policy - Application Security Scope
Change Management
Changes to information resources shall be managed and executed according to a formal change control process. The control process will ensure that changes proposed are reviewed, authorized, tested, implemented, and released in a controlled manner; and that the status of each proposed change is monitored.
Responsibility – To help ensure the security of the network and IT resources, the IT Department shall manage and monitor all installations, upgrades, development, and deployment of software approved for use in the organization. All hardware and software used in the organization must be approved by Management prior to being placed into production. Any applications and/or operating systems for operational use in the production environment must be successfully tested for usability, security, and impact prior to migration. Testing must be conducted in a logically and physically segregated environment.
Configuration Control – The Security Officer or their designee shall implement a configuration control program to maintain control of all implemented software and its system documentation and archive prior versions of implemented software and associated system documentation.
Access Approval – Only authorized administrators are permitted to approve and deploy upgrades to software, applications, and program libraries based on business requirements and security implications.
Documentation – All system changes (hardware, applications, major software upgrades, etc.) shall be fully documented using change management software that will record business needs, development activities, developer/QA testing activities, proper approvals and authorizations, and details of the migration to production.
Procedures
Operational Procedures
The change control process shall be formally defined and documented. A change control process shall be in place to control changes to all critical company information resources (such as hardware, software, system documentation, and operating procedures). This documented process shall include management responsibilities and procedures. Wherever practicable, operational and application change control procedures should be integrated.
At a minimum the change control process should include the following phases:
Logged Change Requests
Identification, prioritization, and initiation of change
Proper authorization of changes
Requirements analysis
Inter-dependency and compliance analysis
Impact Assessment
Change approach
Change testing
User acceptance testing and approval
Implementation and release planning
Documentation
Change monitoring
Defined responsibilities and authorities of all users and IT personnel
Emergency change classification parameters
Documented Change
All change requests shall be logged whether approved or rejected on a standardized and central system. The approval of all change requests and the results thereof shall be documented.
A documented audit trail, maintained at a Business Unit Level, containing relevant information shall be maintained at all times. This should include change request documentation, change authorization, and the outcome of the change. No single person should be able to effect changes to production information systems without the approval of other authorized personnel.
Risk Management
A risk assessment shall be performed for all changes and dependent on the outcome, an impact assessment should be performed.
The assessment shall include the potential effect on other information resources and potential cost implications, including but not limited to, any impact on commitments made by the organization to customers or users of the system. The impact assessment should, where applicable, consider compliance with legislative requirements and standards.
Change Classification
All change requests shall be prioritized in terms of the benefits, urgency, effort required, and potential impact on operations.
Testing
Changes shall be tested in an isolated, controlled, and representative environment (where such an environment is feasible) prior to implementation to minimize the effect on the relevant business process, assess its impact on operations and security, and verify that only the intended and approved changes were made.
Changes Affecting SLAs
The impact of change on existing SLAs shall be considered. Where applicable, changes to the SLA shall be controlled through a formal change process that includes contractual amendments.
Version Control
Any software change and/or update shall be controlled with version control. Older versions shall be retained in accordance with corporate retention and storage management policies (HITRUST requires a minimum of six years).
Approval
All changes shall be approved prior to implementation. Approval of changes shall be based on formal acceptance criteria i.e. the change request was done by an authorized user, the impact assessment was performed, and proposed changes were tested.
Communicating Changes
All users, significantly affected by a change, shall be notified of the change. The user representative shall sign-off on the change. Users shall be required to make submissions and comments prior to the acceptance of the change.
Implementation
Implementation will only be undertaken after appropriate testing and approval by stakeholders. All major changes shall be treated as new system implementation and shall be established as a project. Major changes will be classified according to the effort required to develop and implement. When feasible, implementation of changes to production systems shall be conducted by personnel not involved in development or testing activities (e.g. separation of duties).
Roll Back
Procedures for aborting and recovering from unsuccessful changes shall be documented to help ensure that systems can revert to a previous stable state. Should the outcome of a change be different from the expected result (as identified in the testing of the change), procedures and responsibilities shall be noted for the recovery and continuity of the affected areas.
Documentation
Information resources documentation shall be updated on the completion of each change and old documentation shall be archived or disposed of as per the documentation and data retention policies.
Information resources documentation is used for reference purposes in various scenarios i.e. further development of existing information resources as well as ensuring adequate knowledge transfer in the event of the original developer and/or development house being unavailable. It is therefore imperative that information resources documentation is complete, accurate, and kept up to date with the latest changes. Policies and procedures, affected by software changes, shall be updated on completion of each change.
Business Continuity Plans (BCP)
Business continuity plans shall be updated with relevant changes and managed through the change control process. Business continuity plans rely on the completeness, accuracy, and availability of BCP documentation. BCP documentation is the road map used to minimize disruption to critical business processes where possible and to facilitate their rapid recovery in the event of disasters.
Emergency Changes
Specific procedures to ensure the proper control, authorization, and documentation of emergency changes shall be in place. Specific parameters will be defined as a standard for classifying changes as Emergency changes.
Only appropriate IT personnel have the authority to initiate emergency changes. Emergency changes are required to retroactively follow the standard change control process within a two-day period of the issue is resolved. Emergency changes must be communicated to all affected parties.
The Emergency Change workflow is a relatively simple one that requires approval from a member of the E-CAB in order to proceed. Some Emergency Changes may require custom tasks to be created before approval is sought. The detailed workflow below:
Change Monitoring
All changes will be monitored once they have been rolled out to the production environment. Deviations from design specifications and test results will be documented and escalated to the solution owner for ratification.
Development Environment
A test/development environment, separate from the production environment, must be used to test changes. If the test/development environment has network connectivity to the production network, access controls must be in place to enforce the separation.
Production data will not be used for testing and development purposes without being sanitized. Test personnel should make every effort to use mock data only for testing on non-production systems and software.
All test data, custom application accounts, usernames, and passwords must be removed at the conclusion of testing, and in all cases before software becomes active.
All promotion to the production environment will be accomplished by authorized System Administrators.