Procedures and Controls Documentation Guidelines

©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA, of 80

More from Phoenix Business and Systems Process, http://www.pbandsp.com

Procedure Guidelines and Controls Documentation May 23, 2006 (rev3 May 16, 2006)

A Proposed Template for Governance: Process Documentation and Process Architecture As aligned to CobiT® Process Management and Documentation Controls, ISO9001 Process Documentation Methodology and COSO ERM Standards for Enterprise Risk Management

Author Robin Basham, M.IT, M.Ed, CISA

President, Phoenix Business and Systems Process

Template Copyright © [Company Name]

Procedure Guidelines and Controls Documentation Robin Basham, M.IT, M.Ed., CISA

©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA, Page 1 of 80


Process Profile

Process Owners: Process Owners’ Departments: Process Owner At Release: Release Approval List: Distribution List: Document Authors: Data Classification: Confidential Effective Date: Revision Date:

Version Control

Revision Notes Revision Code

Revision Author

Revision Release Date

Release Approved by




Table of Contents Purpose and Scope............................................................................................................................................. 5 Policy Statement.............................................................................................................................................. 5 Requirements .................................................................................................................................................. 5 Document Library Management Program .................................................................................................... 5

Roles and Responsibilities ............................................................................................................................... 6 Process Librarian......................................................................................................................................... 6 Security or Resource Administration ........................................................................................................... 7 Business Unit and Department Data Owners................................................................................................ 7

Access Control ................................................................................................................................................ 7 Audience and Audit Considerations ................................................................................................................. 8 Writing Standards............................................................................................................................................ 8 Change Requirements...................................................................................................................................... 8 Key Controls ................................................................................................................................................... 8 Data Classification and Data Owners ............................................................................................................... 8 Naming Conventions ....................................................................................................................................... 9

Document Types and Their Use ........................................................................................................................ 9 What Type of Document Do I Need To Write? ................................................................................................ 9 Forms and Templates .................................................................................................................................. 9

Getting Started: ......................................................................................................................................................1 New Object Support Request ..................................................................................................................................1

How Do I Validate My Document?.............................................................................................................. 2 Figure 1. Validate a Process Object ............................................................................................... 2

Document Type Process Profile..................................................................................................................... 3 Characteristics of Process ................................................................................................................................ 3 Should I Write A Process Profile? ............................................................................................................... 4

Figure 2. Should I write a process profile?...................................................................................... 4 Where Do I Find the Process Profile Template?........................................................................................... 1

Figure 3. What are the steps and controls in writing a process profile? ........................................... 1 Document Type Policy Profile....................................................................................................................... 2 Should I Write A Policy Profile? ................................................................................................................. 3

Figure 4. Should I write a policy profile? ......................................................................................... 3 Where Do I Find the Template?................................................................................................................... 3

Document Type Program Profile ................................................................................................................... 3 Should I Write A Program Profile? .............................................................................................................. 4

Figure 5. Should I write a program profile? ..................................................................................... 4 Where Do I Find The Template?.................................................................................................................. 5

Document Type Work Instruction or SOP ..................................................................................................... 5 Should I Write A Work Instruction SOP? .................................................................................................. 6

Figure 6. Should I write a Work Instruction SOP........................................................................... 6 Where Do I Find The Template?.................................................................................................................. 6

Document Type RunBook ............................................................................................................................. 6 Why Do RunBooks Focus On Service?........................................................................................................ 7 Should I Write A RunBook?........................................................................................................................ 8

Figure 7. Should I write a RunBook? .............................................................................................. 8 When Is A RunBook Complete?................................................................................................................ 10 What Are The Formats For RunBook?....................................................................................................... 10

Figure 8. RunBook Process.......................................................................................................... 10 Figure 9. Example Interface for gathering RunBook elements by Service Title.............................. 11

Where Do I Find The Template?................................................................................................................ 12 Document Elements ......................................................................................................................................... 12




How Do I Find Or Store My Document? ....................................................................................................... 13 PAL\ IT Process Asset Library .................................................................................................................. 13

Figure 10. What is in the PAL?..................................................................................................... 13 PAL\ IT Work Products............................................................................................................................. 13 When Do I Need To Create A Work Product?............................................................................................ 13 Where Do We Keep Current And Archived Work Products?...................................................................... 13

Figure 11. What are the work product folders? ............................................................................. 14 Where Do I Find Reference, Benchmark and Industry Guidelines .................................................................. 15

Figure 12. Standards and Reference folders ................................................................................ 15 Other Work Products and Controlled Documentation:...................................................................................... 2 Controls Evidence Specific to Software Development and Product Development Lifecycle: ............................ 2

Figure 13. Information Criteria........................................................................................................ 4 What elements are captured during the flow diagramming process? ................................................................. 5

Figure 14. Process Inputs and Outputs, RACI Chart for AI7 as found in CobiT® 4.0, Copyright of ISACA® 6 Figure 15. Process Flow Diagram: How are software development artifacts captured in system event logs and software design templates? ......................................................................................... 2

Controls and Application Controls................................................................................................................... 2 When do I need to document specific control processes? ............................................................................. 2 How do we manage all these requirements? ................................................................................................. 2

MKS Integrity Manager for process and workflow management of enterprise software development ............... 2 How mature do we really need to be? .............................................................................................................. 3

Figure 16. Maturity Toolbox, as represented by ISACA and CMU as the common maturity model or CMM 3 Figure 17. How are software development artifacts captured in system event logs and software design templates?............................................................................................................................... 4

Test Scripts, Utilities and Event Tracking Systems .......................................................................................... 5 What Is A Test Script Or Test Templates? ................................................................................................... 5 Where Do I Find QA Test Templates? ......................................................................................................... 5

Assets, Inventories and Configuration Baselines .............................................................................................. 5 Figure 18. Should I document a controlled server in our system inventory database?..................... 6

Where Are Devices Inventoried As Assets? ................................................................................................. 6 Where Do I Find Server Control Records?................................................................................................... 6

Figure 19. Controlled Server Form ................................................................................................. 7 Figure 20. Each controlled item has associated security exemptions and standard OS and Application build.................................................................................................................................. 8

Which Tools Store Server and Application Information? ............................................................................. 8 Where Is The List Of Tools And Tool Types?.............................................................................................. 9

Controls and Key Controls .............................................................................................................................. 9 When Do I Need To Document A Control Object? ...................................................................................... 9 Where Are Controls Catalogued?............................................................................................................... 10

Figure 21. What Process Engineering, Auditors and Quality Gather Regarding Corporate Key Controls 10 Figure 22. Key Controls Form ...................................................................................................... 11

Where Do I Find The Form or Template? .................................................................................................. 11 Product, Application Development and Quality Templates ............................................................................ 12 Which Tool Stores Process and Work Instruction information?.................................................................. 16

Figure 23. Facilitated Compliance Management™ provides summary reports for many object types 17

Figure 24. Facilitated Compliance Management™ Allows Process Librarian to capture and catalogue all process objects ............................................................................................................ 17

Flow Diagram ............................................................................................................................................... 17




When Do I Use A Flow Diagram? ............................................................................................................. 17 Figure 25. Sample of A Business Process.................................................................................... 19

Visio Shapes and Custom Properties for Evidence of Process Controls ...................................................... 20 Figure 26. Process Objects with properties .................................................................................. 23

Acronym Glossary and Definitions ................................................................................................................ 24 Comprehensive Glossary of all Corporate Terms ........................................................................................... 25 Related Documents........................................................................................................................................ 25

Extended Bibliography.................................................................................................................................... 25 Risks and Associated Controls....................................................................................................................... 32

Figure 27. What Type of Document Should I Write?..................................................................... 34 Example of PAL Contents File Location, Description of Use ...................................................................... 35




Purpose and Scope Procedure Guidelines and Controls Documentation outlines how to create and modify procedures, work instructions, policies, and RunBooks as they currently exist in their correct location and format and as aligned to the requirements of document security.

Change control, information asset location, and documentation format standards are the combined responsibility of Security Management, Quality Assurance, and Process Engineering. In the context of creation, iteration, approval, and posting, the Process Librarian manages documentation.

Process Engineering manages quality over documentation as demonstrated by document templates.

Security Management defines policy and access rules for the recording, adherence to, and monitoring of procedures involving data integrity, privacy, and security across any enterpriselevel configuration.

Policy Statement All changes, additions, and deletions to the production documentation library require management approval. Managers should notify Process Engineering of changes to production process.

Requirements The primary security elements of any document library management process are:

• Auditable changes

• Evidence of document library and document lifecycle management that is readily available for those who need to monitor this activity.

Documentation strategies need to:

• Reduce complexity.

• Prioritize key control processes

• Reflect COMPANY process architecture

• Represent real functions and real activities

Document Library Management Program A formal document library management program manages the Process Asset Library and monitors compliance with document lifecycle objectives (i.e., annual document reviews). The program must include, but is not limited to, the following controls:

• Documented procedures for updating production documentation.

• Defined roles and responsibilities that support defined procedures for document and document library maintenance.

• Accountability for document content integrity.

• Education, notification, and awareness process to inform all necessary stakeholders affected by document modifications.

• Separation of production and nonproduction documentation.

• A defined data retention goal for each document or class of document. Documents are maintained for the lifecycle of the process. If aligned to key controls and loaded in [Name of core product or service], the document is retained as part of SAS 70 evidence.




Document lifecycle control procedures must detail the process for: (Process Profile Creation doc – sections embedded in this doc)

• Reviewing new or changed documents.

• Approving and rejecting documents.

• Posting documentation.

• Documenting information about documentation (metadata).

• Auditing the lifecycle of documents in the library.

Roles and Responsibilities Document and document class owners shall:

• Ensure the integrity, confidentiality, and availability of production documentation and the library environment through the implementation of documented programs, procedures and standards.

• Approve all changes affecting their domain of control and responsibility.

• Ensure all changes have been approved and properly communicated prior to posting.

• Ensure that their employees understand and abide by this policy and its control requirements.

• Report any violation of this policy to the CTO and CSO or its designated representatives, within a timely manner.

The Process Engineering Team will endeavor to assist COMPANY operations with many timeconsuming functions not core to their roles. Process and technical documentation is central to the creation of user guides and training materials and is currently aligned to the COMPANY Process Engineering group. As COMPANY may add or extend this function, the process librarian function will continue to assist with the design and deployment of training materials and user guides.

These duties may include:

• Assist with writing and maintaining procedures and controls. The data owner will usually write procedures.

• Providing methods to maintain and meet record keeping obligations.

• Assisting with the design and modeling of management reports and control checklists.

• Assisting with workflow and process design.

• Acting as a liaison with business, compliance, and development to implement and/or update procedures, controls, and system enhancements.

Process Librarian The Process Librarian controls the process information directory structure and makes sure the integrity of the folders is maintained. The librarian function catalogues and categorizes documentation assets and aligns documentation standards to the needs of the business and technology functions.

Where changes are required to existing process documentation, the process librarian handles the registration and posting of new procedures to the established process location.




Any new folders must be requested via email to the process librarian, currently [Name of Process Librarian], at [email protected]. The librarian insures name and contents integrity within Facilitated Compliance Management™ process tracking. \\...\PAL\Facilitated Compliance Management\Facilitated Compliance Management2000FCM.mdb

Security or Resource Administration People who administer access to process assets will adhere to sanctioned user access process, providing resource access to employees as determined by their role and the approval of their management. The Resource Administrator will not add or modify folders outside the boundaries defined by the Process Engineering Team. Specifically, once a business area is provided space for information assets, modification to root level file hierarchy is not permitted. This rule is established to assure inventory over information and in no way limits the productivity of any business area. Information can be created in subfolders within the designated file share. Persons with write access can create subfolders within the root of their information domain.

The Security Administrator will create file shares and folders as requested by the Process Librarian, and will allow changes within the files as determined by the business owner for the share information.

