A RunBook is Service Oriented vs. single system oriented.  When documentation does not meet the requirements mentioned above, it is probable that listing the device in an inventory system is sufficient and further documentation is not required.

Where the availability of a critical or core business function depends upon the accurate working of interdependent systems, it is advisable to have a business owner who assures the current and complete Service RunBook.   As is true for any controlled system, the RunBook explains day to day system procedures, but additionally adds some or all of the following elements:

• Functional Overview
• Functional Overview Diagram
• List of Interfaces
• System Overview
• System Overview Diagram (s)
• Network Management Process
• Hardware
• Hardware Management Process
• Software Development and Release
• Third Party Vendor / Software Management
• Performance Monitoring Process
• Database Administration Process
• Quality Assurance
• Vendor Information
• Back Up Processes
• Disaster Recovery Process
• Security
• Problem Management
• Configuration Overview:
• Server/ HW/OS
• Application
• Database Configuration
• Daily cycle
• Fail-over
• Maintenance
• Troubleshooting and Error Messages
• Glossary
• List of files
• Financial Processes
• Test procedure

Should I Write A RunBook?

Consider whether the following statements are true.

Figure 7. Should I write a RunBook?

Where Do I Get The Information That Goes Into The RunBook?

Consider the following sources.

RunBooks bring visibility to an aggregation of documents and details that collectively support service availability or product delivery.

When Is A RunBook Complete?

Consider whether the following statements are true.

RunBooks can be maintained as a word report that is output from a single database system or from a collection of systems.  The form used to gather RunBook elements (today) is in Facilitated Compliance Management. This is a location that is subject to change.  The tool that gathers RunBook details is not critical to the process.  The tool for gathering elements can also be a word document, as identified in the template section.  The process for generating RunBook information is not important, so long as visibility of how systems run is maintained for the business owner and technology support personnel.

Figure 8. RunBook Process

Example Interface for gathering RunBook elements by Service Title

Where Do I Find The Template?

\\...\pal\Facilitated Compliance Management\...

\\...\pal\Templates\RunBook Template.dot

The current procedure for RunBook is to use our system database and generate a RunBook report as needed.

RunBook Document Elements

The following section is written to address addition questions pertaining to document elements, storing and managing information and how steps and controls are specifically captured to support the internal audit of IT program and application level controls.  Sections include:

Where Does My Document Belong?

\\...\PAL\IT Process Asset Library\

1. Static Process versus Process Output (Evidence of Using Process)

\\...\PAL\IT Work Product Library\

1. Other Work Products and Controlled Documentation:
2. Version Control versus VSS (Microsoft Visual SourceSafe)
3. Test Scripts, Utilities and Event Tracking Systems
4. Assets, Inventories and Configuration Baselines
5. Controls and Key Controls
6. Product, Application Development and Quality Templates
7. Flow Diagram

<< Prev - Next >>

< Prev