Procedure Guidelines and Controls Documentation
December 11, 2005 ©2005, Robin Basham, M.Ed., M.IT, CISA, ITSM

Want to implement your own Process Program? Contact SOAProjects. We make Process Easier!

SOAProjects is proud to be listed with and to support Jim Kaplan's AuditNet.org

Portions of this page are published in the ISACA Control Journal.  To view this paper from the ISACA web site, click here.  Copyright © 2006 ISACA. All rights reserved. www.isaca.org.

TEMPLATE [Company Name]

Sample Document for use as model for corporate process guidelines and procedures Content is protected by Copyright, ALL RIGHTS RESERVED

Version Control

[This is a prototype for the benefit of persons seeking a model for an overall compliance program.]

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.

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.

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.  \\...\PAL\Facilitated Compliance Management\Facilitated Compliance Management2000FCM.mdb

Security or Resource Administration

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

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

Business Unit and Department Data Owners

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

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

Access Control

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

Default access controls include:

• Process Librarian has administrative privileges to the PAL and provides Security Administration with the Functional Business Owner for each directory in the PAL.
• System Administrator has administrative privileges to the PAL and may grant user access according to Manager Approval.
• Functional Managers, such as Support, Change Management and Process Engineering, have read/write/update/delete privileges to their file share on the PAL. Policy dictates they should not create or delete folders without notice and approval from the Process Librarian.
• Employees (non managers) have read only privileges unless granted write privilege by the Functional Manager.  Employees do not have delete privilege.

Audience and Audit Considerations

This process profile serves as reference for  COMPANY.  Groups may be referenced by functional email notification names such as 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, 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 sample list.

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.

1. Is this a Process, Work Procedures, a Policy, a Program Definition or a Form?   
2. Management or Department Function:
3. Title:               
4. Owner:
5. Purpose:
6. Affirmation Team: 
7. Associated Key Control:  

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

How Do I Validate My Document?

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

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 detailHigh level set of steps that collectively accomplish a business function:Typically includes sub or component level processesOften 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?

\\...\PAL\Templates\Process Profile Template.dot

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

Document Type - Policy Profile

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

Elements:

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

Should I Write A Policy Profile?

Consider whether the following statements are true.

Figure 4.  Should I write a policy profile?

Where Do I Find the Template?

\\...\PAL\TEMPLATES\Policy Profile.dot

Document Type - Program Profile

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

Attributes of a program include:

• Manages Control Systems and Events
• Owns Initiatives and Business and IT Systems
• Responsible For Supporting Functions
• Is Measured
• Program profiles support the ability to perform:
• Personnel Recruitment and Promotion
• Benchmark Personnel Qualifications
• Designate Roles and Responsibilities
• Plan and Deliver Personnel Training
• Implement 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.

Figure 5.  Should I write a program profile?

Where Do I Find The Template?

\\...\PAL\Templates\Program Profile Template.dot

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

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

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

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

Document Type - Work Instruction or SOP

Work Instructions, also known as Standard Operating Procedures, (SOP) represent:

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

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

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

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

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

Should I Write A Work Instruction - SOP?

Consider whether the following statements are true.

Figure 6.  Should I write a Work Instruction - SOP

Where Do I Find The Template?

The template to write a simple set of work instructions is located in:

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

Document Type - RunBook

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

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

On a per system instance, a RunBook can document a small set of operational procedures and reference various guidelines.  On a larger scale, a service oriented RunBook details the combination of systems and their dependencies in keeping a service available. This is a valid form of meeting both BCP and various other levels of compliance requirements.  Determining this requirement can be as follows:

Why Do RunBooks Focus On Service?

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

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

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

Should I Write A RunBook?

Consider whether the following statements are true.

Figure 7.  Should I write a RunBook?

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

Consider the following sources.

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

When Is A RunBook Complete?

Consider whether the following statements are true.

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

Example Interface for gathering RunBook elements by Service Title

Where Do I Find The Template?

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

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

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

RunBook Document Elements

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

Where Does My Document Belong?

1. \\...\PAL\IT Process Asset Library\
2. Static Process versus Process Output (Evidence of Using Process)
3. \\...\PAL\IT Work Product Library\
4. Other Work Products and Controlled Documentation:
5. Version Control versus VSS (Microsoft Visual SourceSafe)
6. Test Scripts, Utilities and Event Tracking Systems
7. Assets, Inventories and Configuration Baselines
8. Controls and Key Controls
9. Product, Application Development and Quality Templates
10. 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 9.  What is in the PAL?

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

PAL\ IT Work Products

When Do I Need To Create A Work Product?

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

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

Where Do We Keep Current And Archived Work Products?

\\...\PAL\IT WORK PRODUCT LIBRARY\

Figure 10. What are the work product folders?

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

Where Do I Find Reference, Benchmark and Industry Guidelines

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

Figure 11.Standards and Reference folders

Other Work Products and Controlled Documentation:

Figure 13.                  How [other] artifacts are captured in system event logs and software design templates?

