Procedures and Controls Documentation Guidelines

©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
Process Profile
Process Owners:
Process Owners’
Departments:
Process Owner At
Release:
Release Approval List:
Distribution List:
Document Authors:
Data Classification: Confidential
Effective Date:
Revision Date:
Version Control
Revision Notes Revision
Code
Revision
Author
Revision
Release
Date
Release
Approved by

Table of Contents
Purpose and Scope............................................................................................................................................. 5
Policy Statement.............................................................................................................................................. 5
Requirements .................................................................................................................................................. 5
Document Library Management Program .................................................................................................... 5
Roles and Responsibilities ............................................................................................................................... 6
Process Librarian......................................................................................................................................... 6
Security or Resource Administration ........................................................................................................... 7
Business Unit and Department Data Owners................................................................................................ 7
Access Control ................................................................................................................................................ 7
Audience and Audit Considerations................................................................................................................. 8
Writing Standards............................................................................................................................................ 8
Change Requirements...................................................................................................................................... 8
Key Controls ................................................................................................................................................... 8
Data Classification and Data Owners............................................................................................................... 8
Naming Conventions....................................................................................................................................... 9
Document Types and Their Use ........................................................................................................................ 9
What Type of Document Do I Need To Write?................................................................................................ 9
Forms and Templates .................................................................................................................................. 9
Getting Started: ......................................................................................................................................................1
New Object Support Request ..................................................................................................................................1
How Do I Validate My Document?.............................................................................................................. 2
Figure 1. Validate a Process Object ............................................................................................... 2
Document Type Process Profile..................................................................................................................... 3
Characteristics of Process ................................................................................................................................ 3
Should I Write A Process Profile? ............................................................................................................... 4
Figure 2. Should I write a process profile?...................................................................................... 4
Where Do I Find the Process Profile Template?........................................................................................... 1
Figure 3. What are the steps and controls in writing a process profile? ........................................... 1
Document Type Policy Profile....................................................................................................................... 2
Should I Write A Policy Profile? ................................................................................................................. 3
Figure 4. Should I write a policy profile? ......................................................................................... 3
Where Do I Find the Template?................................................................................................................... 3
Document Type Program Profile ................................................................................................................... 3
Should I Write A Program Profile?.............................................................................................................. 4
Figure 5. Should I write a program profile?..................................................................................... 4
Where Do I Find The Template?.................................................................................................................. 5
Document Type Work Instruction or SOP ..................................................................................................... 5
Should I Write A Work Instruction SOP?.................................................................................................. 6
Figure 6. Should I write a Work Instruction SOP........................................................................... 6
Where Do I Find The Template?.................................................................................................................. 6
Document Type RunBook............................................................................................................................. 6
Why Do RunBooks Focus On Service?........................................................................................................ 7
Should I Write A RunBook?........................................................................................................................ 8
Figure 7. Should I write a RunBook? .............................................................................................. 8
When Is A RunBook Complete?................................................................................................................ 10
What Are The Formats For RunBook?....................................................................................................... 10
Figure 8. RunBook Process.......................................................................................................... 10
Figure 9. Example Interface for gathering RunBook elements by Service Title.............................. 11
Where Do I Find The Template?................................................................................................................ 12
Document Elements ......................................................................................................................................... 12

