SlideShare a Scribd company logo
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 1 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 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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 enterprise­level 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 non­production 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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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 time­consuming 
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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Any new folders must be requested via email to the process librarian, currently [Name of Process Librarian], at 
Process@COMPANY.com.  The librarian insures name and contents integrity within Facilitated Compliance 
Management™ process tracking.  ...PALFacilitated Compliance ManagementFacilitated 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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 8 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Audience and Audit Considerations 
This process profile serves as reference for COMPANY.  Groups may be referenced by functional email 
notification names such as Process@company.com.  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, work­specific 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 Process@company.com. 
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,
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 9 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
should be appropriately defined.  This is a co­dependency 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.  End­user 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.
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 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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 process@company.com. 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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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 ...PALTemplates.  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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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?
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 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Where Do I Find the Process Profile Template? 
...PALTemplatesProcess Profile Template.dot 
Figure 3. What are the steps and controls in writing a process profile?
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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? 
...PALTEMPLATESPolicy 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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com
·  Plan and Deliver Personnel Training
·  Implement Cross­Training or Staff Back­up
·  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?
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Where Do I Find The Template? 
...PALTemplatesProgram Profile Template.dot 
Templates that describe positions or assist in the design of a program organizational chart are located in: 
...PALIT Process Asset LibraryHuman ResourcesTemplateJob Description Template.dot 
...PALIT Process Asset LibraryHuman ResourcesTemplateEmployee Warning Notice.dot 
...PALIT Process Asset LibraryHuman ResourcesTemplateJob 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 event­tracking systems and are not centrally located, but are accessible and known 
to all persons within the user department.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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: 
...PALTemplatesWork 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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
·  Fail­over
·  Maintenance
·  Troubleshooting and Error Messages
·  Glossary
·  List of files
·  Financial Processes
·  Test procedure
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 8 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Should I Write A RunBook? 
Consider whether the following statements are true. 
Figure 7. Should I write a RunBook?
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 9 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 10 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 11 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Figure 9. Example Interface for gathering RunBook elements by Service Title
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 12 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Where Do I Find The Template? 
...palFacilitated Compliance ManagementShortcut to RunBook in Facilitated Compliance 
Management2000FCM.MAF 
...palTemplatesRunBook 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? 
...PALIT Process Asset Library
·  Static Process versus Process Output (Evidence of Using Process) 
...PALIT 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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 13 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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? 
...PALIT 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? 
...PALIT WORK PRODUCT LIBRARY
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 14 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Figure 11.  What are the work product folders? 
Current Inventory of Folder and Contents is maintained by Process Engineering, in ...PALIT Work Product 
LibraryProcess EngineeringPAL Folders.xls
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 15 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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 post­implementation 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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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 pre­established plan. An audit trail 
of pre­ and post­conversion 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 year­end production cycles. 
Software Release (7.9) 
Ensure that the release of software is governed by formal procedures ensuring sign­off, packaging, regression testing, distribution, 
handover, status tracking, backout procedures and user notification. 
System Distribution (7.10)
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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. 
Post­implementation Review (7.12) 
Establish procedures in line with the enterprise development and change standards that require a post­implementation 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 cost­effective 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., high­level business process flow schema).
· Quantify by class, a hierarchical data flow/control flow decomposition.
· Include control transformations.
· Allow for mini­specifications.
· Maintain data dictionaries.
· Consider all external events­inputs 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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com
· 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 Environment­lDE), 
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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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®
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Goals and Metrics as described in CobiT®  4.0, Copyright of ISACA®
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 
More from Phoenix Business and Systems Process, http://www.pbandsp.com
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
process, based on individual decisions. The quality of systems entering production is inconsistent, with new 
systems often generating a significant level of post­implementation 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 post­implementation problems. Automation of the 
process is ad hoc and project­dependent. Management may be satisfied with the current level of efficiency despite 
the lack of post­implementation 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. Well­developed 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 post­implementation problems are normally limited to 
minor corrections. Post­implementation 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?
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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 
...PALIT Process Asset LibraryQuality AssuranceTemplate 
Security Program Test templates are maintained in Security Management directory 
...PALIT Process Asset LibrarySecurity ManagementProgram 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?
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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? 
...palFacilitated Compliance ManagementShortcut to Controlled Servers in Facilitated Compliance 
Management
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
Figure 19.  Controlled Server Form
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 8 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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.
Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA 
©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 9 of 80 
More from Phoenix Business and Systems Process, http://www.pbandsp.com 
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
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines
Procedures and Controls Documentation Guidelines