Business Unit and Department Data Owners Data owners are accountable to the reasonable use of their designated drive space, assuring proper classification and location of their data. Business owners define users and establish access rules based on a need to know principal. Where a business area needs folders that extend beyond the current process architecture, the Business Unit must gain approval through process engineering and security, insuring proper rules for classification and the avoiding of duplicate information. (See Current PAL Contents and File Location Description of Use)

Business owners are accountable to the periodic review of information on their drive. This review is to assure appropriate use of file naming conventions, validity of process, completed procedures, and to archive out of date content. Business owners are accountable to understanding their data privacy and retention requirements and to communicate these requirements to their personnel.

Access Control Access to the production library contents must be controlled in the same manner as the production environment to ensure that only authorized users can access the documents. Access controls must be established to ensure only authorized individuals can view, edit, and update documents according to appropriate roles.

Default access controls include:

• Process Librarian has administrative privileges to the PAL and provides Security Administration with the Functional Business Owner for each directory in the PAL.

• System Administrator has administrative privileges to the PAL and may grant user access according to Manager Approval.

• Functional Managers, such as Support, Change Management and Process Engineering, have read/write/update/delete privileges to their file share on the PAL. Policy dictates they should not create or delete folders without notice and approval from the Process Librarian.

• Employees (non managers) have read only privileges unless granted write privilege by the Functional Manager. Employees do not have delete privilege.




Audience and Audit Considerations This process profile serves as reference for COMPANY. Groups may be referenced by functional email notification names such as [email protected]. Group functional emails are used to support communication trails and facilitate rules for review, approval, and timely business communication.

Procedures are detailed documents, generally derived from parent policy and implemented to the spirit (intent) of the policy statement. Therefore, all procedures written and implemented by COMPANY align to Security Policy, HR Policy, Program Change Policy, and specific requirements for Data Classification, Data Retention, and Data Privacy as defined by senior management.

Writing Standards Procedures are written in a clear, concise, and easily understood manner. Procedures document business processes (administrative and operational) and their controls. Procedures are created by upper and middle management as a means to translate policy to practice.

Change Requirements Procedures, represented as processes, work instructions, standard operating procedures, workspecific training materials, and production support procedures (i.e., RunBooks), are dynamic, changing to fit current business operational practices. They must reflect the regular changes in business focus and environment. Reviews and updates of procedures are essential if they are to be relevant. Therefore, COMPANY provides notice to business management of all changes and new instances of process. Both internal and external auditors will review procedures to identify, evaluate, and thereafter test controls over business processes. Given this knowledge, it is the responsibility of the process owner to keep current any process documentation and to notify the process librarian of any process change via [email protected].

Additionally, part of change approval includes validation that all training and support procedures are current.

Key Controls The controls embedded in procedures are evaluated to ensure that they fulfill necessary control objectives while making the process as efficient and practical as possible. Some controls are designated as “key” and represent reported controls evidence in support of COMPANY regulatory attestation. Where operational practices do not match documented procedures or where documented procedures do not exist, it is difficult (for management and auditors) to identify controls and ensure that they are in continuous operation. While not all situations of this type represent control failure, each situation requires review and response based on the risk to safe and effective process management.

Documentation is a key control in that proper documentation directly supports every aspect of COMPANY control framework. The absence of documented process is a risk to operations and to COMPANY . Failure to properly document control procedures is an indication of management and control deficiencies.

NOTE: Missing or incomplete critical process documentation is not tolerated as acceptable business practice.

Key control objectives are mapped to documentation and other evidence of control. Currently the tool to manage this is [Name of core product or service].

Data Classification and Data Owners The CobiT Planning and Organization Control objective “Define the Information Architecture, 2.3 Data Classification Scheme” requires a general classification framework established with regard to placement of data in information classes (i.e., security categories) as well as allocation of ownership. The “access rules”, as in who can access what type of data as well as the restrictions over where that data may reside, on a per classification basis,




should be appropriately defined. This is a codependency on Security and Security Administration, where Process assists in the implementation of classification standards, and access is further supervised and implemented through Security programs.

Process Librarian and Data Owners are dependent upon the accurate “classification of information assets” as defined by the Security Policy. Enduser managers and the security administrators require classifications to accurately determine who should be able to access what. The Process Librarian assists in the design of file share information, whereas the Data Owner is accountable for the classification and administration of its use. The Process Librarian assists the business to manage data assets by location and classification. The Process Librarian further supports requirements to have an information inventory of internal process and work products.

Naming Conventions Naming conventions are a part of the COMPANY overall security design and are an integral part of information asset accounting. In accordance with an approved set of access rules stipulating users (or groups of users) authorized to access a resource (such as a dataset or file) and at what level (such as read or update) the access control mechanism applies these rules whenever a user attempts to access or use a protected resource. Data is maintained by location such that access is appropriately restricted.

These general naming conventions and associated files are required in a computer environment to establish and maintain personal accountability and segregation of duties in the access of data. The owners of the data or application, with the help of the security officer and process librarian, establish the name of files and subfolders for their business information. It is important to establish naming conventions that both promote the implementation of efficient access rules and simplify security administration. Naming conventions for system resources are an important prerequisite for efficient administration of security controls.

Process Engineering Key Controls and Risks can be reviewed in Process Documentation Compliance Control CobiT Function CobiT Detail Objective and Risks and Associated Controls

Document Types and Their Use What Type of Document Do I Need To Write? Writing a document may sound easy, but it is really very complex. Documentation strategies are designed to reduce complexity, prioritize Key Control Processes, reflect a common Process Architecture; (ITIL and CobiT frameworks), and above all else, represent REAL Functions and REAL activities.

Factors that influence the type of document that we write are:

• Sustainability, how often detail within the process will change and

• “High Level not Vague” Achieving the Highest Level of information possible before document details become formless, blurry or vague

Forms and Templates Process documentation is designed for a specific layer of abstraction. Process engineering works with the document author to select a template that meets the writer’s minimal requirements.

Guided writing is a process that facilitates creating consistent standard quality documentation. Writing takes many forms, each best suited to serve a different purpose. The following sections explain the different types of templates or writing guides, including application interface, word templates and diagrams.




Getting Started: Prior to creating a procedure, persons are asked to review available formats for documentation. Once the type and topic for documentation is established, Process Engineering is available to review and validate the intended process. Process Engineering catalogues corporation documentation and is able to prevent wasted or duplicated documentation efforts.

How: Send notice of intention to create documentation to [email protected]. The following details provide notice to the Process Librarian of an intended process product. This request minimally requires the following information:

New Object Support Request For each intended process object, please fill in the section below. Please copy the questions for each title.




Is this a Process, Work Procedures, a Policy, a Program Definition or a Form?

Management or Department Function:

Title:

Owner:

Purpose:

Affirmation Team:

Associated Key Control:

The Process Team will select a template or document format and refine the title and scope to best align the output with existing process architecture and requirements. Templates exist in the template folder for each functional area. A master file of business templates can be found in \\...\PAL\Templates. A comprehensive list of approved templates is in Facilitated Compliance Management, located in the Forms and Templates Section.

How Do I Validate My Document? Before embarking on a procedure, policy, process or any type of controls documentation, contact the process librarian so the intended object can be verified and catalogued in the process objects database.

Process Object Validation

Request new Process Object

Management Approval

Launch Process Object form

Form open

Return pending manager’s approval

Identified process object

Legitimate need for process

New Process Validation

New

Alert IT management of new process in development

Pass One process created

IT stakeholders are able to get involved in process

Enter process details

Process details exist

Exists. Gain consensus is an update.

Created Update Process Object

Instance of process in process profile table

Department or User Approval to Update Process

Process Change

Figure 1. Validate a Process Object




Document Type Process Profile The purpose of a process profile is to capture and document essential elements associated with a business process. A process is a series of actions, changes, or functions bringing about a result.

Elements included in a process profile are selected by the process team. Generally, the elements include, but are not limited to:

• Version Control And Change History

• Purpose And Scope

• Associated Control Objectives

• Critical Success Factors

• Performance Indicators Baseline Performance

• Goals/Measures

• Service Level Considerations

• Related /Source Documents

• Forms And Templates

• Quality Records Including SQM

• Process Diagram

• Process Deviations And Current State

• Trigger And Exit Criteria

• Acronyms/Definitions

• Safety Issues

• Risk Management Plan

• Process Definition (Inputs And Outputs To Other Processes)

• Status Codes—Metadata

Characteristics of Process • Highest level of abstraction and lowest level of detail • High level set of steps that collectively accomplish a business function: • Typically includes sub or component level processes • Often used by more than one program or department




Should I Write A Process Profile? Consider whether the following statements are true.

The process flow diagram demonstrates the steps involved in creating any process object. If this is viewed on line, the flow includes all process properties in the flow objects. For more information, see Appendix A.

Figure 2. Should I write a process profile?




Where Do I Find the Process Profile Template? \\...\PAL\Templates\Process Profile Template.dot

Figure 3.What are the steps and controls in writing a process profile?




Document Type Policy Profile Policy is the underlying principle upon which process and programs are built. One might consider that a policy is “Commander’s Intent”, and it is up to the persons governed to determine the best practice or process to attain their goal within the confines of the policy. While not every program requires a policy, information technology practice is largely determined by the Security Policy, Change Policy and Data Classification Policy. In addition, most business practice is in some way governed by the Human Resource Policy. Policy is implemented by programs that enact processes. Policy is generally required for legal and regulatory compliance. Policy is enforced through system, application and organizational controls. A policy is typically designed to be true across all departments and for all persons. Where a policy is highly specific to a program or department, it is generally a department policy, but not a formally distributed corporate policy.

Elements:

• Policy Area • Effective Date • Revision Date • Contacts: • Summary • Goals • Applicability • Policy Statement • Roles and Responsibilities • Compliance • Exemptions • Appeals • Authority • Related Documents • Definitions




Should I Write A Policy Profile? Consider whether the following statements are true.

Figure 4. Should I write a policy profile?

Where Do I Find the Template? \\...\PAL\TEMPLATES\Policy Profile.dot

Document Type Program Profile Program Profiles are sometimes referred to as a program or department charter and are used to define the scope of a group as well as the requirements of its organization. This document outlines the overall organizational or department function and is aligned with departments and individual performance reviews. Program profiles may include job descriptions or job profiles and are represented by organizational diagram. These are supporting documents, often associated to the program profile.

Attributes of a program include:

• Manages Control Systems and Events • Owns Initiatives and Business and IT Systems • Responsible For Supporting Functions • Is Measured

Program profiles support the ability to perform:

• Personnel Recruitment and Promotion • Benchmark Personnel Qualifications • Designate Roles and Responsibilities




• Plan and Deliver Personnel Training • Implement CrossTraining or Staff Backup • Verify Personnel Clearance Procedures • Design and Perform Employee Job Performance Evaluation • Determine Job Change and Termination Requirements

Program Profile Elements:

• Purpose and Scope: • Roles and Responsibilities: • Program Elements: • Tools: • Program Controls and Measures

Should I Write A Program Profile? Program profiles are not required, but can facilitate a great many other functions including Audit and Training or Organization Requirements Definition. Where a program profile supports the organization to explain a department charter, it is a simple and useful tool that may benefit employees and auditors equally.

Consider whether the following statements are true.

Program Profile Supports

implementation of process or policy

Aligned to job descriptions and control functions

Serves as audit guide for program implementation

Organizational control activity

Defines a company specific activity Including purpose,

elements, tools and staff

Activity is exclusive to this group

There is a group

chartered to perform this function

Required to maintain controls

Measured metrics

Complete Program and Program Test

Definition

Figure 5. Should I write a program profile?




Where Do I Find The Template? \\...\PAL\Templates\Program Profile Template.dot

Templates that describe positions or assist in the design of a program organizational chart are located in:

\\...\PAL\IT Process Asset Library\Human Resources\Template\Job Description Template.dot

\\...\PAL\IT Process Asset Library\Human Resources\Template\Employee Warning Notice.dot

\\...\PAL\IT Process Asset Library\Human Resources\Template\Job Analysis Questionnaire.dot

