COBIT 2019: the clauses the checker cites

All requests for change are evaluated to determine their impact on business processes and I&T services and to assess whether the change will adversely affect the operational environment and introduce unacceptable risk, and changes are logged, prioritised, categorised, assessed, authorised, planned and scheduled: formal change requests let process owners and IT request changes to processes, infrastructure, systems or applications, with all changes arising only through the change management process and pre-screened for standard changes; requests are categorised (business process, infrastructure, operating systems, networks, applications, packaged software) and related to affected configuration items; they are prioritised on business and technical requirements, resources and legal, regulatory and contractual reasons; each change is formally approved by process owners, service managers and IT technical stakeholders as appropriate, with low-risk frequent changes pre-approved as standard; approved changes are planned and scheduled; every request is evaluated in a structured way with impact analysis on processes, infrastructure, systems, applications, continuity plans and service providers so that all affected components are identified; and the effect of contracted providers on change management is considered, including integration of their processes into the enterprise's.

Emergency changes are carefully managed to minimise further incidents, controlled and made securely, and assessed and authorised appropriately after the change: what constitutes an emergency change is defined; a documented procedure declares, assesses, preliminarily approves, authorises after the change and records emergency changes; all emergency access arrangements for changes are appropriately authorised, documented and revoked after the change is applied; and all emergency changes are monitored with post-implementation reviews involving all concerned parties, considering root causes such as problems with business processes, application development, infrastructure, testing or the environment and initiating corrective action.

A tracking and reporting system documents rejected changes and communicates the status of approved, in-process and complete changes, and approved changes are implemented as planned: requests are categorised in tracking (rejected, approved not yet initiated, approved and in process, closed); status reports with performance metrics let management review detailed status and the overall state such as aged analysis; open changes are monitored so approved changes close in a timely fashion by priority; and a tracking and reporting system covers all change requests.

Whenever changes are implemented, the solution, user documentation and procedures affected by the change are updated: documentation changes are included in the management procedure, including business and IT operational procedures, continuity and disaster recovery documentation, configuration information, application documentation, help screens and training materials; an appropriate retention period is defined for change documentation and pre- and post-change system and user documentation; and documentation is subjected to the same level of review as the change itself.

Changes are tested independently according to the defined test plan before migration to the live environment: the categorised log of errors found by the development team is reviewed to verify remediation or formal acceptance; final acceptance is evaluated against the success criteria and results are presented understandably to process owners and IT for an informed decision; acceptance is approved with formal sign-off by process owners, third parties as appropriate and IT stakeholders before promotion; testing follows the plan and is designed and conducted by a test group independent from the development team; tests and expected outcomes follow the plan's success criteria; scripted test instructions are assessed and approved by the independent group; an appropriate balance of automated and interactive user testing is used; security tests measure weaknesses and consider security incidents since the plan was written; performance tests cover a range of metrics such as end-user response times and database update performance; fallback and rollback elements of the plan are addressed; and errors are identified, logged and classified with an audit trail of results and communication per the plan.

The accepted solution is promoted to the business and operations, run as a pilot or in parallel with the old solution for a defined period where appropriate, and where distribution is electronic or physical it is controlled so that it reaches authorised locations intact: transfer of procedures and supporting services, applications and infrastructure from testing to production follows organisational change management and release management standards; the extent of pilot or parallel processing is determined per the implementation plan; process and system documentation, configuration information and contingency plans are updated promptly; media libraries are updated promptly with the transferred version and the existing version and supporting configuration archived; electronic distribution is controlled so that users are notified and distribution occurs only to authorised and correctly identified destinations with completion confirmed; and physical distribution is logged with what was distributed, to whom, where implemented and when updated.

During development, testing including control testing is executed continually according to the test plan and development practices in the appropriate environment, engaging business process owners and end users in the test team: solutions and components are tested per the plan with testers independent from the solution team and representative process owners and end users, and results are recorded in a test log; clearly defined test instructions are used with an appropriate balance of automated scripted tests and interactive user testing; all tests cover the integration of business processes and IT components and non-functional requirements such as security, privacy, interoperability and performance; errors are identified, logged and classified (minor, significant, mission-critical) and tests repeated until all significant errors are resolved, with an audit trail of results; and outcomes are recorded and communicated to stakeholders per the plan.

Business roles, responsibilities, levels of authority and segregation of duties supporting the process objectives are managed, and access to all information assets related to business processes is authorised: roles and responsibilities follow approved job descriptions and process activities; levels of authority for approving transactions, transaction limits and other decisions follow approved job roles; sensitive activities are allocated so that duties are clearly segregated; access rights and privileges are the minimum needed for predefined job roles, removed or revised immediately on role change or termination; regular awareness and training cover roles, responsibilities, the importance of controls and the security, integrity, confidentiality and privacy of information; administrative privileges are secured, tracked and controlled to prevent misuse; and access control definitions, logs and exception reports are periodically reviewed so that privileges remain valid and aligned with current staff and roles.

An up-to-date repository of configuration items is maintained by populating all configuration changes: all changes to CIs are regularly identified, proposed changes are reviewed against the baseline for completeness and accuracy, configuration details are updated for approved changes, and changes to baselines are created, reviewed and formally agreed whenever needed.