More Related Content

What's hot

Supplier Charge back and Reducing CoPQ
Supplier Charge back and Reducing CoPQSupplier Charge back and Reducing CoPQ
Supplier Charge back and Reducing CoPQ
8020 Consultancy & Interim Services
 
10 Laws of Customer Success
10 Laws of Customer Success10 Laws of Customer Success
10 Laws of Customer Success
Gainsight
 
Standardize the Service Desk
Standardize the Service DeskStandardize the Service Desk
Standardize the Service Desk
Info-Tech Research Group
 
SAP MM_IM Inventory Management
SAP MM_IM Inventory  Management SAP MM_IM Inventory  Management
SAP MM_IM Inventory Management
Lokesh Modem
 
Enterprise Service Management & IT Operations Management Coming Together
Enterprise Service Management & IT Operations Management Coming TogetherEnterprise Service Management & IT Operations Management Coming Together
Enterprise Service Management & IT Operations Management Coming Together
OpsRamp
 
AGS Support Live: SAP Business One Procure to Pay Refresher Training
AGS Support Live: SAP Business One Procure to Pay Refresher TrainingAGS Support Live: SAP Business One Procure to Pay Refresher Training
AGS Support Live: SAP Business One Procure to Pay Refresher Training
AGSanePLDTCompany
 
Sap wm pdf
Sap wm pdfSap wm pdf
Sap wm pdf
acutesoft22
 
Itil v3-foundation-certification-exam2
Itil v3-foundation-certification-exam2Itil v3-foundation-certification-exam2
Itil v3-foundation-certification-exam2
seveman
 
DIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑA
DIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑADIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑA
DIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑA
Pintiparada
 
Demand Generation Maturity Model
Demand Generation Maturity ModelDemand Generation Maturity Model
Demand Generation Maturity Model
Demand Metric
 
OSS Service Assurance -Concept Presentation by Biju M Rr
OSS Service Assurance  -Concept Presentation by Biju M RrOSS Service Assurance  -Concept Presentation by Biju M Rr
OSS Service Assurance -Concept Presentation by Biju M Rr
Biju M R
 
INVENTORY OPTIMIZATION
INVENTORY OPTIMIZATIONINVENTORY OPTIMIZATION
INVENTORY OPTIMIZATION
Rajeev Sharan
 
Salesforce Cloud Infrastructure and Challenges - A Brief Overview
Salesforce Cloud Infrastructure and Challenges - A Brief OverviewSalesforce Cloud Infrastructure and Challenges - A Brief Overview
Salesforce Cloud Infrastructure and Challenges - A Brief Overview
Salesforce Engineering
 
Make the Move to Lightning in 60 Days
Make the Move to Lightning in 60 DaysMake the Move to Lightning in 60 Days
Make the Move to Lightning in 60 Days
Rebecca Saar
 
CRM@Oracle - Customer 360
CRM@Oracle - Customer 360CRM@Oracle - Customer 360
CRM@Oracle - Customer 360
tbOracleCRM
 
ETOM Enterprise Framework Management
ETOM Enterprise Framework ManagementETOM Enterprise Framework Management
ETOM Enterprise Framework Management
Infosys
 
ETRM Reporting and Market Risk
ETRM Reporting and Market RiskETRM Reporting and Market Risk
ETRM Reporting and Market Risk
Wongyu Choe
 
SAP MM Presentation
SAP MM PresentationSAP MM Presentation
SAP MM Presentation
Ramesh Kamishetty
 
The procure to pay process
The procure to pay process The procure to pay process
The procure to pay process
Jaures Magloire N. Ambe
 
CPQ Solution Study
CPQ Solution StudyCPQ Solution Study
CPQ Solution Study
Demand Metric
 

What's hot (20)

Supplier Charge back and Reducing CoPQ
Supplier Charge back and Reducing CoPQSupplier Charge back and Reducing CoPQ
Supplier Charge back and Reducing CoPQ
 
10 Laws of Customer Success
10 Laws of Customer Success10 Laws of Customer Success
10 Laws of Customer Success
 
Standardize the Service Desk
Standardize the Service DeskStandardize the Service Desk
Standardize the Service Desk
 