Document Type Work Instruction or SOP Work Instructions, also known as Standard Operating Procedures, (SOP) represent:

• Greatest level of technical detail • Are tool dependent; • Change when technology changes • Are updated often • Stored in knowledge management systems or help desk database • Associated with specific tools and tasks • Used to guide and train work at the task implementation level • Are part of an already approved process

Work instructions or SOP’s can be located within a functional area and are often embedded in help files within systems. RunBooks (explained in the next section) reference work instructions to facilitate answering the question, “Where do I find directions to perform this task?” Whereas process changes are a part of standard change management, a work instruction may be updated as a course of an individual’s personal need to track how detailed steps are done. A work instruction may have general or highly specialized use. Where work instructions are critical to the control of a process, it is the business manager’s responsibility to insure that routine work procedures exist and are followed within their functional area.

All service affecting operational processes must be documented to prevent service disruption caused by the absence of primary staff. Any procedure required to maintain operations, that is not already documented as a part of routine system functions, (i.e., already located in general product help files), must be documented to assure that in the absence of primary staff, the process can be sustained by others. At a minimum, all personnel are accountable to documentation to the extent that a similarly trained staff could stand in for emergency coverage and be able to use directions to maintain required operations. Where staff fail to keep their work instructions up to date, the failure is both on the part of the individual and the area manager.

Work instructions or SOPs are a simple list of steps that explain in clear terms, how to achieve a specific result.

Directories containing work instructions and SOPs should be clearly labeled and information should be current. Work instructions can exist in all eventtracking systems and are not centrally located, but are accessible and known to all persons within the user department.




Should I Write A Work Instruction SOP? Consider whether the following statements are true.

Figure 6. Should I write a Work Instruction SOP

Where Do I Find The Template? The template to write a simple set of work instructions is located in:

\\...\PAL\Templates\Work Instruction Template. dot

Document Type RunBook A RunBook, sometimes known as playbook, is a document containing detailed procedures that collectively keep a mission critical system running. A RunBook is sometimes viewed as an element of Business Continuity Planning (BCP) or Disaster Recover (DR). This is because they are written to assure that an equally skilled administrator would be able to use the RunBook to step in and administer the system until such time that normal staffing and conditions apply. RunBooks are a system current document with all the required information needed to understand how a service or system is kept running. RunBooks are not project plans, and do not maintain information unless it is “in use” and a part of the working system.

A RunBook is used to verify and gather the location of all operational information. A production RunBook is evidence of documentation and control over a service or system. It provides information on “how” to run procedures without necessarily providing background for the process. RunBooks are detailed instructions that a user references when performing the process.

On a per system instance, a RunBook can document a small set of operational procedures and reference various guidelines. On a larger scale, a service oriented RunBook details the combination of systems and their




dependencies in keeping a service available. This is a valid form of meeting both BCP and various other levels of compliance requirements. Determining this requirement can be as follows:

Why Do RunBooks Focus On Service? 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 • Failover • 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.

What Are The Formats For RunBook? 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




Figure 9.Example Interface for gathering RunBook elements by Service Title




Where Do I Find The Template? \\...\pal\Facilitated Compliance Management\Shortcut to RunBook in Facilitated Compliance Management2000FCM.MAF

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

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

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\

• Static Process versus Process Output (Evidence of Using Process)

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

• Other Work Products and Controlled Documentation:

• Controls Evidence Specific to Software Development and Product Development Lifecycle:

•

• Test Scripts, Utilities and Event Tracking Systems

• Assets, Inventories and Configuration Baselines

• Controls and Key Controls

• Product, Application Development and Quality Templates

• Flow Diagram




How Do I Find Or Store My Document?

PAL\ IT Process Asset Library Process documents are stored in the IT Process Asset Library (PAL).

Figure 10. What is in the PAL?

\\...\PAL\IT PROCESS ASSET LIBRARY\

PAL\ IT Work Products

When Do I Need To Create A Work Product? There are a variety of Word and Excel files used during the workday. These documents may include spreadsheets used for analysis, client contact files, miscellaneous notes, etc. These are not considered forms or procedures and remain within their respective locations on the network. In conditions where documents or spreadsheets represent evidence of a process output, the materials are “Work Products” and should reside in the functional work products directory. Not all data is work product. A test of whether information belongs in the work products area is answering yes to the following question:

Is this the output of a template, process, form, and is this evidence of a process?

Where Do We Keep Current And Archived Work Products? \\...\PAL\IT WORK PRODUCT LIBRARY\




Figure 11. What are the work product folders?

Current Inventory of Folder and Contents is maintained by Process Engineering, in \\...\PAL\IT Work Product Library\Process Engineering\PAL Folders.xls




Where Do I Find Reference, Benchmark and Industry Guidelines Methodology and standards documentation is maintained in the Standards and External Reference folder. Corporate Policy and Templates also reside at this level of the PAL. These folder locations allow for all personnel to have equal access to information used to support and design any process.

Figure 12. Standards and Reference folders




Other Work Products and Controlled Documentation:

Controls Evidence Specific to Software Development and Product Development Lifecycle: Teams preparing their annual audit work papers (controls evidence) will often ask, “What about SDLC related artifacts like VSS/ CVS, test events and source code libraries? Software Development work products have particular control requirements satisfied through the appropriate use of tools such as workflow and event management, integrated development environments or IDE’s and storage libraries for the purpose of source control. Unlike controls designed to enforce and manage the policy of production environments however, software development must allow for both creative genius and water tight tests over what can sometimes be bleeding edge or “non conforming” code. The requirements aligned to creating and modifying today’s business solutions must often support multiple libraries of code involving issues integration with environments best described as moving targets, highly complex data requirements and greater third party dependencies than could have ever been anticipated. “Production Environments” are as fixed as the next patch response to newly revealed malicious code, hardware or software exploit or even regulatory requirement. Among the myriad of morphing parts is the Holy Grail we call “production” and the miraculous belief that we control it. It is no wonder that entire careers have been made in the path of unraveling the events perceived as the negative effects of purposefully released code.

Software development is an integrated process spanning the entire IT organization. The term lifecycle can be taken to represent the collection of agreed steps to control development, modification and distribution of code. While Change and Configuration Management denote separate entities exerting policy over standards for the production environment, the design of these standards and all efforts between these points can be characterized as the world of software development and code.

Clearly, no two companies have exactly the same organization, product or infrastructure, but the efforts of Carnegie Mellon University, Software Engineering Institute, the Office of Government and Commerce and British Standards Institute and the Information Systems Audit and Control Association have produced clear and aligned frameworks for the representation of software development best practice. Well run, or mature development shops provide similar process and control points and reap quality product as the benefit of their status among “mature” organizations.

The Control Objectives for Information Technology, Edition Four, CobiT® 4.0 is our most widely adopted matrix and measure for all integrated IT and Enterprise controls. Aligning the concepts of CMM, ITIL, ISO/IEC 17799 and COSO, CobiT® 4.0 advances the previous project with increased attention in the areas of SDLC, Quality and Project Risk Management. Of particular note, is the newly numbered control process “Install and Accredit Solutions and Changes”, AI7.

Install and Accredit Solutions and Changes is the high level functional area that captures the greatest number of features representing the activities related to SDLC or Release Management. AI7 states:

“New systems need to be made operational once development is complete. This requires proper testing in a dedicated environment with relevant test data, definition of rollout and migration instructions, release planning and actual promotion to production, and a postimplementation review. This assures that operational systems are in line with the agreed expectations and outcomes.”

“Install and Accredit Solutions and Changes” include inputs and outputs to configuration, project, change, maintenance and acquisition programs. With handoffs based in triggers, performance goals, measurements and business based criteria, documented consensus and tested results, evidence of their implementation is best suited to automated systems.




As companies comply with regulatory and industry requirements, system based records showing evidence of these controls gain even greater importance. The following are high level definitions of the control processes found within Acquisition and Implementation process, Install and Accredit Solutions and Changes, or “AI7”.

Training (7.1)

Train the staff of the affected user departments and the operations group of the IT function in accordance with the defined training and implementation plan and associated materials, as part of every information systems development, implementation or modification project.

Test Plan (7.2)

Establish a test plan and obtain approval from relevant parties. The test plan is based on organization wide standards and defines roles, responsibilities and success criteria. The plan considers test preparation (including site preparation), training requirements, installation or update of a defined test environment, planning/performing/documenting/retaining test cases, error handling and correction, and formal approval. Based on assessment of the risk of system failure and faults on implementation, the plan should include requirements for performance, stress, usability, pilot and security testing.

Implementation Plan (7.3)

Establish an implementation plan and obtain approval from relevant parties. The plan defines release design, build of release packages, rollout procedures/installation, incident handling, distribution controls (including tools), storage of software, and review of the release and documentation of changes. The plan should also include fallback/back out arrangements.

Test Environment (7.4)

Establish a separate test environment for testing. This environment should reflect the future operations environment (e.g., similar security, internal controls and workloads) to enable sound testing. Procedures should be in place to ensure that the data used in the test environment are representative of the data (sanitized where needed) that will eventually be used in the production environment. Provide adequate measures to prevent disclosure of sensitive test data. The documented results of testing should be retained.

System and Data Conversion (7.5)

Ensure that the organization's development methods provides for all development, implementation or modification projects, that all necessary elements such as hardware, software, transaction data, master files, backups and archives, interfaces with other systems, procedures, system documentation, etc., be converted from the old system to the new according to a preestablished plan. An audit trail of pre and postconversion results should be developed and maintained. A detailed verification of the initial processing of the new system should be performed by the system owners to confirm a successful transition.

Testing of Changes (7.6)

Ensure that changes are tested in accordance with the defined acceptance plan and based on an impact and resource assessment that includes performance sizing in a separate test environment by an independent (from builders) test group before use in the regular operational environment begins. Parallel or pilot testing should be considered as part of the plan. The security controls should be tested and evaluated prior to deployment, so the effectiveness of security can be certified. Fallback/ backout plans should also be developed and tested prior to promotion of the change to production.

Final Acceptance Test (7.7)

Ensure that procedures provide for, as part of the final acceptance or quality assurance testing of new or modified information systems, a formal evaluation and approval of the test results by management of the affected user department(s) and the IT function. The tests should cover all components of the information system (e.g., application software, facilities, technology and user procedures) and ensure that the information security requirements are met by all components. The test data should be saved for audit trail purposes and for future testing.

Promotion to Production (7.8)

Implement formal procedures to control the handover of the system from development to testing to operations in line with the implementation plan. Management should require that system owner authorization be obtained before a new system is moved into production and that, before the old system is discontinued, the new system has successfully operated through all daily, monthly, quarterly and yearend production cycles.

Software Release (7.9)

Ensure that the release of software is governed by formal procedures ensuring signoff, packaging, regression testing, distribution, handover, status tracking, backout procedures and user notification.

System Distribution (7.10)




Establish control procedures to ensure timely and correct distribution and update of approved configuration items. This involves integrity controls; segregation of duties among those who build, test and operate; and adequate audit trails of all actions.

Recording and Tracking of Changes (7.11)

Automate the system used to monitor changes to application systems to support the recording and tracking of changes made to applications, procedures, processes, system and service parameters, and the underlying platforms.

Postimplementation Review (7.12)

Establish procedures in line with the enterprise development and change standards that require a postimplementation review of the operational information system to assess and report on whether the change met customer requirements and delivered the benefits envisioned in the most costeffective manner.