Version Control versus VSS (Microsoft Visual SourceSafe)

When Do I Use VSS?

Software Development work products have particular control requirements that are satisfied through the use of VSS, (Visual SourceSafe).  Where procedures for component level code movement are highly specialized, development documentation is maintained under a more stringent and restricted environment. Development documentation is maintained in VSS.  VSS is used to ensure document or code approval, version control and ability for roll back.  Where documentation and code requires peer review and product management approval, VSS provides control over status and review notes. Additionally, where more than one person may be required to use or modify a same document, VSS provides a check in and check out process, further supporting evidence of valid authorization for release.

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

Test Scripts, Utilities and Event Tracking Systems

What Is A Test Script Or Test Templates?

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

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

Where Do I Find QA Test Templates?

Test templates are maintained in the QA Process directory

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

Security Program Test templates are maintained in Security Management directory

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

Assets, Inventories and Configuration Baselines

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

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

WhenDo I Need To Create A Controlled Server Object?

Consider whether the following statements are true.

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

 Where Are Devices Inventoried As Assets?

Controlled Server Records will reside in [Name of core product or service] but are currently staged in Facilitated Compliance Management

Where Do I Find Server Control Records?

\\...\pal\Facilitated Compliance Management\Shortcut to Controlled Servers in Facilitated Compliance Management2000FCM.MAT [links are for example and are not enabled over the internet]

Figure 16.Controlled Server Form

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

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 (see Control Self Assessment Portal)

When Do I Need To Document A Control Object?

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

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

Control Over Process Is Demonstrated When:

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

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

Where Are Controls Catalogued?

Controls are catalogued by Name, Associated Processes and Owners within Technology's [Name of core product or service] system.  The information is used for ongoing Control Self Assessment and Compliance Documentation.

Controls are catalogued in Facilitated Compliance Management and in [Name of core product or service].  Controls are also identified within every Process Flow Diagram and Program Definition.  Key Controls align to the CobiT framework and are visible on the CobiT Assessment form within Facilitated Compliance Management.

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

 

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

Figure 20.Example of a Key Controls

Figure 21.Key Controls Form

Where Do I Find The Form or Template?

http://www.COMPANY.com Technology-Controls (Login Required)

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

Product, Application Development and Quality Templates

Which Tool Stores Process and Work Instruction information?

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

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

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

Flow Diagram

SOAProjects Consultants are famous for documentation

When Do I Use A Flow Diagram?

Flow Diagrams are developed to provide a high level summary of steps in any process or procedure.  They are "High Level", not vague.  Controls are also listed in Flow Diagrams, further demonstrating constraints that either prevent error or reinforce correct movement.  Key control template objects are created by process engineering in response to the current controls in scope for audit.  These items detail all aspects that control a process. Following are my favorite choices for simple Process Objects and some suggestions for using Visio to capture and automate their properties

See or download "Sample of A Business Process" in Word 2003 (please virus scan all downloads)

Visio Shapes and Custom Properties for Evidence of Process Controls

Process Objects

		Document Title, Scope, Revision, Release Date, Editors, Affirmation Team Always Sequence 0.0
		Reference to other process documents and to full processes outside of the scope of the current document. Part of processes sequence
		Identifies process activity, noting control issues and potential gaps, owners and event sequence. Part of processes sequence
		Decision point and criteria for movement Part of processes sequence
		Grouping allows representation of simultaneous events Sequence should parent child the sub group of activities
		Loop limits usually reflect key controls
		Data Management: What data is used, how is it classified, retained, transferred, accessed
		Data Management: What data is used, how is it classified, retained, transferred, accessed
		List of external documents used to complete process, status of use in controls evidence, creation frequency, description of use Sequence is always 9.9 so that all data sources are clustered to the bottom of the process report.
		Exit and entrance criteria for movement from one activity to the next.  Where criteria for movement is monitored by a system and is critical to control activity, this should be filled in.  Where this is true, there would be an expected control.
		Trigger and Exit criteria Sequence is always 0.1 so that all triggers and exit criteria are clustered to the top of the process report.

Acronym Glossary and Definitions

Comprehensive Glossary of all Corporate Terms

SOAProjects, Inc. FCM™ Actual Glossary has over 5000 terms.

Related Documents

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

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

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

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-2000 Edition, Project Management Institute, Project Management Institute, Inc., Newtown Square, PA, USA , 2000

Six Sigma Project Management: A Pocket Guide, by Jeffrey N., PhD Lowenthal, (American Society for Quality; Spiral edition, August 1, 2001)

Risks and Associated Controls  (SAMPLE)

Process "Piece of Cake!"

                       

Now can you ask and answer the question: "What Type of Document Should I Write?"

PAL Contents - File Location, Use

Portions of this page are reprinted with permission from its author, and are also located at http://www.pbandsp.com/process/procedureguidelines.html, with parts of this publication also published in the ISACA Control Journal.  To view this paper from the ISACA web site, click here.

Copyright © 2006 ISACA. All rights reserved. www.isaca.org.