SAP MM_IM Inventory Management
SAP MM_IM Inventory  Management SAP MM_IM Inventory  Management
SAP MM_IM Inventory Management
 
Enterprise Service Management & IT Operations Management Coming Together
Enterprise Service Management & IT Operations Management Coming TogetherEnterprise Service Management & IT Operations Management Coming Together
Enterprise Service Management & IT Operations Management Coming Together
 
AGS Support Live: SAP Business One Procure to Pay Refresher Training
AGS Support Live: SAP Business One Procure to Pay Refresher TrainingAGS Support Live: SAP Business One Procure to Pay Refresher Training
AGS Support Live: SAP Business One Procure to Pay Refresher Training
 
Sap wm pdf
Sap wm pdfSap wm pdf
Sap wm pdf
 
Itil v3-foundation-certification-exam2
Itil v3-foundation-certification-exam2Itil v3-foundation-certification-exam2
Itil v3-foundation-certification-exam2
 
DIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑA
DIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑADIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑA
DIRECCIONES DE EMAIL DE LOS 350 DIPUTADOS DEL CONGRESO DE ESPAÑA
 
Demand Generation Maturity Model
Demand Generation Maturity ModelDemand Generation Maturity Model
Demand Generation Maturity Model
 
OSS Service Assurance -Concept Presentation by Biju M Rr
OSS Service Assurance  -Concept Presentation by Biju M RrOSS Service Assurance  -Concept Presentation by Biju M Rr
OSS Service Assurance -Concept Presentation by Biju M Rr
 
INVENTORY OPTIMIZATION
INVENTORY OPTIMIZATIONINVENTORY OPTIMIZATION
INVENTORY OPTIMIZATION
 
Salesforce Cloud Infrastructure and Challenges - A Brief Overview
Salesforce Cloud Infrastructure and Challenges - A Brief OverviewSalesforce Cloud Infrastructure and Challenges - A Brief Overview
Salesforce Cloud Infrastructure and Challenges - A Brief Overview
 
Make the Move to Lightning in 60 Days
Make the Move to Lightning in 60 DaysMake the Move to Lightning in 60 Days
Make the Move to Lightning in 60 Days
 
CRM@Oracle - Customer 360
CRM@Oracle - Customer 360CRM@Oracle - Customer 360
CRM@Oracle - Customer 360
 
ETOM Enterprise Framework Management
ETOM Enterprise Framework ManagementETOM Enterprise Framework Management
ETOM Enterprise Framework Management
 
ETRM Reporting and Market Risk
ETRM Reporting and Market RiskETRM Reporting and Market Risk
ETRM Reporting and Market Risk
 
SAP MM Presentation
SAP MM PresentationSAP MM Presentation
SAP MM Presentation
 
The procure to pay process
The procure to pay process The procure to pay process
The procure to pay process
 
CPQ Solution Study
CPQ Solution StudyCPQ Solution Study
CPQ Solution Study
 

Viewers also liked

Does audit make us more secure
Does audit make us more secureDoes audit make us more secure
Does audit make us more secure
EnterpriseGRC Solutions, Inc.
 
CISSP Study Exercises, Just some good will to help my peers with their studies
CISSP Study Exercises, Just some good will to help my peers with their studiesCISSP Study Exercises, Just some good will to help my peers with their studies
CISSP Study Exercises, Just some good will to help my peers with their studies
EnterpriseGRC Solutions, Inc.
 
ISACA SV 2013 Winter Conference Brochure
ISACA SV 2013 Winter Conference BrochureISACA SV 2013 Winter Conference Brochure
ISACA SV 2013 Winter Conference Brochure
EnterpriseGRC Solutions, Inc.
 
The Perils of Mount Must Read
The Perils of Mount Must ReadThe Perils of Mount Must Read
The Perils of Mount Must Read
EnterpriseGRC Solutions, Inc.
 
Enterprise governance risk_compliance_fcm slides
Enterprise governance risk_compliance_fcm slidesEnterprise governance risk_compliance_fcm slides
Enterprise governance risk_compliance_fcm slides
EnterpriseGRC Solutions, Inc.
 
Cryptographic lifecycle security training
Cryptographic lifecycle security trainingCryptographic lifecycle security training
Cryptographic lifecycle security training
EnterpriseGRC Solutions, Inc.
 