(Additional information regarding CobiT® can be viewed at http://www.isaca.org)

While SDLC Process documentation is heavily impacted by supporting programs, such as Steering Committee and overall Project / Program Management, Training and Quality Assurance, cooperation between these groups is necessary to the production acceptance of any major release and in some conditions, even simple enhancement to previously released code. Artifacts of these procedures can include process profiles, detailed workflow diagrams, committee presentations and even on line help files, but the true nature of software development controls evidence can only be demonstrated through the appropriate use and capture of controls over the policies and procedures for the development and release of all associated software and code. Modern forms of evidence generally must:

• Demonstrate an existing system context in the form of functional, transaction process and infrastructure diagrams (e.g., highlevel business process flow schema).

• Quantify by class, a hierarchical data flow/control flow decomposition. • Include control transformations. • Allow for minispecifications. • Maintain data dictionaries. • Consider all external eventsinputs from external environment. • Track by change any and every single transformation data flow diagrams with extreme emphasis towards data

input, transformation, verification, validation and output controls. Consider the seven Information Criteria as represented in review of IT Governance Controls by ISACA

Figure 13. Information Criteria

Regardless of domain, process outputs are reviewed in the context of their effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability. Given the scenario of software development programs, information criteria might be applied to elements such as the following:

• Code Libraries • Restore by code revision and secure retrieval process • Meeting Minutes as visible in tracking systems • Risk Evaluation Definition and Risk Review • Anomaly Measures and Reporting




• Enhancement Request Tracking • Quality and Test Tracking • Test Plans • Project Milestone Tracking • Data Dictionary • Defect, Enhancement or Error Tracking • Production Acceptance guidelines • Post Implementation Review • Customer Satisfaction Ratings • Service Level and Operating Level Requirements

Version control software, or tools that capture a roll back state, are sometimes confused with full scale software development tracking applications. Online Programming Facilities (integrated Development EnvironmentlDE), however, must extend far beyond a snapshot and restoration to previous version of code. While software projects may have once been characterized as a routine process of delivering code to a single business unit, involving a homogenous development teams using a single platform and familiar technology, today’s project can be characterized quite differently. Typical projects integrate efforts by dozens of developers in multiple countries, involving three or more business streams, traversing varied platforms and applications, accepting some degree of technological uncertainty and unfamiliarity, and satisfying the requirements of disparate organizations that may not have organic opportunities to seek consensus or even share awareness of each other’s requirements. Add to this at least one major vendor, market projections for cost and completion and increasingly regulated and complex electronic transaction processes. A code snapshot doesn’t suffice.

Programming tools are not enough to facilitate effective use of structured programming methods in the path of measured service delivery. Highly skilled program teams require systems to enable proper use of best practice, including protection of their own use or misuse as a primary IT resource. Mature shops leverage an online programming facility as part of an integrated development environment. This practice alone, however, cannot assure mature product delivery. Software departments require SDLC products, where the suite of modules includes inputs beyond those of the programmer and to include all members in the path of a Service Application. While an IDE provides programmers ability to code and compile programs interactively with a remote computer, it cannot efficiently and effectively control workflow, to say nothing of risk management.

In fact, the IDE alone can facilitate our most tremendous control weakness in IT, being capacity to enter, modify, and delete programming code, as well as compile and store programs (source and object) on a single workstation without prior plan, authority or approval. While affording required reporting, the online facilities also can be used by non IS staff to update and retrieve data directly from computer files. While this is a business requirement, without proper controls, it is also an inherent control risk.

What elements are captured during the flow diagramming process? Steve Covey’s often quoted “Begin with the end in mind” principle applies well to the question of “what do I need to capture during the process flow diagramming process?” Accurate, versus incomplete requirements are said to represent the single greatest factor in software development success. Consider that the process of gathering requirements provides many opportunities to communicate attributes needed for successful documentation of software and business controls. Regardless of the applications used to document requirements, using common terms and controls definitions, such as those found in CobiT® 4.0 will dramatically shorten time spent on software design and control documentation. The following image is intended as suggested content captured by control objects in a process flow diagram. Such objects might be found in virtually all process modeling and development tracking systems. The effort to apply controls language to the documentation of responsibility is a process driven by people, and best facilitated by current and mature software development tools.




When selecting tools for the alignment of SDLC with regulatory and audit reporting requirements, consider that the product must:

• Easily and clearly represent main components, objectives and user requirements, while identifying areas that require controls

• Provide means for capture, evaluation and rank of the major risks to, and exposures of, the system • Include how each control is monitored and what ensures controls are implemented such tht control owners

determine their effectiveness, for example that business users review business requirements, data owners review data access, end users affirm adequacy of training materials and documentation, and so on

• Verify that any software development and change tracking system include: • Work order and related task assignment history, status, duration and outcome • Segregated tracking of system and role based access such as console logins and logouts by programmers,

ticket updates by end users, program authorization by the business. • Ensure existence of a reasonable explanation for all program deletions

• Document and assign owners to events based in a system maintenance process: • business authorization, • regression testing where code or hardware integration affect end user processing, and • record of post maintenance test results or any other audit evidence.

• Verify through test and frequent checks, the adequacy of production library security • Integrate process controls between configuration management, problem management and change

management in the process to ensure the integrity of the production resources The following charts and flow diagram shows IT Programs in relation to the Software development Lifecycle. The triangle objects represent audited CobiT® controls, with focus to AI7 and including additional controls from supporting programs.

Figure 14. Process Inputs and Outputs, RACI Chart for AI7 as found in CobiT® 4.0, Copyright of ISACA®




Goals and Metrics as described in CobiT® 4.0, Copyright of ISACA®




Figure 15. Process Flow Diagram: How are software development artifacts captured in system event logs and software design templates?

Controls and Application Controls

When do I need to document specific control processes? The output of any policy or process includes a list of quality measures. Quality is measured by a set of controls or tests, each designed to provide feedback or align our actions to those policies and procedures.

A “control” over process is characterized by ability to:

• Communicates Repeatable Intention • Executes As Planned (Implementation Plan) • Measure (Risk Measurement & Impact Analysis) • Record (Management Reporting & KPI) • Respond (Thresholds) • Archive (Defined Data Retention) Controls require a visible and recognized: • Name • Owner • Method –(Automation or Manual) • Program • Frequency • Test • Activity Definition • Location • Test Evidence • Information Processing Objective • Sequence ID and method of tracking

How do we manage all these requirements?

MKS Integrity Manager for process and workflow management of enterprise software development MKS Integrity Manager is an excellent example of Software tools providing flexible process and workflow management, while facilitating common best practice for managing software development. This tool seamlessly marries with MKS Source Integrity Enterprise for full enterprise software configuration management, is the foundation for MKS Requirements for requirements management and integrates other developer productivity tools to leverage software investments and enhance coverage of the software.




MKS Integrity Manager Image is copyright of MKS http://www.mks.com

The MKS Integrity suite enables development as it occurs in a service delivery model. Inputs from Project Management and Help Desk are built into the workflow with controls placed in points of emphasis to a program designed specifically for product development and release. An additional highlight is this products ability to integrate with most known IDE’s and to operate in any well established technology platform as it exists today.

Even if popular voting for your personal IT motto puts “you can’t please everyone” in a tie with “did you want it good or did you want it fast?” MKS offers a degree of supplanted process maturity representing a bump to at least level two across most maturity measures of SDLC. (See Maturity Model in text below). MKS integrity manager integrates IT processes, platforms and tools while guiding software development teams through the most common input and outputs, rat holes and handshakes found among all IT shops today.

How mature do we really need to be?

Figure 16. Maturity Toolbox, as represented by ISACA and CMU as the common maturity model or CMM

Install and Accredit Solutions and Change, is a significantly important control for any IT organization. Without these controls existing to some level, it is unlikely that any form of business could thrive. Consider, however, that most companies could be described as having attributes resembling the descriptions for “initial” or “repeatable” maturity. Would this be mature enough to achieve the milestone found in the Enterprise Strategy? That is a decision for each company and its leaders. Here are some of the CobiT® maturity definitions for the Install and Accredit Solutions and Change process area.

CobiT® 4.0 Defines Repeatable to Optimized SDLC related practice in the follo wing way:

• *(Install and Accredit Solutions and Changes) Repeatable but Intuitive: There is some consistency amongst the testing and accreditation approaches, but typically they are not based on any methodology. The individual development teams normally decide the testing approach and there is usually an absence of integration testing. There is an informal approval process.

• Defined Process: A formal methodology relating to installation, migration, conversion and acceptance is in place. IT installation and accreditation processes are integrated into the system life cycle and automated to some extent. Training, testing and transition to production status and accreditation are likely to vary from the defined




process, based on individual decisions. The quality of systems entering production is inconsistent, with new systems often generating a significant level of postimplementation problems.

• Managed and Measurable: The procedures are formalized and developed to be well organized and practical with defined test environments and accreditation procedures. In practice, all major changes to systems follow this formalized approach. Evaluation of meeting user requirements is standardized and measurable, producing metrics that can be effectively reviewed and analyzed by management. The quality of systems entering production is satisfactory to management even with reasonable levels of postimplementation problems. Automation of the process is ad hoc and projectdependent. Management may be satisfied with the current level of efficiency despite the lack of postimplementation evaluation. The test system adequately reflects the live environment. Stress testing for new systems and regression testing for existing systems are applied for major projects.

• Optimized: The installation and accreditation processes have been refined to a level of good practice, based on the results of continuous improvement and refinement. IT installation and accreditation processes are fully integrated into the system life cycle and automated when appropriate, facilitating the most efficient training, testing and transition to production status of new systems. Welldeveloped test environments, problem registers and fault resolution processes ensure efficient and effective transition to the production environment. Accreditation takes place usually with no rework, and postimplementation problems are normally limited to minor corrections. Postimplementation reviews are standardized, with lessons learnt channeled back into the process to ensure continuous quality improvement. Stress testing for new systems and regression testing for modified systems are consistently applied.

* (Spelling is altered for US English) Not every organization will set SDLC targets on “optimized”, but one thing is certain. Any organization with strategy towards level five Software Development practice needs evidence of system based controls as seen in the MKS Integrity Manager Suite.

Figure 17. How are software development artifacts captured in system event logs and software design templates?




Test Scripts, Utilities and Event Tracking Systems

What Is A Test Script Or Test Templates? Programs, systems and releases have associated tests and test results. QA and Security maintain secure test plans and test results. Tests related to Software Quality are run from, and secured in, the [Name of Testing or Quality Assurance Application] Application.

Security scripts and networking utilities are maintained in secure location with the highest degree in limited access. These items are by design, neither visible or accessible to the general user.

Where Do I Find QA Test Templates? Test templates are maintained in the QA Process directory

\\...\PAL\IT Process Asset Library\Quality Assurance\Template\

Security Program Test templates are maintained in Security Management directory

\\...\PAL\IT Process Asset Library\Security Management\Program Test Plans\

Assets, Inventories and Configuration Baselines Networking devices, servers and application servers have both inventory and configuration control requirements. Configuration baseline refers to the minimum secure configuration applied to any device at build. Changes to the configuration beyond this point are associated to business requirements, product release and project management. Data Center Operations and Support manage an inventory of items and baseline configuration. These records are tables in Facilitated Compliance Management™ but are scheduled to be moved into [Name of core product or service].

Where configuration records include IP addressing and other information that could be used to compromise network security, the information is not made available beyond person’s who support and networking and [Name of core product or service] platform availability.

When Do I Need To Create A Controlled Server Object?




Consider whether the following statements are true.

Figure 18. Should I document a controlled server in our system inventory database?

Where Are Devices Inventoried As Assets? Controlled Server Records will reside in [Name of core product or service] but are currently staged in Facilitated Compliance Management

Where Do I Find Server Control Records? \\...\pal\Facilitated Compliance Management\Shortcut to Controlled Servers in Facilitated Compliance Management




Figure 19. Controlled Server Form




Figure 20. Each controlled item has associated security exemptions and standard OS and Application build

Which Tools Store Server and Application Information? The data center maintains a list of devices and tools or applications with their respective controls and resource owners. This information is maintained in Facilitated Compliance Management. All systems, applications or Tools are inventoried assets. Software Control applications must address all points of handoff in a software development and support lifecycle.




Where Is The List Of Tools And Tool Types? Tools and Tool types are listed in the Tools and Tool Type table in the Facilitated Compliance Management2000FCM database. Servers and devices are recorded in the Controlled Server Form, located in the Facilitated Compliance Management™ database.

Controls and Key Controls

When Do I Need To Document A Control Object? Controls practices provide reasonable assurance that business rules exist and are optimized such that negative impact of undesirable events are captured, responded to and mitigated. IT Control is the right mixture of policies, procedures, practices and organizational structures that assure business objectives are met, while preventing, detecting or correcting any or all undesired events.

Control Definitions exist within each process and are an inherent feature in policy.

Control Over Process Is Demonstrated When:

• It Communicates Repeatable Intention • Executes As Planned (Implementation Plan) • Measures (Risk Measurement & Impact Analysis) • Records (Management Reporting & KPI) • Archives (Defined Data Retention) • Control Items capture • Control Name • Owner • Control Method • Automation or Manual • Program • Frequency • Test Information • Activity Definition • Location of Test and Test Evidence • Information Processing Objective • Sequence ID and Key Tracking




For more information, review section Document Elements: Flow Diagram , “Visio Shapes and Custom Properties for Evidence of Process Controls”

Where Are Controls Catalogued? Controls are catalogued by Name, Associated Processes and Owners within Technology’s [Name of core product or service] system. The information is used for ongoing Control Self Assessment and Compliance Documentation. Controls are catalogued in Facilitated Compliance Management™ and in [Name of core product or service]. Controls are also identified within every Process Flow Diagram and Program Definition. Key Controls align to the CobiT® framework and are visible on the Control Self Assessment form within Facilitated Compliance Management™.

Figure 21. What Process Engineering, Auditors and Quality Gather Regarding Corporate Key Controls




Process Diagrams call information from the Facilitated Compliance Management™ database. Key controls pull information from the Key Controls Table.

Example of a Key Controls

Figure 22. Key Controls Form

Where Do I Find The Form or Template? http://www.COMPANY.com TechnologyControls (Login Required)

\\...\PAL\Templates\Internal Control Testing Template.dot




Product, Application Development and Quality Templates Object Name Function Owners Approve

Date

Change Committee Review Board

The Change Committee Review Board Template guides the completion of documentation for the purpose of enterprise or high priority/impact Change Management.

[Name of Chief Technology Officer]

Change Review Board Checklist

Checklist identifies validation items before a change control can be approved or closed

©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA, Emergency Deployment Authorization

Emergency code change requires written approval by Quality, Development, and CTO. The Emergency deployment form represents signed approval by all necessary parties and is submitted to the Network or Data Center Operations prior to emergency deployment of code to production. Emergency change is subject to Change Management policy and is reviewed prior to and post change implementation.

[Name of Chief Security Officer]

High Level Test Plan Template is used to document high level aspects of a test plan

[Name of Chief Technology Officer], [Name of Quality Assurance Manager]

ICQ Physical Security Template is used to generate a new unique instance of ICQ Physical Security. Templates, when used, constitute a work product, which is processed and then stored as control evidence in the \\...\PAL\IT Process Asset Library\Process and Procedures\Security Management\Template\ folder

[Name of Chief Security Officer], [Name of Chief Technology Officer]

ICQ Security Policy Template is used to generate a new unique instance of ICQ Security Policy. Templates, when used, constitute a work product, which is processed and then stored as control evidence in the \\...\PAL\IT Process Asset Library\Process and Procedures\Security Management\Template\ folder.


Implementation Planning Template

Provides documentation format for an implementation.

[Name of Process Librarian]

Internal Control Testing Template

Template is used to document all aspects of testing an internal control


Meeting Agenda and Minutes.dot





Object Name Function Owners Approve Date

Meeting Form Letter This letter is linked in console as a template. [Name of Process Librarian]

Meeting Minutes Template.dot


Network Change Identification Form

Template is used when changes and/or security violations are found on the network, to systems, or to servers that did not go through the formal change control process.


Policy Profile

Process Profile Template

Template is used to document all areas of a process [Name of Process Librarian]

Program Profile Template

Template is used to document all areas of a program [Name of Process Librarian]

Project Charter Template is used to document the scope, assurance and resources of a project


Project Plan Definition Template is used to document all areas of a Project Plan

QA Planning Kickoff Check List

Template is used to guide documents and tasks needed prior to QA Planning

Request For Exemption Template is used to document all areas of risk associated with requested exemption


June 23, 2005

Request For Removal of Media

Template is used to generate a new unique instance of Request For Removal of Media Template. Templates, when used, constitute a work product, which is processed and then stored as control evidence in the \\...\PAL\IT Process Asset Library\Process and Procedures\Security Management\Template\ folder.


Requirements Completeness Checklist

Template is used to guide review of requirements to assure completeness across all areas.

, [Name of Product or Project Management Director]

Risk Criteria Template is used to generate a new unique instance of Risk Criteria Template. Templates, when used, constitute a work product, which is processed and then stored as control evidence in the \\...\PAL\IT





Process Asset Library\Process and Procedures\Security Management\Template\ folder.

RunBook Security Section What to Describe

Template is used to generate a new unique instance of RunBook Security Section What to Describe Template: (For financial/high risk servers). Templates, when used, constitute a work product, which is processed and then stored as control evidence in the \\...\PAL\IT Process Asset Library\Process and Procedures\Security Management\Template\ folder.


Secure Email and File Transfer

Template is used to document electronic security regarding email and file transfer.


Security Infrastructure Plan

The purpose of the Security Infrastructure Plan is to establish strategic, tactical and annual information security plans for COMPANY.


Security Program and Program Test Profile

Template is used to generate a new unique instance of Security Program and Program Test Profile Template. Templates, when used, constitute a work product, which is processed and then stored as control evidence in the \\...\PAL\IT Process Asset Library\Process and Procedures\Security Management\Template\ folder.

Situation Evaluation Form

Template is used to used to capture and fully develop and analyze security risks.


Software Requirement Specifications Template

Template is used to document all requirements for software

Thom Gray, [Name of Product or Project Management Director]

RunBook Template The RunBook or System Documentation book contains information necessary to run and maintain a core business system. In the event of emergency staffing change, this document serves to guide a new employee through the support of this system.

System Operational Requirement

Template is used to document all operational requirements for a system

Test Plan Template Template is used to document all areas of a Test Plan





User Access Program Checklist

Template is used to generate a new unique instance of User Access Controls Work Program Template. Templates, when used, constitute a work product, which is processed and then stored as control evidence in the \\...\PAL\IT Process Asset Library\Process and Procedures\Security Management\Template\ folder.


Employee Warning Notice

Template is used to warn an employee when they do something inappropriate and how to improve.

Job Analysis Questionnaire

Job Analysis Questionnaire template is used to describe employee’s responsibilities and duties among other things.

Job Description Template

Template is used to provide a brief description of the general nature of the position, an overview of why the job exists, and what the job is to accomplish.




Which Tool Stores Process and Work Instruction information? Process Engineering manages a list of all Work Instructions and Processes in the Facilitated Compliance Management™ Object table. There are a variety of reports that summarize the function for all processes as well as provide an overview of all process flow diagrams.




Figure 23. Facilitated Compliance Management™ provides summary reports for many object types

Figure 24. Facilitated Compliance Management™ Allows Process Librarian to capture and catalogue all process objects

Flow Diagram

When Do I Use A Flow Diagram? Flow Diagrams are developed to provide a high level summary of steps in any process or procedure. They are “High Level”, not vague. Controls are also listed in Flow Diagrams, further demonstrating constraints that either prevent error or reinforce correct movement. Key control template objects are created by process engineering in response to the current controls in scope for audit. These items detail all aspects that control a




process.




Figure 25. Sample of A Business Process




Visio Shapes and Custom Properties for Evidence of Process Controls

Name* Description*

Document Title, Scope, Revision, Release Date, Editors, Affirmation Team

Always Sequence 0.0

Reference to other process documents and to full processes outside of the scope of the current document.

Part of processes sequence

Identifies process activity, noting control issues and potential gaps, owners and event sequence.


Decision point and criteria for movement


Grouping allows representation of simultaneous events

Sequence should parent child the sub group of activities

Loop limits usually reflect key controls




Name* Description*

Data Management: What data is used, how is it classified, retained, transferred, accessed

List of external documents used to complete process, status of use in controls evidence, creation frequency, description of use

Sequence is always 9.9 so that all data sources are clustered to the bottom of the process report.

Exit and entrance criteria for movement from one activity to the next. Where criteria for movement is monitored by a system and is critical to control activity, this should be filled in. Where this is true, there would be an expected control.

Trigger and Exit criteria

Sequence is always 0.1 so that all triggers and exit criteria are clustered to the top of the process report.




Name* Description*

Control Documentation Object:

Drop down menu choices include common language for defining controls as expressed by ISACA, PCAOB, PwC, E&Y, KPMG, Deloitte and SANS. Information entered to this area, it is available to controls reporting for this process. The sequence is used to align the control to the associated activities that use this control. Where a control is used in multiple instances, it need only be described once and then mentioned on the activity object.

When a control is inadequate, the issue is identified in the GAP commentary of the activity needing more stringent control. This forces the relative risk of the control gap to be evident to the viewer and writer

Database name and DBA/SA owners

Sequence is always 9.8 so that all data sources are clustered to the bottom of the process report.




Grouping Box

Loop Limit

Database

Process Title Date:

Affirmation Team:

Parent Process (indicates another process diagram)

0.0a

#.# Decision

Figure 26. Process Objects with properties




Acronym Glossary and Definitions Acronyms Definition

Approver An individual who reviews the change to ensure the integrity and reliability of the document and grants approval for the document to be posted.

Document Owner Manager designated as having ownership of all documents associated with the production system and, thereby, having the authority to change it.

Dual control Two people are required for an important activity to be accomplished.

Employee Person, including contractors and temporary staff, who have been granted access to ARL resources.

Owner Manager of a department or business unit responsible for production processes, systems, applications, platforms or users. In accordance with Information Security policies, and standards, owners determine the level of sensitivity and confidentiality of their information. As such, they determine changes, access and dissemination of their information.

Activity An element of work performed during the course of a project. An activity normally has an expected duration

CISA Certified Information Systems Auditor

CobiT® The COBIT® (Control Objectives for Information and Related Technology) framework was released in 1996 and updated in 1998 and 2000 by the Information Systems Audit and Control Association (ISACA) in response to the need for a reference framework for security and control in information technology. In 2000, the IT Governance Institute and ISACF developed the Management Guidelines for COBIT. These guidelines respond to a need by Management for control and measurability of IT, for the purpose of ensuring that IT activities achieve business objectives.

Control The policies, procedures, practices and organizational structures designed to provide reasonable assurance that business objectives will be achieved and that undesired events will be prevented or detected and corrected

Document or Source Document

A sample document that adheres to the criteria necessary for completion of a process and includes the essential contents defined in the template.

Function A group of related actions contributing to a larger action. Security Policy, Access Control, and Perimeter Security represent security functions.

IT Control Objective A statement of the desired result or purpose to be achieved by implementing




Acronyms Definition

control procedures in a particular IT activity

ITIL Information Technology Infrastructure Library

Process A series of tasks that transform inputs into desired outputs. The term procedure is sometimes used interchangeably with process in this methodology. Administer Accounts, Perform Risk Assessment, Audit Perimeter Security, Install Hardware are example

Process Management Architecture

A high level description of the system that provides a fully integrated Knowledge Base [of process information]. The Knowledge Base in turn provides control of process change and access to all processes and procedures.

Task A task is a specific action performed as part of a process. Disable accounts, Interview Network Manager, and run Crack on the Unix machine are examples of security tasks.

Template A skeleton document, spreadsheet, or graphic presentation that represents the essential requirements for deliverable content.

Comprehensive Glossary of all Corporate Terms \\...\pal\Facilitated Compliance Management\Shortcut to Glossary in Facilitated Compliance Management2000FCM.MAT

Related Documents The CobiT® 4.0 (Control Objectives for Information and Related Technology) framework was released in 1996 and updated in 1998 and 2000 and most recently in 2005, by the Information Systems Audit and Control Association (ISACA®) in response to the need for a reference framework for security and control in information technology. In 2000, the IT Governance Institute and ISACA developed the Management Guidelines for COBIT. These guidelines respond to a need by Management for control and measurability of IT, for ensuring that IT activities achieve business objectives. http://www.isaca.org/cobithorizon.htm

The IT Infrastructure Library, ITIL (®), is a series of documents that are used to aid the implementation of a framework for IT Service Management (ITSM). This framework defines how Service Management is applied within specific organizations. Being a framework, it is completely customizable for application within any type of business or organization that has a reliance on IT infrastructure. http://www.itilitsmworld.com/

Project Management Skill and Knowledge Requirements in an Information Technology Environment (ISACA)

http://www.phoenixprocessconsulting.com/security/ProcessProject/projectmanagement.pdf

Extended Bibliography Agency Security Practices. STIGs, Security Technical Implementation Guides. Retrieved December 1, 2005 from http://csrc.nist.gov/pcig/cig.html.

ACLU, (American Civil Liberties Union). Free Speech. Retrieved November 1, 2005 from http://www.aclu.org/freespeech/index.html.

AICPA, American Institute of Certified Public Accountants. Retrieved December 1, 2005 http://www.aicpa.org/index.htm.




ANSI. U.S. National Conformity Assessment Principles. Retrieved December 1, 2005 from http://www.ansi.org/conformity_assessment/ncap.aspx?menuid=4.

Berinato, Scott, Darwin Magazine, http://www.darwinmag.com/read/0502/apples.html.

BSI, British Standards Institute, "BS ISO/IEC 17799:2005", in British Standard ISO/IEC 27001:2005, London, United Kingdom: The Stationary Office, 2005.

CESG (UK) & NIST (USA). Common Criteria, An Introduction. Retrieved December 1, 2005 from http://www.commoncriteriaportal.org/public/files/ccintroduction.pdf. Note: "The Common Criteria work is an international initiative by the following organizations: CSE (Canada), SCSSI (France), BSI (Germany), NLNCSA (Netherlands), CESG (UK), NIST (USA) and NSA (USA)", p. 2.

CIS, Center for Internet Security. CIS Benchmarks/Scoring Tools. Retrieved December 1, 2005 from http://www.cisecurity.org/bench.html.

CISWG (2004). Corporate Information Security Working Group, Report of the Best Practices and Metrics Teams. Retrieved December 1, 2005 from http://www.educause.edu/ir/library/pdf/CSD3661.pdf.

Clark, James Bryce (jamie.clark@oasisopen.org), Shearman & Sterling, New York, http://www.oasis open.org/who/tab.php#jclark.

CMU/SEI, Carnegie Mellon University/Software Engineering Institute. Retrieved December 1, 2005 http://www.sei.cmu.edu/.

COBIT®. Is a product of ISACA®, a global notforprofit professional membership organization focused on IT Governance, assurance and security, with more than 60,000 members in more than 140 countries. ITGI undertakes research and publishes COBIT®, an open standard and framework of controls and best practice for IT governance."ISACA, Information Systems Audit and Control Association. http://www.isaca.org/.

http://www.isaca.org/Template.cfm?Section=CobiT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID =55&ContentID=7981.

COSO, Committee of Sponsoring Organizations of the Treadway Commission. Retrieved December 1, 2005 http://www.coso.org/.

Deming, Edwards (1986), "14 Points for Management", in Out of Crisis, 1986, Cambridge: The MIT Press, http://www.deming.org/resources/books.html.

EDUCAUSE & Internet2, Computer and Network Security Task Force, EDUCAUSE/Internet2 Computer and Network Security Task Force.

Governance Assessment Tool for Higher Education, http://www.educause.edu/ir/library/pdf/SEC0421.pdf.

ECS, Education Commission of the States (2002). Citizenship Education Inclusion in Assessment and Accountability Systems. Retrieved December 1, 2005 from http://mb2.ecs.org/reports/Report.aspx?id=107.

FASP, Federal Agency Security Practices, "STIGs, Security Technical Implementation Guides", http://csrc.nist.gov/pcig/cig.html.

FERF, Financial Executives Research Foundation, http://www.fei.org/rf/.

FFIEC, Federal Financial Institutions Examination Council. Retrieved November 1, 2005 http://www.ffiec.gov/.

FIPS, Federal Information Processing Standards Publication, http://www.itl.nist.gov/fipspubs/.

Frye, Emily, “Cybersecurity and Corporate Governance Now: Does It Take Liability to Get Attention?”, in American Bar Association, Section Of Science & Technology Law, Chicago 2005, http://www.documation.com/aba/pdfs/004.pdf.

GAAP, Generally Accepted Accounting Principles, http://www.fasab.gov/accepted.html.




GAO Accounting and Information Division (1999). FISCAM, Federal Information System Controls Audit Manual Volume I: Financial Statement Audits, Washington: Government Accountability Office. Retrieved December 1, 2005 from http://www.gao.gov/special.pubs/ai12.19.6.pdf.

GAO Accounting and Information Division. FISCAM, Federal Information System Controls Audit Manual Volume I: Financial Statement Audits, Washington: Government Accountability Office, 1999. Retrieved December 1, 2005 from http://www.gao.gov/special.pubs/ai12.19.6.pdf.

GAP, Government Accountability Project, http://www.whistleblower.org/template/index.cfm.

Gibaldi, Joseph (2003), MLA Handbook for Writers of Research Papers, 6th Edition, http://www.mla.org/handbook.

GPO, Government Printing Office. Retrieved December 1, 2005 http://www.gpoaccess.gov/index.html.

Gruber, Tom, What is an Ontology?, KSL, Knowledge Systems, AI Laboratory, Stanford University. Retrieved December 1, 2005 from http://wwwksl.stanford.edu/kst/whatisanontology.html. Note: “An ontology is an explicit specification of a conceptualization. […] We use common ontologies to describe ontological commitments for a set of agents so that they can communicate about a domain of discourse without necessarily operating on a globally shared theory."

IEC, International Electrotechnical Commission. Retrieved December 1, 2005 http://www.iec.ch/.

ISSA, Information Systems Security Association. Retrieved December 1, 2005 http://www.issa.org/.

ISO 16609:2004 Banking Requirements for message authentication using symmetric techniques

ISO/TR 17944:2002 Banking Security and other financial services Framework for security in financial systems

ISO/TR 19038:2005 Banking and related financial services Triple DEA Modes of operation Implementation guidelines.

ISO TC Portal. Standards Development Processes. Retrieved December 1, 2005 from http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3146825/4229629/sds_base.htm.

ISO & CASCO, ISO/IEC Guide 60:2004 Conformity Assessment Code of Good Practice, Geneva: ISO Store. Retrieved December 1, 2005 from http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37035&ICS1=3&ICS2=120&IC S3=20&showrevision=y.

ISO. General information on technical committees. Retrieved December 1, 2005 from http://www.iso.ch/iso/en/stdsdevelopment/tc/TC.html.

ISO. "Achieving Optimal Output", in ISO Annual Report 2004, 2004, Chapter 4. Retrieved December 1, 2005 from http://www.iso.ch/iso/en/aboutiso/annualreports/pdf/chapter4.pdf.

ISO. The Agreement on technical cooperation between ISO and CEN (Vienna Agreement). Retrieved December 1, 2005 from http://isotc.iso.org/livelink/livelink.exe/fetch/2000/2122/3146825/4229629/4230450/4230458/customview.html?f unc=ll&objId=4230458&objAction=browse&sort=subtype

ITGI, IT Governance Institute. Retrieved December 1, 2005 http://www.itgi.org. Note: ITGI describes itself as "The IT Governance Institute (ITGI) exists to assist enterprise leaders in their responsibility to ensure that IT is aligned with the business and delivers value, its performance is measured, its resources properly allocated and its risks mitigated." and "[ITGI] is a notforprofit research organization affiliated with the Information Systems Audit and Control Association®

ITGI & OGC (2005). Aligning COBIT®, ITIL® and ISO 17799 for Business Benefit. Retrieved December 1, 2005 from http://www.isaca.org/.




ITGI & ISACA (2004). COBIT® Mapping, Overview of International IT Guidance. Retrieved December 1, 2005 from http://www.isaca.org/Content/ContentGroups/Research1/Deliverables/CobiT_Mapping_Paper_6jan04.pdf.

ITGI & ISACA (2004). It Control Objectives for SarbanesOxley: The Importance of It in the Design, Implementation and Sustainability of Internal Control over Disclosure and Financial Reporting. Retrieved December 1, 2005 from http://www.isaca.org/Content/ContentGroups/Research1/Deliverables/IT_Control_Objectives_for_Sarbanes Oxley_7july04.pdf.

ITTF, ISO/IEC Information Technology Task Force. Retrieved December 8, 2005 http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm. Note: ITTF maintains access to all freely available ISO standards, a list that grows daily, and on December 8, 2005 included 253 free ISO standards.

ITIL®, Information Technology Infrastructure Library. Retrieved December 1, 2005 http://www.ogc.gov.uk/index.asp?id=2261.

ITTF. Freely Available Standards. In accordance with ISO/IEC JTC 1 and the ISO and IEC Councils these International Standards are publicly available. Retrieved December 1, 2005 from http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm. Note: The standards are available for download at the ITTF web site. This does not imply free use or permission to copy any materials found. The files are in zip format. I had no difficulty with them but always use a staging are to run additional anti virus/spyware before opening anyone’s files: http://standards.iso.org/ittf/PubliclyAvailableStandards/c040612_ISO_IEC_154081_2005(E).zip, http://standards.iso.org/ittf/PubliclyAvailableStandards/c040613_ISO_IEC_154082_2005(E).zip, & http://standards.iso.org/ittf/PubliclyAvailableStandards/c040614_ISO_IEC_154083_2005(E).zip

KNET. Retrieved December 1, 2005 http://www.isaca.org/knet. Note: KNET is provided by ISACA as a professional resource and describes it as "a global knowledge network for IT Governance, Control and Assurance" and “KNET contains over 5,200 peerreviewed web site resources pertaining to knowledge covering IT Governance, Assurance, Security and Control. Full access to KNET is reserved for association members. In addition, a personalized tracking feature […]. Reference items are organized into logical categories of interest and concern".

Lawrence W. Smith, "The FASB’s Efforts Toward Simplification", in The FASB Report, February 28, 2005. Retrieved December 1, 2005 from http://www.fasb.org/articles&reports/fasb_efforts_toward_simplification_tfr_feb_2005.pdf. Note: This article summarizing Bob Herz, FASB chairman of Financial Accounting Standards Board to show the complexity of GAAP as it relates to application of consistent standards and codification in the current 180 of US GAAP articles within U.S. Code.

McNamara, Robert S. and Morris, Errol, The Fog of War: Eleven Lessons from the Life of Robert S. McNamara, December 2003.

NARA, National Archives and Records Administration. Retrieved December 1, 2005 http://www.archives.gov/.

National Council for Science and the Environment. Congressional Research Service Reports. Retrieved December 1, 2005 from http://www.ncseonline.org/NLE/CRS/.

NASD, National Association of Corporate Directors. Retrieved December 1, 2005 http://www.nacdonline.org/.

NHGRI, National Human Genome Research Institute. Retrieved December 1, 2005 http://www.genome.gov/. United States Congress, "Circular 92", "Copyright Law of the United States of America and Related Laws Contained in Title 17 of the United States Code", in United States Code, Title 17 (1976), Washington, U.S. Government Printing Office, Chapters 18 & 1012.




NIAC, National Infrastructure Advisory Council (February 2003). The National Strategy to Secure Cyberspace, Washington: Department of Homeland Security. Retrieved December 1, 2005 from http://www.dhs.gov/interweb/assetlibrary/National_Cyberspace_Strategy.pdf.

NIST Information Technology Laboratory (2002), International Standard ISO/IEC 17799:2000 Code of Practice for Information Security Management, Frequently Asked Questions, Retrieved December 1, 2005 from http://csrc.nist.gov/publications/secpubs/otherpubs/revisofaq.pdf.

NIST, National Institute of Standards and Technology. FIPS, Federal Information Processing Standards Publication. Retrieved December 1, 2005 from http://www.itl.nist.gov/fipspubs/.

NIST SP 80053 Database Application is available for download at http://csrc.nist.gov/seccert/download800 53database.html

NHGRI, National Human Genome Research Institute, http://www.genome.gov/.

NSSN, National Standards Systems Network, "STAR, Standards Tracking and Automated Reporting, Services", http://www.nssn.org/star_intro.html.

NISO, National Information Standards Organization. Retrieved December 1, 2005 http://www.niso.org/index.html.

Norman Walsh & Leonard Muellner, DocBook: The Definitive Guide, O'Reilly & Associates, Inc., Version 1.0.2 (1999). Retrieved December 1, 2005 from http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html. Note: This is the official documentation for DocBook. & Bob Stayton, DocBook XSL: The Complete Guide, Sagehill Enterprises, Third Edition (2005). Retrieved December 1, 2005 from http://www.sagehill.net/docbookxsl/. Note: This is the definitive guide to using the DocBook XSL stylesheets. It provides the necessary documentation to realize the full potential of DocBook

OASIS (2005). Security Assertion Markup Language (SAML) v2.0. Retrieved December 1, 2005 from http://www.oasisopen.org/specs/index.php#samlv2.0, & http://docs.oasisopen.org/security/saml/v2.0/saml2.0 os.zip.

Office of Management and Budget. "Circular No. A130 Revised", in Transmittal Memorandum No. 4, Memorandum For Heads Of Executive Departments And Agencies. Retrieved December 1, 2005 from http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html.

Office of Management and Budget. "Circular No. A119 Revised, Accompanying Federal Register Materials", in Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities. Retrieved December 1, 2005 from http://www.whitehouse.gov/omb/circulars/a119/a119.html.

OGC, Office of Government Commerce. Retrieved December 1, 2005 http://www.ogc.gov.uk. Note: As explained by the OGC as "[…] a UK government organization responsible for procurement and efficiency improvements in the UK public sector. OGC has produced worldclass best practice guidance, including PRINCE (project management), MSP (Managing Successful Programs) and ITIL® (IT service management). ITIL® is used throughout the world and is aligned with the ISO/IEC 20000 international standard in service management."

OGC, Office of Government Commerce, "ICT Infrastructure Management", in ITIL® Series, London, United Kingdom: The Stationary Office, 2002.

OntoWeb Project, OntoWeb Working Group on Process Standards, http://www.aiai.ed.ac.uk/project/ontoweb/. Amy Knutilla, Craig Schlenoff, Steven Ray, Stephen T. Polyak, Austin Tate, Shu Chiun Cheah and Richard C. Anderson: "Process Specification Language: An Analysis of Existing Representations," NISTIR 6160, National Institute of Standards and Technology, Gaithersburg, MD, 1998.

O'Reilly, Tim, What Is Web 2.0, Design Patterns and Business Models for the Next Generation of Software, 09/30/2005 Retrieved December 30, 2005 from




http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/whatisweb20.html?page=1, What is Web 2.0PricewaterhouseCoopers on behalf of COSO, COSO, Enterprise Risk Management — Integrated Framework, AICPA, Volume 2, https://www.cpa2biz.com/CS2000/Products/CPA2BIZ/Publications/COSO+Enterprise+Risk+Management+ +Integrated+Framework.htm, & COSO (2005), Internal Control — Integrated Framework, Guidance for Smaller Public Companies Reporting on Internal Control over Financial Reporting, AICPA, Exposure Draft, http://155.201.80.182/Coso/coserm.nsf/vwResources/PDF_IC/$FILE/COSO_FINAL_Draft_IC_Guidance.pdf.

PricewaterhouseCoopers, Integrity Driven Performance, White Paper (2004), Page 34, Note: PricewaterhouseCoopers (www.pwc.com) provides industryfocused assurance, tax and advisory services for public and private clients. More than 120,000 people in 139 countries connect their thinking, experience and solutions to build public trust and enhance value for clients and their stakeholders.

PricewaterhouseCoopers on behalf of COSO, COSO, Enterprise Risk Management — Integrated Framework, AICPA, Volume 2. Retrieved December 1, 2005 from https://www.cpa2biz.com/CS2000/Products/CPA2BIZ/Publications/COSO+Enterprise+Risk+Management+ +Integrated+Framework.htm. & COSO (2005), Internal Control — Integrated Framework. & Guidance for Smaller Public Companies Reporting on Internal Control over Financial Reporting, AICPA, Exposure Draft. Retrieved December 1, 2005 from http://155.201.80.182/Coso/coserm.nsf/vwResources/PDF_IC/$FILE/COSO_FINAL_Draft_IC_Guidance.pdf. Note: These are both noted by the SEC as appropriate framework in the implementation of controls assessment.

Ross, Dr. Ron and NIST, Protecting Federal Information Systems and Networks, A Standardsbased Security Certification Program for Operational Environments, http://cio.doe.gov/Conferences/Security/Presentations/RossRNIST.pps.

(Dr.) Ron Ross & NIST. Protecting Federal Information Systems and Networks, A Standardsbased Security Certification Program for Operational Environments. Retrieved December 1, 2005 from http://cio.doe.gov/Conferences/Security/Presentations/RossRNIST.pps.

Dr. Ron Ross & The OWASP Foundation. Building More Secure Information Systems, A Strategy for Effectively Applying the Provisions of FISMA. Retrieved December 1, 2005 from http://csrc.nist.gov/organizations/fissea/conference/2005/presentations/Ross/AbstractRoss.pdf.

SANS Institute, SysAdmin Audit Network Security Institute. December 1, 2005 http://www.sans.org/aboutsans.php.

Skadden Biography, Michael S. Hines, http://www.skadden.com/index.cfm?contentID=45&bioID=2732.

Smith, Lawrence W., "The FASB’s Efforts Toward Simplification", in The FASB Report, February 28, 2005, http://www.fasb.org/articles&reports/fasb_efforts_toward_simplification_tfr_feb_2005.pdf.

Spafford Jr., George, Spafford Global Consulting, Inc., Saint Joseph, MI, http://www.spaffordconsulting.com.

Swanson, Dan and Seccuris Inc., Security Benchmark, http://www.securitybenchmark.com.

The Institute of Internal Auditors. GTAG, Global Technology Audit Guide. Retrieved December 1, 2005 from http://www.theiia.org/index.cfm?doc_id=4706.

TQM, Total Quality Management, http://www.managementhelp.org/quality/tqm/tqm.htm.

U.S. Department of Labor, Bureau of Labor Statistics, Occupational Employment and Wages, November 2004, http://www.bls.gov/oes/current/oes132011.htm.

U.S. Navy, Benefits, "Increasing Contractor Commitment", http://www.ar.navy.mil/aosfiles/tools/turbo/topics/cj.cfm.

United States Congress & Subcommittee on Technology, Information Policy, Intergovernmental Relations and the Census (2004). Oversight Hearing Statement by Adam Putnam, Chairman, Identity Theft: The Causes, Costs,




Consequences, and Potential Solutions. http://www.reform.house.gov/UploadedFiles/Final%20Press%20Opening%20Statement%202.pdf, p. 5.

United States Congress, "DMCA", "Digital Millennium Copyright Act", in Public Law 105304, H.R. 2281, S. 2037, & Congressional Record Vol. 144 (1998), Washington: U.S. Government Printing Office, 112 Stat. 2860 & 2905.

United States Congress, SarbanesOxley Act of 2002, 15 U.S.C. §7201 (2002), "SarbanesOxley Act of 2002", "SOX", in Public Law 107204, H.R. 3763, S. 2673, & Congressional Record Vol. 148 (2002), Washington: U.S. Government Printing Office, 116 STAT. 745810.

United States Congress, "HIPA", "Health Insurance Portability and Accountability Act of 1996", in Public Law 104191, H.R. 3103, S. 1028, S. 1698, & Congressional Record Vol. 142 (1996), 110 STAT. 19362103.

United States Congress, "GLBA", "Gramm–Leach–Bliley Act", in Public Law 106102, H.R. 10, S. 900, & Congressional Record Vol. 145 (1999), Washington: U.S. Government Printing Office, 113 STAT. 13401481.

United States Congress, "FISMA", "Federal Information Security Management Act of 2002", in Public Law 107 347, H. R. 245848, Title III, Washington: U.S. Government Printing Office, SEC 301305.

U.S. Department of Homeland Security. FEMA, Federal Emergency Management Agency. Retrieved December 1, 2005 from http://www.fema.gov/.

United States Congress. "DMCA", "Digital Millennium Copyright Act", in Public Law 105304, H.R. 2281, S. 2037, & Congressional Record Vol. 144 (1998), Washington: U.S. Government Printing Office, 112 Stat. 2860 & 2905. Note: Review of the DMCA reveals in contribution the name of Mike S. Hines, who is frequently in discussion on various ISACA and CMU sanctioned list services. Mike contributes to the Information Security Management group, under ISACA sponsor, mailto:infosec[email protected]. Recommendation, send email with the word “join” in subject and no other text to infosec[email protected]. Here is a chance to speak with a few Eagles.

United States Congress, "Computer Security Enhancement Act of 1997", in Public Law 100418, H.R. 1903, Calendar No. 718, & Report No. 105412 (1998), SEC. 114. Note: "To amend the National Institute of Standards and Technology Act to enhance the ability of the National Institute of Standards and Technology to improve computer security, and for other purposes."

United States Congress, "Cyber Security Research and Development Act", in Public Law 107305, H.R. 3394, S. 2182, & Congressional Record Vol. 148 (2002), Washington: U.S. Government Printing Office, 116 STAT. 2367 2382. Retrieved December 1, 2005 from http://thomas.loc.gov/cgi bin/bdquery/z?d107:H.R.3394:@@@L&summ2=m&. FASP, Federal

United States Congress. "Computer Fraud and Abuse Act", in 18 U.S.C. § 1030, 1986. Retrieved December 1, 2005 from http://cio.doe.gov/Documents/CFA.HTM.

VISA International Service Association, Security Programs, http://corporate.visa.com/st/programs.jsp.

Walsh, Norman and Muellner, Leonard, DocBook: The Definitive Guide, O'Reilly & Associates, Inc, Version 1.0.2 (1999), http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html.




Risks and Associated Controls Significance

Likelihood * Impact

Risk Items Control How implemented and actual review schedule

2 * 5 [RiskWatch id here]

Authorization: In addition to limit of access to documentation from within the corporate network, persons are further restricted from reading and modifying documents through the use of security properties on process asset folders. Approval to post or modify a process is in accordance with management's general policies and procedures. Access to assets is further restricted through the use of hyperlinks in place of attachments, enforcing limits for viewing documents based on the persons profile within the organization.

PAL infrastructure is carefully managed by process engineering, with administrative controls as provided within Windows 2000 server and as enforced by the data owners.

1 * 5 Configuration/Account Mapping Controls: System configuration controls restrict non authorized users from deleting and modifying files. Process approval is required in order to post new or modified process.

Security is managed by Network or Data Center Operations and is enforced by Process Engineering and the Data Owner.


Interface/Conversion Controls: Data Integrity (data is not changed or manipulated) and security (no one can access it). Interfaces/conversion includes controls in these areas. Data management (date/time stamps, file names) Processing (no missing, duplicate, or redundant data and to ensure completeness and accuracy.) Validation/reconciliation (online edits, batch totals) Over the detection and correction of exceptions and errors.

When data cannot be altered without explicit audit trail and approval, it is managed in VSS. When code or documentation appears changed, VSS allows for review of edits and roll back. Data integrity in code is assured via promotion to production process, where code is tested in the Quality environment and then approved for movement. The PAL is backed up nightly and content change is evident via time stamp.


Key Performance Indicators KPI's: Periodic review by Process Engineering enforces the goal of having processes documented for all management functional areas. Where information indicates a need for process optimization, process engineering notes this requirement and reviews

The PAL XLS and inventories within Facilitated Compliance Management™ database allow the Process Engineering team visibility on key performance of process items as required for SAS 70 audit and as agreed upon by department owners.




Significance

Likelihood * Impact

Risk Items Control How implemented and actual review schedule

timely completion of required process change. Process engineering also catalogues reviews and guides process development and collection.

There is Risk that Management may fail to assure that procedures are finished in a timely manner or that existing processes are not routinely reviewed to insure their validity or usability.

1 * 1 3 * 5 [RiskWatch id here] Reconciliation of existing rights within the PAL to rights as designed and approved by department owners demonstrates that persons who should not have access to documentation types are segregated. Roles in the approval process deny persons authority to review and approve their own work.


Risk of accidental or intentional distribution of classified private and or sensitive information:

• Documentation practice

• “Hyperlink vs. Attachment” • manager enforcement of storing • data in proper file location • department role based limit to user access • enforcing control related Data Owners • document property capture of key control data • document classification, are all control activities that make likelihood of this risk negligible. Each business or management functional owner has access to modify contents inside their own area but cannot modify files outside their Process domain. Remaining risk are file shares that still require review for misplaced content.




Figure 27. What Type of Document Should I Write?




Example of PAL Contents File Location, Description of Use Management Function Folder

Document Type Subfolders Content Description

Subfolders allowed Classification

IT Process Asset Library Backup and Recovery

Backup and Recovery Flowcharts

Backup and Recovery Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Backup and Recovery Process and Procedure

Backup and Recovery Process and Procedure folder contains process profile documentation. No Confidential

Backup and Recovery Program Definition

Backups and Recovery Program Definition folder contains program profile documentation. No Confidential

Backup and Recovery Template

Backup and Recovery Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Change Management

Change Management Flowcharts

Change Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Change Management Process and Procedure

Change Management Process and Procedure folder contains process profile documentation. No Confidential

Change Management Program Definition

Change Management Program Definition folder contains program profile documentation. No Confidential

Change Management Template

Change Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Configuration Management




Management Function Folder



Configuration Management Flowcharts

Configuration Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Configuration Management Process and Procedure

Configuration Management Process and Procedure folder contains process profile documentation. No Confidential

Configuration Management Program Definition

Configuration Management Program Definition folder contains program profile documentation. No Confidential

Configuration Management RunBook CMDB

Configuration Management RunBook CMDB folder contains RunBook process and guidelines.

Temporary/ Until all data is moved to database Confidential

Configuration Management Module Configuration

Configuration Management Solutions DevelopmentClient Configuration folder contains program profile documentation. This is limited to the area of Master Template configuration guidelines

Subfolder as needed Confidential

Configuration Management Template

Configuration Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Human Resources

Human Resources Flowcharts

Human Resources Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Human Resources Process and Procedure Human Resources Process and Procedure folder contains process profile documentation. No Confidential

Human Resources Program Definition Human Resources Program Definition folder contains program profile documentation. No Confidential







Human Resources Template

Human Resources Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Network Management

Network Management Architectures

Architecture as Diagrams, long term strategic IT Vision, infrastructure planning and technical documentation.

Subfolder as needed Sensitive

Network Management Flowcharts

Network Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Network Management Process and Procedure

Network Management Process and Procedure folder contains process profile documentation. No Confidential

Network Management Program Definition

Network Management Program Definition folder contains program profile documentation. No Confidential

Network Management Template

Network Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Performance Management

Performance Management Flowcharts

Performance Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Performance Management Process and Procedure

Performance Management Process and Procedure folder contains process profile documentation. This area includes database process optimization. No Confidential

Performance Management Template

Performance Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Process Engineering Management







Process Engineering Management Flowcharts

Process Engineering Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Process Engineering Management Process and Procedure

Process Engineering Management Process and Procedure folder contains process profile documentation. No Confidential

Process Engineering Management Process Profile

Process Engineering Management Process Profile folder contains program profile documentation. No Confidential

Process Engineering Management Template

Process Engineering Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Product Management

Product Management Flowcharts

Product Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Product Management Process and Procedure

Product Management Process and Procedure folder contains process profile documentation. No Confidential

Product Management Program Definition

Product Management Program Definition folder contains program profile documentation. No Confidential

Product Management Template

Product Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Quality Assurance

Quality Assurance Flowcharts

Quality Assurance Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Quality Assurance Process and Procedure Quality Assurance Process and Procedure folder contains process profile documentation. No Confidential







Quality Assurance Program Definition Quality Assurance Program Definition folder contains program profile documentation. No Confidential

Quality Assurance Template

Quality Assurance Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Security Management

Security Management Flowcharts

Security Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Security Management Process and Procedure

Security Management Process and Procedure folder contains process profile documentation. No Confidential

Security Management Program Profiles

Security Management Program Profiles folder contains program profile documentation. No Confidential

Security Management Program Test Plans

Security Management Program Test Plans folder contains security specific program control test plans. No Confidential

Security Management Template

Security Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Software Development

Software Development Flowcharts

Software Development Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Software Development Process and Procedure

Software Development Process and Procedure folder contains process profile documentation. No Confidential

Software Development Program Profiles

Software Development Program Profiles folder contains program profile documentation. No Confidential







Software Development Template

Software Development Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

Standard Operation Procedures

Standard Operation Procedures Forms No Confidential

Standard Operation Procedures General Use Flowcharts

Standard Operation Procedures General Use Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Standard Operation Procedures * RunBook

Output of the RunBook Database is a paper copy of the RunBook. RunBooks live in the database, but a single paper copy may be posted here as SAS70 summary evidence. This folder could also be removed. No Confidential

Standard Operation Procedures SOP By Domain

Standard operating procedures are any set of directions used to maintain or operate any production system.

Folders should be set but if an area is needed/ add Confidential

Standard Operation Procedures

…\Citrix …\Desktop …\LAN Access Distribution …\Oracle DB …\Oracle Server …\SQL Server …\Unix …\VPN …\WAN Backbone …\WINTEL

Each folder is a holding place for short instructions related to the maintenance and care of any technology type. If a person creates any work instructions, be it in email or as a word file, this a place to store a record of the work so that the SOP doesn't have to be created again. SOP is less strict than process in that the owner of the technology maintains their current instructions and does not require approval to add to their folder. Manager is responsible for insuring that any high risk process is documented and that the process could be followed by a person of equal skill in the event that the primary support staff was not available.

Sub folder as needed for specific servers and systems. Sensitive

Standard Operation Procedures Template

Standard Operation Procedures Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential







Support Management

Support Management Flowcharts

Support Management Flowcharts folder contains process flow diagrams including those used in process and procedure documentation. No Confidential

Support Management Process and Procedure

Support Management Process and Procedure folder contains process profile documentation. No Confidential

Support Management Program Definition

Support Management Program Definition folder contains program profile documentation. No Confidential

Support Management Template

Support Management Template folder contains shortcuts to approved templates and forms as required for this management function. No Confidential

IT Work Product Library

Change Management

Change Management

Production Release and Change Review Meetings

This area will be relocated to RiskConsole once the Change Management program is operational No Confidential

Change Management

…\Agendas …\Meeting Minutes Change requests and change review meeting records No Confidential

Network or Data Center Operations Planning and Infrastructure

Network or Data Center Operations Planning and Infrastructure Infrastructure Planning

Documentation pertaining to infrastructure planning and development including any current projects. This area will support numerous project specific subfolders. No Confidential

Network or Data Center Operations Planning and Infrastructure …\133patch

Create a folder for infrastructure item and keep all planning for that change or project in the folder

Sub folder on a per project basis Confidential







Network or Data Center Operations Planning and Infrastructure

Performance Management

Output of monitoring performance, shows evidence of monitoring activity

Sub folder on a per monitoring area as needed Confidential

Process Meeting Minutes

Process Meeting Minutes

Meeting Minutes and Review Planning

Meeting Minutes and approvals for Process Engineering team and program No Confidential

Product Management

Product Management Meetings Meetings pertaining to any release are captured and stored here No Confidential

Product Management Project Planning Release tasks by release and other evidence of project structure No Confidential

Product Management Requirements

Current list of requirements belongs in VSS, but this location is an evidence pointer showing the requirements in play and recent past. This folder should have a short cut the actual location in VSS and someone who can walk the auditor through those folders. No Confidential

Product Management

[Company Core Product or Service] Release Notes Past and current release notes, evidence folder No Confidential

Product Management Module Configuration Output of planning for Master Template service related tasks.

Subfolder as needed Confidential

Product Management Status Reports

Staff reports to managers regarding work activity

Any status provided can be stored here. Phillip can use this to show his oversight of staff and programs Sensitive

Product Training







Product Training

[Company Core Product or Service] User Guide External Product training output/ evidence folder No Confidential

Product Training

[Company Core Product or Service] User Technical Guide Internal Product training output/ evidence folder No Confidential

Quality Assurance

Quality Assurance Quarterly Reports

Documentation pertaining to infrastructure planning and development including any current projects. This area will support numerous project specific subfolders.

Subfolders created by quarter as needed Confidential

Quality Assurance

[Company Core Product or Service] QA Testing By Release

Test planning documentation and a link to the current tests in Test in TestDirector. This is a "pointer file" used to assist auditor in finding the evidence.

Subfolders are not limited. This is a place to store in process work. Confidential

Quality Assurance Test Output

Used to gather the Internal Controls Testing Plans and the most current snapshot of testing as used for evidence in the upcoming SAS 70. The actual testing information must reside in its secure location within TestDirector. This is an output for evidence purposes only.

Subfolders limited to the Internal Control Testing program Confidential

Quality Assurance fs02 main Quality Assurance

the QA folder on FS02 Main should be relocated to the process and work product areas. Confidential

ReleaseSoftware Development








Release PlanEvidence Copy for current review cycle

Documentation in VSS must remain in VSS. This is a pointer file and demonstration of current content on current release. VSS link should be here. No Confidential

ReleaseSoftware Development Release Request

Email outtakes and meeting notes where a release related activity is requested. Release requests live in DevTrack, but can start as emails or notes. This is where the document record is stored. All details would show up as a DevTrack ID. No Confidential


[Company Core Product or Service]

Design Specifications from VSS are here as process evidence and are read only. This is a placeholder for audit data. Auditor should not be in VSS clicking through directories as this would raise issues around items that are out of date. Better strategy is to put what we want to show here. No Confidential

Security Management

Security Management Exemption Requests

Business requests for policy exception based in need to maintain operations with given technology constraints. All exemptions should also be logged in a table where CSO can maintain visibility on such items. RC is good candidate for this, especially as tied to Risk area. No Sensitive

Security Management

...\Situation Evaluation Forms

Output of situation review and decisions based on Exceptions to policy. No Sensitive

Security Management

Meetings Notes and Incident Review Records

Meeting notes from any security meeting or incident response meeting No Sensitive

Security Management ...\ Agendas …\Minutes

Recommend a format for file name that shows Security, date and meeting type. Agenda can be a place holder for meeting plans and meeting minutes are just meeting minutes. No Sensitive

Security Management

Program Policy Approval

Email outtakes and copy of documents indicating approval to implement security programs. I have a concern about storing electronic image of signatures and request that files state that signature is locked in a file.

Straight evidence folder/ NO Sensitive







Security Management

Security Infrastructure and Program Planning

Infrastructure planning document and information related to the planning of any security program.

Create a subfolder for any program. Sensitive

Security Management …\Awareness

Awareness program documents, including planned presentations and documents for the development of the program


Security Management Test Output DS5 related internal control test plans and output

One folder per program tested Sensitive

Security Management

Tracking and Reconciliation Reports Output of security scans and processes.


Security Management

…\Tools ….\...\Last Login Scripts …\...\...\Risklabs Domain …\...\...\Company Domain Evidence of security monitoring activity


Contact the author: http://www.pbandsp.com/cgi/form.html

Procedures and Controls Documentation Guidelines

Documents

Transcript of Procedures and Controls Documentation Guidelines