How Do I Find Or Store My Document? ....................................................................................................... 13
PAL IT Process Asset Library .................................................................................................................. 13
Figure 10. What is in the PAL?..................................................................................................... 13
PAL IT Work Products............................................................................................................................. 13
When Do I Need To Create A Work Product?............................................................................................ 13
Where Do We Keep Current And Archived Work Products?...................................................................... 13
Figure 11. What are the work product folders? ............................................................................. 14
Where Do I Find Reference, Benchmark and Industry Guidelines.................................................................. 15
Figure 12. Standards and Reference folders ................................................................................ 15
Other Work Products and Controlled Documentation:...................................................................................... 2
Controls Evidence Specific to Software Development and Product Development Lifecycle: ............................ 2
Figure 13. Information Criteria........................................................................................................ 4
What elements are captured during the flow diagramming process? ................................................................. 5
Figure 14. Process Inputs and Outputs, RACI Chart for AI7 as found in CobiT® 4.0, Copyright of
ISACA® 6
Figure 15. Process Flow Diagram: How are software development artifacts captured in system
event logs and software design templates? ......................................................................................... 2
Controls and Application Controls................................................................................................................... 2
When do I need to document specific control processes? ............................................................................. 2
How do we manage all these requirements?................................................................................................. 2
MKS Integrity Manager for process and workflow management of enterprise software development ............... 2
How mature do we really need to be? .............................................................................................................. 3
Figure 16. Maturity Toolbox, as represented by ISACA and CMU as the common maturity model or
CMM 3
Figure 17. How are software development artifacts captured in system event logs and software
design templates?............................................................................................................................... 4
Test Scripts, Utilities and Event Tracking Systems .......................................................................................... 5
What Is A Test Script Or Test Templates? ................................................................................................... 5
Where Do I Find QA Test Templates?......................................................................................................... 5
Assets, Inventories and Configuration Baselines .............................................................................................. 5
Figure 18. Should I document a controlled server in our system inventory database?..................... 6
Where Are Devices Inventoried As Assets?................................................................................................. 6
Where Do I Find Server Control Records?................................................................................................... 6
Figure 19. Controlled Server Form................................................................................................. 7
Figure 20. Each controlled item has associated security exemptions and standard OS and
Application build.................................................................................................................................. 8
Which Tools Store Server and Application Information? ............................................................................. 8
Where Is The List Of Tools And Tool Types?.............................................................................................. 9
Controls and Key Controls .............................................................................................................................. 9
When Do I Need To Document A Control Object? ...................................................................................... 9
Where Are Controls Catalogued?............................................................................................................... 10
Figure 21. What Process Engineering, Auditors and Quality Gather Regarding Corporate Key
Controls 10
Figure 22. Key Controls Form ...................................................................................................... 11
Where Do I Find The Form or Template? .................................................................................................. 11
Product, Application Development and Quality Templates ............................................................................ 12
Which Tool Stores Process and Work Instruction information?.................................................................. 16
Figure 23. Facilitated Compliance Management™ provides summary reports for many object types
17
Figure 24. Facilitated Compliance Management™ Allows Process Librarian to capture and
catalogue all process objects ............................................................................................................ 17
Flow Diagram ............................................................................................................................................... 17

When Do I Use A Flow Diagram? ............................................................................................................. 17
Figure 25. Sample of A Business Process.................................................................................... 19
Visio Shapes and Custom Properties for Evidence of Process Controls ...................................................... 20
Figure 26. Process Objects with properties .................................................................................. 23
Acronym Glossary and Definitions................................................................................................................ 24
Comprehensive Glossary of all Corporate Terms ........................................................................................... 25
Related Documents........................................................................................................................................ 25
Extended Bibliography.................................................................................................................................... 25
Risks and Associated Controls....................................................................................................................... 32
Figure 27. What Type of Document Should I Write?..................................................................... 34
Example of PAL Contents File Location, Description of Use ...................................................................... 35

Purpose and Scope
Procedure Guidelines and Controls Documentation outlines how to create and modify procedures, work
instructions, policies, and RunBooks as they currently exist in their correct location and format and as aligned to
the requirements of document security.
Change control, information asset location, and documentation format standards are the combined responsibility
of Security Management, Quality Assurance, and Process Engineering. In the context of creation, iteration,
approval, and posting, the Process Librarian manages documentation.
Process Engineering manages quality over documentation as demonstrated by document templates.
Security Management defines policy and access rules for the recording, adherence to, and monitoring of
procedures involving data integrity, privacy, and security across any enterpriselevel configuration.
Policy Statement
All changes, additions, and deletions to the production documentation library require management approval.
Managers should notify Process Engineering of changes to production process.
Requirements
The primary security elements of any document library management process are:
· Auditable changes
· Evidence of document library and document lifecycle management that is readily available for those who
need to monitor this activity.
Documentation strategies need to:
· Reduce complexity.
· Prioritize key control processes
· Reflect COMPANY process architecture
· Represent real functions and real activities
Document Library Management Program
A formal document library management program manages the Process Asset Library and monitors compliance
with document lifecycle objectives (i.e., annual document reviews). The program must include, but is not limited
to, the following controls:
· Documented procedures for updating production documentation.
· Defined roles and responsibilities that support defined procedures for document and document library
maintenance.
· Accountability for document content integrity.
· Education, notification, and awareness process to inform all necessary stakeholders affected by document
modifications.
· Separation of production and nonproduction documentation.
· A defined data retention goal for each document or class of document. Documents are maintained for the
lifecycle of the process. If aligned to key controls and loaded in [Name of core product or service], the
document is retained as part of SAS 70 evidence.