The value of our data
The value of our dataThe value of our data
The value of our data
EnterpriseGRC Solutions, Inc.
 
Resume - Desktop Support Engineer
Resume - Desktop Support EngineerResume - Desktop Support Engineer
Resume - Desktop Support Engineer
Nauman Ahmed
 
Walk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 rule
Walk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 ruleWalk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 rule
Walk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 rule
EnterpriseGRC Solutions, Inc.
 
Networking and communications security – network architecture design
Networking and communications security – network architecture designNetworking and communications security – network architecture design
Networking and communications security – network architecture design
EnterpriseGRC Solutions, Inc.
 
Virtualization And Cloud Impact Overview Auditor Spin Enterprise Gr Cv4
Virtualization And Cloud Impact Overview Auditor Spin   Enterprise Gr Cv4Virtualization And Cloud Impact Overview Auditor Spin   Enterprise Gr Cv4
Virtualization And Cloud Impact Overview Auditor Spin Enterprise Gr Cv4
EnterpriseGRC Solutions, Inc.
 

Viewers also liked (11)

Does audit make us more secure
Does audit make us more secureDoes audit make us more secure
Does audit make us more secure
 
CISSP Study Exercises, Just some good will to help my peers with their studies
CISSP Study Exercises, Just some good will to help my peers with their studiesCISSP Study Exercises, Just some good will to help my peers with their studies
CISSP Study Exercises, Just some good will to help my peers with their studies
 
ISACA SV 2013 Winter Conference Brochure
ISACA SV 2013 Winter Conference BrochureISACA SV 2013 Winter Conference Brochure
ISACA SV 2013 Winter Conference Brochure
 
The Perils of Mount Must Read
The Perils of Mount Must ReadThe Perils of Mount Must Read
The Perils of Mount Must Read
 
Enterprise governance risk_compliance_fcm slides
Enterprise governance risk_compliance_fcm slidesEnterprise governance risk_compliance_fcm slides
Enterprise governance risk_compliance_fcm slides
 
Cryptographic lifecycle security training
Cryptographic lifecycle security trainingCryptographic lifecycle security training
Cryptographic lifecycle security training
 
The value of our data
The value of our dataThe value of our data
The value of our data
 
Resume - Desktop Support Engineer
Resume - Desktop Support EngineerResume - Desktop Support Engineer
Resume - Desktop Support Engineer
 
Walk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 rule
Walk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 ruleWalk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 rule
Walk This Way: CIS CSC and NIST CSF is the 80 in the 80/20 rule
 
Networking and communications security – network architecture design
Networking and communications security – network architecture designNetworking and communications security – network architecture design
Networking and communications security – network architecture design
 
Virtualization And Cloud Impact Overview Auditor Spin Enterprise Gr Cv4
Virtualization And Cloud Impact Overview Auditor Spin   Enterprise Gr Cv4Virtualization And Cloud Impact Overview Auditor Spin   Enterprise Gr Cv4
Virtualization And Cloud Impact Overview Auditor Spin Enterprise Gr Cv4
 

Similar to Procedures and Controls Documentation Guidelines

Hfm course content
Hfm course contentHfm course content
Hfm course content
Amit Sharma
 
Hfm course content
Hfm course contentHfm course content
Hfm course content
Amit Sharma
 
HFM_Course_Content
HFM_Course_ContentHFM_Course_Content
HFM_Course_Content
kapildevang
 
Efficient Document Control is Essential to Positive Audit Outcomes
Efficient Document Control is Essential to Positive Audit Outcomes Efficient Document Control is Essential to Positive Audit Outcomes
Efficient Document Control is Essential to Positive Audit Outcomes
Veeva Systems
 
Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?
Juan Carlos Gonzalez
 
Webinar Bowles
Webinar BowlesWebinar Bowles
Webinar Bowles
rsuthar
 
IBM - Understanding the value of ECM
IBM - Understanding the value of ECMIBM - Understanding the value of ECM
IBM - Understanding the value of ECM
rashmin_cby
 
Information management architecture concept model
Information management architecture concept modelInformation management architecture concept model
Information management architecture concept model
Allen Woods
 
Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15
Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15
Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15
Paris Salesforce Developer Group
 
Compliance In A Box Documentum Deployment Solution
Compliance In A Box Documentum Deployment SolutionCompliance In A Box Documentum Deployment Solution
Compliance In A Box Documentum Deployment Solution
airsch
 
