AI6.1:

AI 6.1 Change Standards and Procedures

Control Objective:

Controls provide reasonable assurance that system changes of financial reporting significance are authorized and appropriately tested before being moved to production.

Set up formal change management procedures to handle in a standardized manner all requests (including maintenance and patches) for changes to applications, procedures, processes, system and service parameters, and the underlying platforms.

Rationale: Managing changes addresses how an organization modifies system functionality to help the business meet its financial reporting objectives. Deficiencies in this area could significantly impact financial reporting. For instance, changes to the programs that allocate financial data to accounts require appropriate approvals and testing prior to the change so that proper classification and reporting integrity is maintained.

Additional Rationale: Installation testing and validating relate to the migration of new systems into production. Before such systems are installed, appropriate testing and validation must be performed to determine if those systems are operating as designed. Without adequate testing, systems may not function as intended and may provide invalid information, which could result in unreliable financial information and reports.

Applicability:

Sarbanes-Oxley

HIPAA

GLBA

PCI

FISMA

NIST SP 800-66

Ditscap

Control Exception

User Defined

Risk Association Control Activities:

1. Risk: Controls provide reasonable assurance that the systems are appropriately tested and validated prior to being placed into production processes, and associated controls operate as intended and support financial reporting requirements.

a. SOX.5.4 A testing strategy is developed and followed for all significant changes in applications and infrastructure technology, which addresses unit, system, integration and user-acceptance-level testing so that deployed systems operate as intended.

2. Risk: Availability of critical systems is decreased because system changes have not been evaluated and tested prior to moving the changes to production.

a.SOX.6.1.1Requests for program changes, system changes and maintenance (including changes to system software) is standardized, logged, approved, documented and subject to formal change management procedures.

3. Risk: Data from old application may be lost, corrupted, or altered inappropriately.

a. SOX.6.1.2 Data from prior versions of applications should be converted complete and accurately, without unauthorized changes.

4. Risk: New program developments and/or changes may be made that are unnecessary or inappropriate.

a. SOX.6.1.3 Request for new applications or changes to existing applications should be appropriately considered and processed.

5. Risk: Application and/or program changes may not meet all control requirements or may negatively impact existing processing.

a. SOX.6.1.4 Application and/or program changes should be tested to ensure that they achieve the necessary application, business, and user control requirements and that they do not negatively impact existing processing.

6. Risk: Unapproved application changes negatively impact business processing or may corrupt production data stores.

a. SOX.6.1.5 Controls are in place to restrict migration of programs to production by authorized individuals only.

7. Risk: Control procedures are not flexible enough to allow for emergency changes to occur.

a. SOX.6.1.6 Emergency requests for change to an application can only be made by authorized individuals, and must have been approved by the owner of the application.

8. Risk: Concurrent access to code in development leads to improper or incomplete changes.

a. SOX.6.1.7 Only properly delegated changes to an application are made, and concurrent access to modify code is not allowed.

9. Risk: Application or system changes may disrupt business processes or corrupt production data stores.

a. SOX.6.1.8 Only properly authorized and tested changes are migrated to the production environment.

10. Risk: Application changes may interrupt business processes or corrupt production data stores.

a. SOX.6.1.9 Only properly authorized emergency changes of applications are migrated to the production environment.

11. Risk: Separate development and production environments do not exist allowing changes to be developed directly into the production environment without proper testing.

a. SOX.6.1.10 Only properly tested changes to applications are migrated to the production environment.

12. Risk: Recovery from a production change cannot be performed.

a. SOX.6.1.11 Applications can be recovered from unintended effects of a change to an application.

Implementation Guide:

Process Narrative
Insert a description of the process narration that is applicable to the existing control statement this narrative refers to.

Process Illustration
Insert a process diagram, flowchart or other visual representation here to illustrate the process narrative.

File:Someimage.jpg

Control Commentary
Insert a description of the control that is applicable to the existing control statement this commentary refers to.

Control Exception Commentary
Insert a description of the control exception that is applicable to the existing control statement this commentary refers to.

Evidence Archive Location
Insert Evidence Description Here.

Control Status and Auditors Commentary
Describe the condition of the applicable control and its effectiveness. Set the color icon to a redlock.jpg, yellowlock.jpg or greenlock.jpg.

File:Redlock.jpg

Remediation Plan
Insert remediation plan, applicability, or any information that indicates what needs to be done.

Supplemental Information:

• ISO 17799 10.1.2: Operational systems and application software are subject to strict change management control.
  

• ISO 17799 10.1.2: Changes to operational systems and application software are identified and recorded.
  

• ISO 17799 10.1.2: Changes to operational systems and application software are planned and tested.
  

• ISO 17799 10.1.2: An assessment was made of the potential impact of the change, including security.
  

• ISO 17799 10.1.2: Changes to operational systems and application software are formally approved, and documented.
  

• ISO 17799 10.1.2: Details of changes are communicated to all relevant persons.
  

• ISO 17799 10.1.2: Formal fallback procedures are in place including procedures and responsibilities for aborting and recovering from unsuccessful changes and unforeseen events.
  

• ISO 17799 10.1.2: When changes are made, an audit log containing all relevant information should be retained.
  

• ISO 17799 10.1.2: Changes to operational systems are only made when there is a valid business reason to do so.
  

Change control procedures:

• ISO 17799 12.5.1: Formal change control procedures are documented and enforced in order to minimize the corruption of information systems.
  

• ISO 17799 12.5.1: Introduction of new systems and major changes to existing systems follows a formal process of documentation, specification, testing, quality control, and managed implementation.
  

• ISO 17799 12.5.1: Because changing software can impact the operational environment, the change process includes a risk assessment, analysis of the impacts of changes, and specification of security controls which are required.
  

• ISO 17799 12.5.1: Support programmers are given access only to those parts of the system necessary for their work. Formal documented agreement and approval for any change is obtained before changes are made.
  

• ISO 17799 12.5.1: A record is maintained for agreed authorization levels.
  

• ISO 17799 12.5.1: Changes are submitted by authorized users which have been approved by the business owner.
  

• ISO 17799 12.5.1: Control and integrity procedure are reviewed to ensure that they will not be compromised by the changes.
  

• ISO 17799 12.5.1: All software, information, database entities, and hardware that require amendment are identified.
  

• ISO 17799 12.5.1: Business owners accept changes prior to implementation.
  

• ISO 17799 12.5.1: System documentation set is updated on the completion of each change and that old documentation is archived or disposed of.
  

• ISO 17799 12.5.1: Version control is maintained for all software updates.
  

• ISO 17799 12.5.1: An audit trail is maintained for all change requests.
  

• ISO 17799 12.5.1: Operating documentation and user procedures are changed as necessary to remain appropriate.
  

• ISO 17799 12.5.1: Changes takes place at the right time and does not disturb the business processes involved.
  

• ISO 17799 12.5.1: New software is tested in an environment segregated from both the production and development environments.
  

• ISO 17799 12.5.1: Automated updates are not used on critical systems as some updates may cause critical applications to fail.
  

Implementation guidance
Insert guidance in this section if it helps to elaborate upon the subject matter. Examples of evidence that would help guide the end user is desirable.

--Mdpeters 10:21, 23 June 2006 (EDT)