Document lifecycle control procedures must detail the process for: (Process Profile Creation doc – sections
embedded in this doc)
· Reviewing new or changed documents.
· Approving and rejecting documents.
· Posting documentation.
· Documenting information about documentation (metadata).
· Auditing the lifecycle of documents in the library.
Roles and Responsibilities
Document and document class owners shall:
· Ensure the integrity, confidentiality, and availability of production documentation and the library
environment through the implementation of documented programs, procedures and standards.
· Approve all changes affecting their domain of control and responsibility.
· Ensure all changes have been approved and properly communicated prior to posting.
· Ensure that their employees understand and abide by this policy and its control requirements.
· Report any violation of this policy to the CTO and CSO or its designated representatives, within a timely
manner.
The Process Engineering Team will endeavor to assist COMPANY operations with many timeconsuming
functions not core to their roles. Process and technical documentation is central to the creation of user guides and
training materials and is currently aligned to the COMPANY Process Engineering group. As COMPANY may
add or extend this function, the process librarian function will continue to assist with the design and deployment
of training materials and user guides.
These duties may include:
· Assist with writing and maintaining procedures and controls. The data owner will usually write
procedures.
· Providing methods to maintain and meet record keeping obligations.
· Assisting with the design and modeling of management reports and control checklists.
· Assisting with workflow and process design.
· Acting as a liaison with business, compliance, and development to implement and/or update procedures,
controls, and system enhancements.
Process Librarian
The Process Librarian controls the process information directory structure and makes sure the integrity of the
folders is maintained. The librarian function catalogues and categorizes documentation assets and aligns
documentation standards to the needs of the business and technology functions.
Where changes are required to existing process documentation, the process librarian handles the registration and
posting of new procedures to the established process location.

Any new folders must be requested via email to the process librarian, currently [Name of Process Librarian], at
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.

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, workspecific training
materials, and production support procedures (i.e., RunBooks), are dynamic, changing to fit current business
operational practices. They must reflect the regular changes in business focus and environment. Reviews and
updates of procedures are essential if they are to be relevant. Therefore,  COMPANY provides notice to business
management of all changes and new instances of process.   Both internal and external auditors will review
procedures to identify, evaluate, and thereafter test controls over business processes. Given this knowledge, it is
the responsibility of the process owner to keep current any process documentation and to notify the process
librarian of any process change via 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,

should be appropriately defined.  This is a codependency on Security and Security Administration, where Process
assists in the implementation of classification standards, and access is further supervised and implemented
through Security programs.
Process Librarian and Data Owners are dependent upon the accurate “classification of information assets” as
defined by the Security Policy.  Enduser managers and the security administrators require classifications to
accurately determine who should be able to access what. The Process Librarian assists in the design of file share
information, whereas the Data Owner is accountable for the classification and administration of its use.  The
Process Librarian assists the business to manage data assets by location and classification.  The Process Librarian
further supports requirements to have an information inventory of internal process and work products.
Naming Conventions
Naming conventions are a part of the COMPANY overall security design and are an integral part of information
asset accounting. In accordance with an approved set of access rules stipulating users (or groups of users)
authorized to access a resource (such as a dataset or file) and at what level (such as read or update) the access
control mechanism applies these rules whenever a user attempts to access or use a protected resource. Data is
maintained by location such that access is appropriately restricted.
These general naming conventions and associated files are required in a computer environment to establish and
maintain personal accountability and segregation of duties in the access of data. The owners of the data or
application, with the help of the security officer and process librarian, establish the name of files and subfolders
for their business information.   It is important to establish naming conventions that both promote the
implementation of efficient access rules and simplify security administration. Naming conventions for system
resources are an important prerequisite for efficient administration of security controls.
Process Engineering Key Controls and Risks can be reviewed in Process Documentation Compliance Control
CobiT Function CobiT Detail Objective and Risks and Associated Controls
Document Types and Their Use
What Type of Document Do I Need To Write?
Writing a document may sound easy, but it is really very complex. Documentation strategies are designed to
reduce complexity, prioritize Key Control Processes, reflect a common Process Architecture; (ITIL and CobiT
frameworks), and above all else, represent REAL Functions and REAL activities.
Factors that influence the type of document that we write are:
· Sustainability, how often detail within the process will change and
· “High Level not Vague” Achieving the Highest Level of information possible before document details
become formless, blurry or vague
Forms and Templates
Process documentation is designed for a specific layer of abstraction.  Process engineering works with the
document author to select a template that meets the writer’s minimal requirements.
Guided writing is a process that facilitates creating consistent standard quality documentation. Writing takes many
forms, each best suited to serve a different purpose. The following sections explain the different types of
templates or writing guides, including application interface, word templates and diagrams.

Getting Started:
Prior to creating a procedure, persons are asked to review available formats for documentation. Once the type and
topic for documentation is established, Process Engineering is available to review and validate the intended
process.  Process Engineering catalogues corporation documentation and is able to prevent wasted or duplicated
documentation efforts.
How: Send notice of intention to create documentation to 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.

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

