The control environment is an important component of an entity’s control structure or system that directly impacts IT governance. Literally, an entity’s control environment sets the “tone at the top” and can influence the effectiveness of specific IT service delivery and support control techniques. Delineated at a detail-level, factors that impact the control environment include: integrity, ethics, philosophy, operating style, the organizational structures, methods of assigning authority and responsibility (with appropriate accountability), commitment to competence, human resources policies and practices, control methods for monitoring and following up on performance, the effectiveness of audits, as well as influences external to the entity.
An IT maintenance request requires analysis of all incidents and problems generated in the entity’s production environment. However, assigned IT service support personnel should make problem evaluation their final step prior to correction. Sequentially, within the evaluation process, an entity’s major problem management tasks should include: resolving problem causes, investigating and diagnosing the root cause of the problem, identifying and recording known circumstances, assessing known circumstances, recording the known circumstances’ resolution and requesting appropriate changes.
IT service support management has a proactive role in identifying application or infrastructure weaknesses and ‘areas of concern’ within the entity’s deployed IT architecture. Once adverse trends are recognized, service problems should be highlighted and corrective action initiated. For instance, a known circumstance can be forwarded to service support change management personnel or used for employee education and training.
An IT service problem can be viewed as a demarcated and identified condition extracted from a single incident or multiple incidents exhibiting common symptoms. Initially, the IT service problem is an unknown circumstance awaiting identification and attribution. Through successful problem root cause analysis, the unknown circumstance converts to a known circumstance representing an identified condition where a CI is confirmed as the resource defect. Therefore, a primary problem management process objective should be ensuring IT services stability by identifying and removing known circumstances negatively affecting deployed IT. When cascaded, the primary goals of the Problem Management process are to minimize the adverse impact of known circumstances affecting IT service delivery and to prevent recurring incidents related to known circumstances that can affect IT service delivery. Furthermore, the reactive aspect of these goals is to quickly solve problems in response to one or more incidents; whereas, the proactive aspect of these goals is to reduce the overall number of incidents.
Cascading from the primary release management objective, the primary release management goal should be to ensure approved and accredited components are installed malfunction-resistant and on schedule. Consequently, the high level activities associated with this process should encompass: release planning, CI distribution and implementation into production, as well as definitive software library (DSL) and definitive hardware store (DHS) management.
Commonly, change tracking and change oversight practices are necessary but not sufficient to achieve acceptable CI performance improvements. Specifically, there are a variety of potential IT service threats that can convert to intentional or unintentional incidents requiring adequate IT service support. If restoring service normalcy as swiftly as possible and minimizing adverse impacts on entity operations are the primary incident management process goals, then IT support personnel achievement of expected performance levels ensures that the highest possible service quality and availability levels are maintained.
Once change tests prove satisfactory functionality, most IT CIs should be moved to a secure staging area. Subsequently, a release request should be submitted to the appropriate individual for production implementation. Upon notification of a successfully released change, documentation updates should be delivered to the individual directly responsible for the CMDB. Moreover, a change review should be performed to assess change process performance and development adequacy.
Within the change management process, release management is the practice of software development, installation as well as support for software control and distribution. The primary release management objective should be to ensure that only authorized and correct versions of software are made available for operational production usage.
Even a small change in a CI could cause a mission-critical application to fail or disrupt a service. To reduce the likelihood of undesirable consequences, thorough change planning is required for adequate change construction including: back-out planning, change testing and documentation updating. As a particular, back-out planning is necessary should the change result in an unacceptable configuration state. Additionally; since most information systems are frequently too large, integrated and complicated for service design failure or success to be predicted without testing, experimentation should be built into the change process. Lastly, CI documentation affected by the change should be correlated for updating to ensure appropriate resource utilization and maintenance.
Change management is the practice of ensuring all CI alterations are carried out in a planned and authorized manner. Change can occur for various reasons including response to business process needs, the availability and introduction of new technologies, as well as normal business growth. Changes can be permanent or temporary. However, change management procedures should reduce and provide adequate responses to anticipated or unanticipated incidents as well as problems.
Receiving the request for change (RFC), logging the RFC, assessing the incident or problem, obtaining authorization to perform the change, and planning the change are procedures that should precede change construction. Minimally, the RFC should provide the business or technology reason behind each change; identify the specific CIs and IT services affected by the change; cost estimates; risk assessment; resource requirements; and support process approvals. Logging the change permits tracking and records the RFC has passed initial documentation requirements. Assessing the incident or problem provides analysis and evaluation enabling change prioritization and categorization. To construct the change, IT service support should obtain proper authorizations for the change from the appropriate business and technical experts responsible for change deployment. Furthermore, change planning provides the means to ensure successful change development.
Enabling accommodation of essential configuration management requirements is the implementation and control of a database (commonly referred to as a Configuration Management Database (CMDB)) containing details regarding infrastructure elements that are utilized in IT services provisioning and management. To ensure successful configuration management, relevant inventory management ‘best practices’ adoption is required. However, when properly deployed, the CMDB is more than an ‘asset register’ since the database should contain information that accurately portrays the maintenance, movement and issues experienced with CIs enabling superior IT service practices.
Active IT networks can be defined as the functions performed by CIs and the interfaces, structure, as well as protocols utilized to enable service execution. Therefore, a fully configured IT network architecture creates a single uniform communication mechanism enabling utilization by resources distributed throughout the IT infrastructure. Consequently, networking architectures have a pivotal enabling role when in-depth information assets protection (IAP) is the operational objective.
Configuration management is considered by many knowledge leaders as a key process for enabling IT services support. Under typical circumstances, configuration management’s key process status is attributable to an accepted belief that the initiation point for adequately managing IT services depends on clearly knowing what items constitute the entity’s IT architecture.
Most entities should have an information assets inventory of configuration items (CIs) utilized in providing IT services. However, maintaining a current IT inventory listing can be a managerial challenge, if not addressed through a process with information asset owner participation. Considering entity information assets are continuously updated, it is critical that the IT department regulate and provide change documentation to support future maintenance situations. Therefore, configuration management requires appropriate controls.
Jointly, physical and logical security can significantly reduce the risk of irregular and illegal acts. Within this context, superior IT physical security is a major larceny deterrent for certain hardware. For example, bolting a personal computer to a fortified mount minimizes the threat of thief. Whereas, deploying general logical security practices usually requires adequate administration to reduce the risk of blackmail based on malware threats. Specifically; anti-virus software, firewalls as well as intrusion detection systems and/or intrusion prevention systems should be installed and monitored to assist in minimizing the risk of compromising the entity’s IT architecture.
Given the greater potential for an IT software related irregular or illegal act, an IT auditor should pursue understanding the backdoors and trapdoors in the entity’s computer processing environment and evaluate whether adequate preventive and detective controls are deployed. Furthermore, when performing irregular or illegal act agreed-upon procedures assessments, an IT auditor should determine if management designed adequate encryption requirements for sensitive data.
“View Part I of the Irregularities and Illegal Acts Agreed-Upon Procedures Assessments series here“