Sox Compliance Solution
Sox Compliance SolutionSox Compliance Solution
Sox Compliance Solution
guest586cf0
 
Sox Software Solution
Sox Software Solution Sox Software Solution
Sox Software Solution
Gerald Walker
 
ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...
ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...
ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...
ARC Advisory Group
 
Maximising Data Governance in the Cloud
Maximising Data Governance in the CloudMaximising Data Governance in the Cloud
Maximising Data Governance in the Cloud
Amazon Web Services
 
Bonitasoft Corporate and Product Overview
Bonitasoft Corporate and Product OverviewBonitasoft Corporate and Product Overview
Bonitasoft Corporate and Product Overview
Sergio-Feliciano Mendoza-Barrera
 
05 Service Oriented Architecture Series - Preparing for SOA
05 Service Oriented Architecture Series - Preparing for SOA05 Service Oriented Architecture Series - Preparing for SOA
05 Service Oriented Architecture Series - Preparing for SOA
Pouria Ghatrenabi
 
IT Governance, Risk & Compliance (GRC) by Berk Algan
IT Governance, Risk & Compliance (GRC) by Berk AlganIT Governance, Risk & Compliance (GRC) by Berk Algan
IT Governance, Risk & Compliance (GRC) by Berk Algan
Berk Algan
 
Enabling The Service-Oriented Enterprise
Enabling The Service-Oriented EnterpriseEnabling The Service-Oriented Enterprise
Enabling The Service-Oriented Enterprise
Nathaniel Palmer
 
The Art of Process Modeling: Theory and Practice
The Art of Process Modeling: Theory and PracticeThe Art of Process Modeling: Theory and Practice
The Art of Process Modeling: Theory and Practice
Sandy Kemsley
 
Contract Lifecycle Management
Contract Lifecycle Management Contract Lifecycle Management
Contract Lifecycle Management
InnocenzoLippa
 

Similar to Procedures and Controls Documentation Guidelines (20)

Hfm course content
Hfm course contentHfm course content
Hfm course content
 
Hfm course content
Hfm course contentHfm course content
Hfm course content
 
HFM_Course_Content
HFM_Course_ContentHFM_Course_Content
HFM_Course_Content
 
Efficient Document Control is Essential to Positive Audit Outcomes
Efficient Document Control is Essential to Positive Audit Outcomes Efficient Document Control is Essential to Positive Audit Outcomes
Efficient Document Control is Essential to Positive Audit Outcomes
 
Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?
 
Webinar Bowles
Webinar BowlesWebinar Bowles
Webinar Bowles
 
IBM - Understanding the value of ECM
IBM - Understanding the value of ECMIBM - Understanding the value of ECM
IBM - Understanding the value of ECM
 
Information management architecture concept model
Information management architecture concept modelInformation management architecture concept model
Information management architecture concept model
 
Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15
Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15
Introducing salesforce shield - Paris Salesforce Developer Group - Oct 15
 
Compliance In A Box Documentum Deployment Solution
Compliance In A Box Documentum Deployment SolutionCompliance In A Box Documentum Deployment Solution
Compliance In A Box Documentum Deployment Solution
 
Sox Compliance Solution
Sox Compliance SolutionSox Compliance Solution
Sox Compliance Solution
 
Sox Software Solution
Sox Software Solution Sox Software Solution
Sox Software Solution
 
ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...
ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...
ARC's Greg Gorbach's Global Manufacturing Presentation at ARC's 2008 Industry...
 
Maximising Data Governance in the Cloud
Maximising Data Governance in the CloudMaximising Data Governance in the Cloud
Maximising Data Governance in the Cloud
 
Bonitasoft Corporate and Product Overview
Bonitasoft Corporate and Product OverviewBonitasoft Corporate and Product Overview
Bonitasoft Corporate and Product Overview
 
05 Service Oriented Architecture Series - Preparing for SOA
05 Service Oriented Architecture Series - Preparing for SOA05 Service Oriented Architecture Series - Preparing for SOA
05 Service Oriented Architecture Series - Preparing for SOA
 
IT Governance, Risk & Compliance (GRC) by Berk Algan
IT Governance, Risk & Compliance (GRC) by Berk AlganIT Governance, Risk & Compliance (GRC) by Berk Algan
IT Governance, Risk & Compliance (GRC) by Berk Algan
 