Document Type Process Profile
The purpose of a process profile is to capture and document essential elements associated with a business process.
A process is a series of actions, changes, or functions bringing about a result.
Elements included in a process profile are selected by the process team. Generally, the elements include, but are
not limited to:
· Version Control And Change History
· Purpose And Scope
· Associated Control Objectives
· Critical Success Factors
· Performance Indicators Baseline Performance
· Goals/Measures
· Service Level Considerations
· Related /Source Documents
· Forms And Templates
· Quality Records Including SQM
· Process Diagram
· Process Deviations And Current State
· Trigger And Exit Criteria
· Acronyms/Definitions
· Safety Issues
· Risk Management Plan
· Process Definition (Inputs And Outputs To Other Processes)
· Status Codes—Metadata
Characteristics of Process
· Highest level of abstraction and lowest level of detail
· High level set of steps that collectively accomplish a business function:
· Typically includes sub or component level processes
· Often used by more than one program or department

Should I Write A Process Profile?
Consider whether the following statements are true.
The process flow diagram demonstrates the steps involved in creating any process object. If this is viewed on
line, the flow includes all process properties in the flow objects. For more information, see Appendix A.
Figure 2. Should I write a process profile?

Where Do I Find the Process Profile Template?
...PALTemplatesProcess Profile Template.dot
Figure 3. What are the steps and controls in writing a process profile?

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

Should I Write A Policy Profile?
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

· Plan and Deliver Personnel Training
· Implement CrossTraining or Staff Backup
· Verify Personnel Clearance Procedures
· Design and Perform Employee Job Performance Evaluation
· Determine Job Change and Termination Requirements
Program Profile Elements:
· Purpose and Scope:
· Roles and Responsibilities:
· Program Elements:
· Tools:
· Program Controls and Measures
Should I Write A Program Profile?
Program profiles are not required, but can facilitate a great many other functions including Audit and Training or
Organization Requirements Definition. Where a program profile supports the organization to explain a department
charter, it is a simple and useful tool that may benefit employees and auditors equally.
Program Profile
Supports
implementation of
process or policy
Aligned to job
descriptions and
control functions
Serves as audit
guide for program
implementation
Organizational
control activity
Defines a company
specific activity Including purpose,
elements, tools and staff
Activity is exclusive to this group
There is a
group
chartered to
perform this
function
Required to maintain controls
Measured metrics
Complete Program
and Program Test
Definition
Figure 5. Should I write a program profile?

Where Do I Find The Template?
...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 eventtracking systems and are not centrally located, but are accessible and known
to all persons within the user department.

Should I Write A Work Instruction SOP?
Figure 6. Should I write a Work Instruction SOP
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

dependencies in keeping a service available. This is a valid form of meeting both BCP and various other levels of
compliance requirements.  Determining this requirement can be as follows:
Why Do RunBooks Focus On Service?
A RunBook is Service Oriented vs. single system oriented.  When documentation does not meet the requirements
mentioned above, it is probable that listing the device in an inventory system is sufficient and further documentation
is not required.
Where the availability of a critical or core business function depends upon the accurate working of interdependent
systems, it is advisable to have a business owner who assures the current and complete Service RunBook.   As is
true for any controlled system, the RunBook explains day to day system procedures, but additionally adds some or
all of the following elements:
· Functional Overview
· Functional Overview Diagram
· List of Interfaces
· System Overview
· System Overview Diagram (s)
· Network Management Process
· Hardware
· Hardware Management Process
· Software Development and Release
· Third Party Vendor / Software Management
· Performance Monitoring Process
· Database Administration Process
· Quality Assurance
· Vendor Information
· Back Up Processes
· Disaster Recovery Process
· Security
· Problem Management
· Configuration Overview:
· Server/ HW/OS
· Application
· Database Configuration
· Daily cycle
· Failover
· Maintenance
· Troubleshooting and Error Messages
· Glossary
· List of files
· Financial Processes
· Test procedure

Should I Write A RunBook?
Figure 7. Should I write a RunBook?

Where Do I Get The Information That Goes Into The RunBook?
Consider the following sources.
RunBooks bring visibility to an aggregation of documents and details that collectively support service availability or
product delivery.

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

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

...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

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

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

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

Other Work Products and Controlled Documentation:
Controls Evidence Specific to Software Development and Product
Development Lifecycle:
Teams preparing their annual audit work papers (controls evidence) will often ask, “What about SDLC related
artifacts like VSS/ CVS, test events and source code libraries? Software Development work products have
particular control requirements satisfied through the appropriate use of tools such as workflow and event
management, integrated development environments or IDE’s and storage libraries for the purpose of source control.
Unlike controls designed to enforce and manage the policy of production environments however, software
development must allow for both creative genius and water tight tests over what can sometimes be bleeding edge or
“non conforming” code.  The requirements aligned to creating and modifying today’s business solutions must often
support multiple libraries of code  involving issues integration with environments best described as moving targets,
highly complex data requirements and greater third party dependencies than could have ever been anticipated.
“Production Environments” are as fixed as the next patch response to newly revealed malicious code, hardware or
software exploit or even regulatory requirement.  Among the myriad of morphing parts is the Holy Grail we call
“production” and the miraculous belief that we control it.  It is no wonder that entire careers have been made in the
path of unraveling the events perceived as the negative effects of purposefully released code.
Software development is an integrated process spanning the entire IT organization.  The term lifecycle can be taken
to represent the collection of agreed steps to control development, modification and distribution of code.  While
Change and Configuration Management denote separate entities exerting policy over standards for the production
environment, the design of these standards and all efforts between these points can be characterized as the world of
software development and code.
Clearly, no two companies have exactly the same organization, product or infrastructure, but the efforts of Carnegie
Mellon University, Software Engineering Institute, the Office of Government and Commerce and British Standards
Institute and the Information Systems Audit and Control Association have produced clear and aligned frameworks
for the representation of software development best practice.   Well run, or mature development shops provide
similar process and control points and reap quality product as the benefit of their status among “mature”
organizations.
The Control Objectives for Information Technology, Edition Four, CobiT® 4.0 is our most widely adopted matrix
and measure for all integrated IT and Enterprise controls.  Aligning the concepts of CMM, ITIL, ISO/IEC 17799
and COSO, CobiT® 4.0 advances the previous project with increased attention in the areas of SDLC, Quality and
Project Risk Management.  Of particular note, is the newly numbered control process “Install and Accredit
Solutions and Changes”, AI7.
Install and Accredit Solutions and Changes is the high level functional area that captures the greatest number of
features representing the activities related to SDLC or Release Management.  AI7 states:
“New systems need to be made operational once development is complete. This requires proper testing in a
dedicated environment with relevant test data, definition of rollout and migration instructions, release
planning and actual promotion to production, and a postimplementation review. This assures that
operational systems are in line with the agreed expectations and outcomes.”
“Install and Accredit Solutions and Changes” include inputs and outputs to configuration, project, change,
maintenance and acquisition programs.  With handoffs based in triggers, performance goals, measurements and
business based criteria, documented consensus and tested results, evidence of their implementation is best suited to
automated systems.

As companies comply with regulatory and industry requirements, system based records showing evidence of these
controls gain even greater importance. The following are high level definitions of the control processes found
within Acquisition and Implementation process, Install and Accredit Solutions and Changes, or “AI7”.
Training (7.1)
Train the staff of the affected user departments and the operations group of the IT function in accordance with the defined training and
implementation plan and associated materials, as part of every information systems development, implementation or modification
project.
Test Plan (7.2)
Establish a test plan and obtain approval from relevant parties. The test plan is based on organization wide standards and defines roles,
responsibilities and success criteria. The plan considers test preparation (including site preparation), training requirements, installation or
update of a defined test environment, planning/performing/documenting/retaining test cases, error handling and correction, and formal
approval. Based on assessment of the risk of system failure and faults on implementation, the plan should include requirements for
performance, stress, usability, pilot and security testing.
Implementation Plan (7.3)
Establish an implementation plan and obtain approval from relevant parties. The plan defines release design, build of release packages,
rollout procedures/installation, incident handling, distribution controls (including tools), storage of software, and review of the release
and documentation of changes. The plan should also include fallback/back out arrangements.
Test Environment (7.4)
Establish a separate test environment for testing. This environment should reflect the future operations environment (e.g., similar
security, internal controls and workloads) to enable sound testing. Procedures should be in place to ensure that the data used in the test
environment are representative of the data (sanitized where needed) that will eventually be used in the production environment. Provide
adequate measures to prevent disclosure of sensitive test data. The documented results of testing should be retained.
System and Data Conversion (7.5)
Ensure that the organization's development methods provides for all development, implementation or modification projects, that all
necessary elements such as hardware, software, transaction data, master files, backups and archives, interfaces with other systems,
procedures, system documentation, etc., be converted from the old system to the new according to a preestablished plan. An audit trail
of pre and postconversion results should be developed and maintained. A detailed verification of the initial processing of the new
system should be performed by the system owners to confirm a successful transition.
Testing of Changes (7.6)
Ensure that changes are tested in accordance with the defined acceptance plan and based on an impact and resource assessment that
includes performance sizing in a separate test environment by an independent (from builders) test group before use in the regular
operational environment begins. Parallel or pilot testing should be considered as part of the plan. The security controls should be tested
and evaluated prior to deployment, so the effectiveness of security can be certified. Fallback/ backout plans should also be developed and
tested prior to promotion of the change to production.
Final Acceptance Test (7.7)
Ensure that procedures provide for, as part of the final acceptance or quality assurance testing of new or modified information systems, a
formal evaluation and approval of the test results by management of the affected user department(s) and the IT function. The tests should
cover all components of the information system (e.g., application software, facilities, technology and user procedures) and ensure that
the information security requirements are met by all components. The test data should be saved for audit trail purposes and for future
testing.
Promotion to Production (7.8)
Implement formal procedures to control the handover of the system from development to testing to operations in line with the
implementation plan. Management should require that system owner authorization be obtained before a new system is moved into
production and that, before the old system is discontinued, the new system has successfully operated through all daily, monthly,
quarterly and yearend production cycles.
Software Release (7.9)
Ensure that the release of software is governed by formal procedures ensuring signoff, packaging, regression testing, distribution,
handover, status tracking, backout procedures and user notification.
System Distribution (7.10)