Enabling The Service-Oriented Enterprise
Enabling The Service-Oriented EnterpriseEnabling The Service-Oriented Enterprise
Enabling The Service-Oriented Enterprise
 
The Art of Process Modeling: Theory and Practice
The Art of Process Modeling: Theory and PracticeThe Art of Process Modeling: Theory and Practice
The Art of Process Modeling: Theory and Practice
 
Contract Lifecycle Management
Contract Lifecycle Management Contract Lifecycle Management
Contract Lifecycle Management
 

More from EnterpriseGRC Solutions, Inc.

CobiT Foundation Free Training
CobiT Foundation Free TrainingCobiT Foundation Free Training
CobiT Foundation Free Training
EnterpriseGRC Solutions, Inc.
 
2012 Summer Conference Brochure
2012 Summer Conference Brochure2012 Summer Conference Brochure
2012 Summer Conference Brochure
EnterpriseGRC Solutions, Inc.
 
2011 Summer Conference Brochure
2011 Summer Conference Brochure2011 Summer Conference Brochure
2011 Summer Conference Brochure
EnterpriseGRC Solutions, Inc.
 
Erm talking points
Erm talking pointsErm talking points
Erm talking points
EnterpriseGRC Solutions, Inc.
 
Security assessment isaca sv presentation jan 2016
Security assessment isaca sv presentation jan 2016Security assessment isaca sv presentation jan 2016
Security assessment isaca sv presentation jan 2016
EnterpriseGRC Solutions, Inc.
 
Security assessment with a hint of CISSP Prep
Security assessment with a hint of CISSP PrepSecurity assessment with a hint of CISSP Prep
Security assessment with a hint of CISSP Prep
EnterpriseGRC Solutions, Inc.
 
Virtualization and cloud impact overview auditor spin enterprise gr-cv3
Virtualization and cloud impact overview auditor spin   enterprise gr-cv3Virtualization and cloud impact overview auditor spin   enterprise gr-cv3
Virtualization and cloud impact overview auditor spin enterprise gr-cv3
EnterpriseGRC Solutions, Inc.
 
Green Tech
Green TechGreen Tech

More from EnterpriseGRC Solutions, Inc. (8)

CobiT Foundation Free Training
CobiT Foundation Free TrainingCobiT Foundation Free Training
CobiT Foundation Free Training
 
2012 Summer Conference Brochure
2012 Summer Conference Brochure2012 Summer Conference Brochure
2012 Summer Conference Brochure
 
2011 Summer Conference Brochure
2011 Summer Conference Brochure2011 Summer Conference Brochure
2011 Summer Conference Brochure
 
Erm talking points
Erm talking pointsErm talking points
Erm talking points
 
Security assessment isaca sv presentation jan 2016
Security assessment isaca sv presentation jan 2016Security assessment isaca sv presentation jan 2016
Security assessment isaca sv presentation jan 2016
 
Security assessment with a hint of CISSP Prep
Security assessment with a hint of CISSP PrepSecurity assessment with a hint of CISSP Prep
Security assessment with a hint of CISSP Prep
 
Virtualization and cloud impact overview auditor spin enterprise gr-cv3
Virtualization and cloud impact overview auditor spin   enterprise gr-cv3Virtualization and cloud impact overview auditor spin   enterprise gr-cv3
Virtualization and cloud impact overview auditor spin enterprise gr-cv3
 
Green Tech
Green TechGreen Tech
Green Tech
 