Establish control procedures to ensure timely and correct distribution and update of approved configuration items. This involves integrity
controls; segregation of duties among those who build, test and operate; and adequate audit trails of all actions.
Recording and Tracking of Changes (7.11)
Automate the system used to monitor changes to application systems to support the recording and tracking of changes made to
applications, procedures, processes, system and service parameters, and the underlying platforms.
Postimplementation Review (7.12)
Establish procedures in line with the enterprise development and change standards that require a postimplementation review of the
operational information system to assess and report on whether the change met customer requirements and delivered the benefits
envisioned in the most costeffective manner.
(Additional information regarding CobiT® can be viewed at http://www.isaca.org)
While SDLC Process documentation is heavily impacted by supporting programs, such as Steering Committee and
overall Project / Program Management, Training and Quality Assurance, cooperation between these groups is
necessary to the production acceptance of any major release and in some conditions, even simple enhancement to
previously released code.  Artifacts of these procedures can include process profiles, detailed workflow diagrams,
committee presentations and even on line help files, but the true nature of software development controls evidence
can only be demonstrated through the appropriate use and capture of controls over the policies and procedures for
the development and release of all associated software and code.  Modern forms of evidence generally must:
· Demonstrate an existing system context in the form of functional, transaction process and infrastructure
diagrams (e.g., highlevel business process flow schema).
· Quantify by class, a hierarchical data flow/control flow decomposition.
· Include control transformations.
· Allow for minispecifications.
· Maintain data dictionaries.
· Consider all external eventsinputs from external environment.
· Track by change any and every single transformation data flow diagrams with extreme emphasis towards data
input, transformation, verification, validation and output controls.
Consider the seven Information Criteria as represented in review of IT Governance Controls by ISACA
Figure 13. Information Criteria
Regardless of domain, process outputs are reviewed in the context of their effectiveness, efficiency, confidentiality,
integrity, availability, compliance and reliability.  Given the scenario of software development programs,
information criteria might be applied to elements such as the following:
· Code Libraries
· Restore by code revision and secure retrieval process
· Meeting Minutes as visible in tracking systems
· Risk Evaluation Definition and Risk Review
· Anomaly Measures and Reporting

· Enhancement Request Tracking
· Quality and Test Tracking
· Test Plans
· Project Milestone Tracking
· Data Dictionary
· Defect, Enhancement or Error Tracking
· Production Acceptance guidelines
· Post Implementation Review
· Customer Satisfaction Ratings
· Service Level and Operating Level Requirements
Version control software, or tools that capture a roll back state, are sometimes confused with full scale software
development tracking applications.  Online Programming Facilities (integrated Development EnvironmentlDE),
however, must extend far beyond a snapshot and restoration to previous version of code.  While software projects
may have once been characterized as a routine process of delivering code to a single business unit, involving a
homogenous development teams using a single platform and familiar technology, today’s project can be
characterized quite differently.  Typical projects integrate efforts by dozens of developers in multiple countries,
involving three or more business streams, traversing varied platforms and applications, accepting some degree of
technological uncertainty and unfamiliarity, and satisfying the requirements of disparate organizations that may not
have organic opportunities to seek consensus or even share awareness of each other’s requirements.  Add to this at
least one major vendor, market projections for cost and completion and increasingly regulated and complex
electronic transaction processes. A code snapshot doesn’t suffice.
Programming tools are not enough to facilitate effective use of structured programming methods in the path of
measured service delivery.  Highly skilled program teams require systems to enable proper use of best practice,
including protection of their own use or misuse as a primary IT resource. Mature shops leverage an online
programming facility as part of an integrated development environment.  This practice alone, however, cannot
assure mature product delivery. Software departments require SDLC products, where the suite of modules includes
inputs beyond those of the programmer and to include all members in the path of a Service Application. While an
IDE provides programmers ability to code and compile programs interactively with a remote computer, it cannot
efficiently and effectively control workflow, to say nothing of risk management.
In fact, the IDE alone can facilitate our most tremendous control weakness in IT, being capacity to enter, modify,
and delete programming code, as well as compile and store programs (source and object) on a single workstation
without prior plan, authority or approval. While affording required reporting, the online facilities also can be used
by non IS staff to update and retrieve data directly from computer files. While this is a business requirement,
without proper controls, it is also an inherent control risk.
What elements are captured during the flow diagramming process?
Steve Covey’s often quoted “Begin with the end in mind” principle applies well to the question of “what do I need
to capture during the process flow diagramming process?”  Accurate, versus incomplete requirements are said to
represent the single greatest factor in software development success.  Consider that the process of gathering
requirements provides many opportunities to communicate attributes needed for successful documentation of
software and business controls.  Regardless of the applications used to document requirements, using common
terms and controls definitions, such as those found in CobiT® 4.0 will dramatically shorten time spent on software
design and control documentation.  The following image is intended as suggested content captured by control
objects in a process flow diagram.  Such objects might be found in virtually all process modeling and development
tracking systems.  The effort to apply controls language to the documentation of responsibility is a process driven
by people, and best facilitated by current and mature software development tools.

When selecting tools for the alignment of SDLC with regulatory and audit reporting requirements, consider that the
product must:
· Easily and clearly represent main components, objectives and user requirements, while identifying areas that
require controls
· Provide means for capture, evaluation and rank of the major risks to, and exposures of, the system
· Include how each control is monitored and what ensures controls are implemented such tht control owners
determine their effectiveness, for example that business users review business requirements, data owners
review data access, end users affirm adequacy of training materials and documentation, and so on
· Verify that any software development and change tracking system include:
· Work order and related task assignment history, status, duration and outcome
· Segregated tracking of system and role based access such as console logins and logouts by programmers,
ticket updates by end users, program authorization by the business.
· Ensure existence of a reasonable explanation for all program deletions
· Document and assign owners to events based in a system maintenance process:
· business authorization,
· regression testing where code or hardware integration affect end user processing, and
· record of post maintenance test results or any other audit evidence.
· Verify through test and frequent checks, the adequacy of production library security
· Integrate process controls between configuration management, problem management and change
management in the process to ensure the integrity of the production resources
The following charts and flow diagram shows IT Programs in relation to the Software development Lifecycle. The
triangle objects represent audited CobiT® controls, with focus to AI7 and including additional controls from
supporting programs.
Figure 14. Process Inputs and Outputs, RACI Chart for AI7 as found in CobiT® 4.0, Copyright of ISACA®

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

Figure 15. Process Flow Diagram: How are software development artifacts captured in system event logs and software
design templates?
Controls and Application Controls
When do I need to document specific control processes?
The output of any policy or process includes a list of quality measures. Quality is measured by a set of controls or
tests, each designed to provide feedback or align our actions to those policies and procedures.
A “control” over process is characterized by ability to:
· Communicates Repeatable Intention
· Executes As Planned (Implementation Plan)
· Measure (Risk Measurement & Impact Analysis)
· Record (Management Reporting & KPI)
· Respond (Thresholds)
· Archive (Defined Data Retention)
Controls require a visible and recognized:
· Name
· Owner
· Method –(Automation or Manual)
· Program
· Frequency
· Test
· Activity Definition
· Location
· Test Evidence
· Information Processing Objective
· Sequence ID and method of tracking
How do we manage all these requirements?
MKS Integrity Manager for process and workflow management of
enterprise software development
MKS Integrity Manager is an excellent example of Software tools providing flexible process and workflow
management, while facilitating common best practice for managing software development. This tool seamlessly
marries with MKS Source Integrity Enterprise for full enterprise software configuration management, is the
foundation for MKS Requirements for requirements management and integrates other developer productivity
tools to leverage software investments and enhance coverage of the software.

MKS Integrity Manager Image is copyright of MKS http://www.mks.com
The MKS Integrity suite enables development as it occurs in a service delivery model.  Inputs from Project
Management and Help Desk are built into the workflow with controls placed in points of emphasis to a program
designed specifically for product development and release.  An additional highlight is this products ability to
integrate with most known IDE’s and to operate in any well established technology platform as it exists today.
Even if popular voting for your personal IT motto puts “you can’t please everyone” in a tie with “did you want it
good or did you want it fast?” MKS offers a degree of supplanted process maturity representing a bump to at least
level two across most maturity measures of SDLC.  (See Maturity Model in text below).  MKS integrity manager
integrates IT processes, platforms and tools while guiding software development teams through the most common
input and outputs, rat holes and handshakes found among all IT shops today.
How mature do we really need to be?
Figure 16. Maturity Toolbox, as represented by ISACA and CMU as the common maturity model or CMM
Install and Accredit Solutions and Change, is a significantly important control for any IT organization.  Without
these controls existing to some level, it is unlikely that any form of business could thrive.  Consider, however, that
most companies could be described as having attributes resembling the descriptions for “initial” or “repeatable”
maturity.  Would this be mature enough to achieve the milestone found in the Enterprise Strategy?  That is a
decision for each company and its leaders.  Here are some of the CobiT®  maturity definitions for the Install and
Accredit Solutions and Change process area.
CobiT® 4.0 Defines Repeatable to Optimized SDLC related practice in the follo wing way:
• *(Install and Accredit Solutions and Changes)  Repeatable but Intuitive: There is some consistency amongst
the testing and accreditation approaches, but typically they are not based on any methodology. The individual
development teams normally decide the testing approach and there is usually an absence of integration testing.
There is an informal approval process.
• Defined Process: A formal methodology relating to installation, migration, conversion and acceptance is in
place. IT installation and accreditation processes are integrated into the system life cycle and automated to some
extent. Training, testing and transition to production status and accreditation are likely to vary from the defined

process, based on individual decisions. The quality of systems entering production is inconsistent, with new
systems often generating a significant level of postimplementation problems.
• Managed and Measurable: The procedures are formalized and developed to be well organized and practical
with defined test environments and accreditation procedures. In practice, all major changes to systems follow this
formalized approach. Evaluation of meeting user requirements is standardized and measurable, producing metrics
that can be effectively reviewed and analyzed by management. The quality of systems entering production is
satisfactory to management even with reasonable levels of postimplementation problems. Automation of the
process is ad hoc and projectdependent. Management may be satisfied with the current level of efficiency despite
the lack of postimplementation evaluation. The test system adequately reflects the live environment. Stress
testing for new systems and regression testing for existing systems are applied for major projects.
• Optimized: The installation and accreditation processes have been refined to a level of good practice, based on
the results of continuous improvement and refinement. IT installation and accreditation processes are fully
integrated into the system life cycle and automated when appropriate, facilitating the most efficient training,
testing and transition to production status of new systems. Welldeveloped test environments, problem registers
and fault resolution processes ensure efficient and effective transition to the production environment.
Accreditation takes place usually with no rework, and postimplementation problems are normally limited to
minor corrections. Postimplementation reviews are standardized, with lessons learnt channeled back into the
process to ensure continuous quality improvement. Stress testing for new systems and regression testing for
modified systems are consistently applied.
* (Spelling is altered for US English)
Not every organization will set SDLC targets on “optimized”, but one thing is certain. Any organization with
strategy towards level five Software Development practice needs evidence of system based controls as seen in
the MKS Integrity Manager Suite.
Figure 17. How are software development artifacts captured in system event logs and software design templates?

Test Scripts, Utilities and Event Tracking Systems
What Is A Test Script Or Test Templates?
Programs, systems and releases have associated tests and test results.  QA and Security maintain secure test plans
and test results.  Tests related to Software Quality are run from, and secured in, the [Name of Testing or Quality
Assurance Application] Application.
Security scripts and networking utilities are maintained in secure location with the highest degree in limited
access.  These items are by design, neither visible or accessible to the general user.
Where Do I Find QA Test Templates?
Test templates are maintained in the QA Process directory
...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?

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

Figure 19. Controlled Server Form

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

Where Is The List Of Tools And Tool Types?
Tools and Tool types are listed in the Tools and Tool Type table in the Facilitated Compliance
Management2000FCM database. Servers and devices are recorded in the Controlled Server Form, located in the
Facilitated Compliance Management™ database.
Controls and Key Controls
When Do I Need To Document A Control Object?
Controls practices provide reasonable assurance that business rules exist and are optimized such that negative
impact of undesirable events are captured, responded to and mitigated. IT Control is the right mixture of policies,
procedures, practices and organizational structures that assure business objectives are met, while preventing,
detecting or correcting any or all undesired events.
Control Definitions exist within each process and are an inherent feature in policy.
Control Over Process Is Demonstrated When:
· It Communicates Repeatable Intention
· Executes As Planned (Implementation Plan)
· Measures (Risk Measurement & Impact Analysis)
· Records (Management Reporting & KPI)
· Archives (Defined Data Retention)
· Control Items capture
· Control Name
· Owner
· Control Method
· Automation or Manual
· Program
· Frequency
· Test Information
· Activity Definition
· Location of Test and Test Evidence
· Information Processing Objective
· Sequence ID and Key Tracking

Procedures and Controls Documentation Guidelines

Procedures and Controls Documentation Guidelines

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

Similar to Procedures and Controls Documentation Guidelines

Similar to Procedures and Controls Documentation Guidelines (20)

More from EnterpriseGRC Solutions, Inc.

More from EnterpriseGRC Solutions, Inc. (8)

Procedures and Controls Documentation Guidelines