Procedures and Controls Documentation Guidelines

  • 1. ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 1 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]
  • 2. 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  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 3. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 4. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 5. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 6. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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 enterprise­level 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 non­production 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.
  • 7. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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 time­consuming  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.
  • 8. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Any new folders must be requested via email to the process librarian, currently [Name of Process Librarian], at  Process@COMPANY.com.  The librarian insures name and contents integrity within Facilitated Compliance  Management™ process tracking.  ...PALFacilitated Compliance ManagementFacilitated 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.
  • 9. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 8 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Audience and Audit Considerations  This process profile serves as reference for COMPANY.  Groups may be referenced by functional email  notification names such as Process@company.com.  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, work­specific 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 Process@company.com.  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,
  • 10. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 9 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  should be appropriately defined.  This is a co­dependency 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.  End­user 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.
  • 11. 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  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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 process@company.com. 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.
  • 12. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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 ...PALTemplates.  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
  • 13. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 14. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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?
  • 15. 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  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Where Do I Find the Process Profile Template?  ...PALTemplatesProcess Profile Template.dot  Figure 3. What are the steps and controls in writing a process profile?
  • 16. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 17. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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?  ...PALTEMPLATESPolicy 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
  • 18. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com ·  Plan and Deliver Personnel Training ·  Implement Cross­Training or Staff Back­up ·  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?
  • 19. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Where Do I Find The Template?  ...PALTemplatesProgram Profile Template.dot  Templates that describe positions or assist in the design of a program organizational chart are located in:  ...PALIT Process Asset LibraryHuman ResourcesTemplateJob Description Template.dot  ...PALIT Process Asset LibraryHuman ResourcesTemplateEmployee Warning Notice.dot  ...PALIT Process Asset LibraryHuman ResourcesTemplateJob 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 event­tracking systems and are not centrally located, but are accessible and known  to all persons within the user department.
  • 20. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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:  ...PALTemplatesWork 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
  • 21. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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 ·  Fail­over ·  Maintenance ·  Troubleshooting and Error Messages ·  Glossary ·  List of files ·  Financial Processes ·  Test procedure
  • 22. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 8 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Should I Write A RunBook?  Consider whether the following statements are true.  Figure 7. Should I write a RunBook?
  • 23. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 9 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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.
  • 24. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 10 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 25. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 11 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Figure 9. Example Interface for gathering RunBook elements by Service Title
  • 26. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 12 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Where Do I Find The Template?  ...palFacilitated Compliance ManagementShortcut to RunBook in Facilitated Compliance  Management2000FCM.MAF  ...palTemplatesRunBook 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?  ...PALIT Process Asset Library ·  Static Process versus Process Output (Evidence of Using Process)  ...PALIT 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
  • 27. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 13 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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?  ...PALIT 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?  ...PALIT WORK PRODUCT LIBRARY
  • 28. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 14 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Figure 11.  What are the work product folders?  Current Inventory of Folder and Contents is maintained by Process Engineering, in ...PALIT Work Product  LibraryProcess EngineeringPAL Folders.xls
  • 29. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 15 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 30. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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 post­implementation 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.
  • 31. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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 pre­established plan. An audit trail  of pre­ and post­conversion 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 year­end production cycles.  Software Release (7.9)  Ensure that the release of software is governed by formal procedures ensuring sign­off, packaging, regression testing, distribution,  handover, status tracking, backout procedures and user notification.  System Distribution (7.10)
  • 32. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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.  Post­implementation Review (7.12)  Establish procedures in line with the enterprise development and change standards that require a post­implementation 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 cost­effective 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., high­level business process flow schema). · Quantify by class, a hierarchical data flow/control flow decomposition. · Include control transformations. · Allow for mini­specifications. · Maintain data dictionaries. · Consider all external events­inputs 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
  • 33. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com · 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 Environment­lDE),  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.
  • 34. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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®
  • 35. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Goals and Metrics as described in CobiT®  4.0, Copyright of ISACA®
  • 37. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 2 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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.
  • 38. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 3 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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
  • 39. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 4 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  process, based on individual decisions. The quality of systems entering production is inconsistent, with new  systems often generating a significant level of post­implementation 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 post­implementation problems. Automation of the  process is ad hoc and project­dependent. Management may be satisfied with the current level of efficiency despite  the lack of post­implementation 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. Well­developed 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 post­implementation problems are normally limited to  minor corrections. Post­implementation 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?
  • 40. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 5 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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  ...PALIT Process Asset LibraryQuality AssuranceTemplate  Security Program Test templates are maintained in Security Management directory  ...PALIT Process Asset LibrarySecurity ManagementProgram 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?
  • 41. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 6 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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?  ...palFacilitated Compliance ManagementShortcut to Controlled Servers in Facilitated Compliance  Management
  • 42. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 7 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  Figure 19.  Controlled Server Form
  • 43. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 8 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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.
  • 44. Procedure Guidelines and Controls Documentation  Robin Basham, M.IT, M.Ed., CISA  ©Copyright 2006, Phoenix Business and Systems Process, Inc. Needham, MA, USA,  Page 9 of 80  More from Phoenix Business and Systems Process, http://www.pbandsp.com  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