CHAPTER 2
IT Governance and Risk Management

This chapter discusses the following topics

• IT governance structure

• Human resources management

• IT policies, standards, processes, and procedures

• Management practices

• IT resource investment, use, and allocation practices

• IT contracting and contract management strategies and practices

• Risk management practices

• Monitoring and assurance

The topics in this chapter represent 15 percent of the CISA examination.

IT governance should be the wellspring from which all other IT activities flow.

Properly implemented, governance is a process whereby senior management exerts strategic control over business functions through policies, objectives, delegation of authority, and measurement. Governance is management’s control over all other IT processes, to ensure that IT processes continue to effectively meet the organization’s business needs.

Organizations usually establish governance through an IT steering committee that is responsible for setting long-term IT strategy, and by making changes to ensure that IT processes continue to support IT strategy and the organization’s needs. This is accomplished through the development and enforcement of IT policies, requirements, and standards.

IT governance typically focuses on several key processes such as personnel management, sourcing, change management, financial management, quality management, security management, and performance optimization. Another key component is the establishment of an effective organization structure and clear statements of roles and responsibilities. An effective governance program will use a balanced scorecard to monitor these and other key processes, and through a process of continuous improvement, IT processes will change to remain effective and to support ongoing business needs.

Practices for Executives and Board of Directors

Governance starts at the top.

Whether the organization has a board of directors, council members, commissioners, or some other top-level governing body, governance begins with top-level objectives and policies that are translated into more actions, policies, and other activities downward through each level in the organization.

This section describes governance practices recommended for IT organizations that include a strategy-developing committee, measurement via the balanced scorecard, security management, and enterprise architecture.

IT Governance

The purpose of IT governance is the alignment of the IT organization with the needs of the business. The term IT governance refers to a collection of top-down activities intended to control the IT organization from a strategic perspective. Some of the products and activities that flow out of healthy IT governance include

Policy At its minimum, IT policy should directly reflect the mission, objectives, and goals of the overall organization.

Priorities The priorities in the IT organization should flow directly from the organization’s mission, objectives, and goals. Whatever is most important to the organization as a whole should be important to IT as well.

Standards The technologies, protocols, and practices used by IT should be a reflection of the organization’s needs. On their own, standards help to drive a consistent approach to solving business challenges; the choice of standards should facilitate solutions that meet the organization’s needs in a cost-effective and secure manner.

Vendor management The suppliers that IT selects should reflect IT priorities, standards, and practices.

Program and project management IT programs and projects should be organized and performed in a consistent manner that reflects IT priorities and supports the business.

While IT governance contains the elements just described, strategic planning is also a key component of governance. Strategy is discussed in the next section.

IT Strategy Committee

In organizations where IT provides significant value, the board of directors should have an IT strategy committee. This group will advise the board of directors on strategies to enable better IT support of the organization’s overall strategy and objectives.

The IT strategy committee can meet with the organization’s top IT executives to impart the board’s wishes directly to them. This works best as a two-way conversation, where IT executives can inform the strategy committee of their status on major initiatives, as well as on challenges and risks. This ongoing dialogue can take place as often as needed, usually once or twice per year.

The Balanced Scorecard

The balanced scorecard (BSC) is a management tool that is used to measure the performance and effectiveness of an organization. The balanced scorecard is used to determine how well an organization can fulfill its mission and strategic objectives, and how well it is aligned with overall organizational objectives.

In the balanced scorecard, management defines key measurements in each of four perspectives:

Financial Key financial items measured, such as the cost of strategic initiatives, support costs of key applications, and capital investment.

Customer Key measurements include the satisfaction rate with various customer-facing aspects of the organization.

Internal processes Measurements of key activities include the number of projects and the effectiveness of key internal workings of the organization.

Innovation and learning Human-oriented measurements include turnover, illness, internal promotions, and training.

Each organization’s balanced scorecard will represent a unique set of measurements that reflects the organization’s type of business, business model, and style of management.

The Standard IT Balanced Scorecard

The balanced scorecard should be used to measure overall organizational effectiveness and progress. A similar scorecard, the standard IT balanced scorecard, can be used to specifically measure IT organization performance and results.

Like the balanced scorecard, the standard IT balanced scorecard has four perspectives:

Business contribution Key indicators here are the perception of IT department effectiveness and value as seen from other (non-IT) corporate executives.

User Key measurements include end user satisfaction rate with IT systems and the IT support organization. Satisfaction rates of external users should be included if the IT department builds or supports externally facing applications or systems.

Operational excellence Key measurements include the number of support cases, amount of unscheduled downtime, and defects reported.

Innovation This includes the rate at which the IT organization utilizes newer technologies to increase IT value, and the amount of training made available to IT staff.

NOTE The IT balanced scorecard should flow directly out of the organization’s overall balanced scorecard. This will ensure that IT will align itself with corporate objectives. While the perspectives between the overall BSC and the IT-BSC vary, the approach for each is similar, and the results for the IT-BSC can “roll up” to the organization’s overall BSC.

Information Security Governance

Security governance is the collection of management activities that establishes key roles and responsibilities, identifies and treats risks to key assets, and measures key security processes. Depending upon the structure of the organization and its business purpose, information security governance may be included in IT governance, or security governance may stand on its own.

The main roles and responsibilities for security should be

Board of directors The board is responsible for establishing the tone for risk appetite and risk management in the organization. To the extent that the board of directors establishes business and IT security, so too should the board consider risk and security in that strategy.

Steering committee A security steering committee should establish the operational strategy for security and risk management in the organization. This includes setting strategic and tactical roles and responsibilities in more detail than done by the board of directors. The security strategy should be in harmony with the strategy for IT and the business overall. The steering committee should also ratify security policy and other strategic policies and processes developed by the CISO.

Chief information security officer (CISO) The CISO should be responsible for conducting risk assessments; developing security policy; developing processes for vulnerability management, incident management, identity and access management, and compliance management; and informing the steering committee and board of directors of incidents and new or changed risks.

All employees Every employee in the organization should be required to comply with the organization’s security policy, as well as with security requirements and processes. All senior and executive management should demonstrably comply with these policies as an example for others.

NOTE Security governance should also make clear that compliance to policies is a condition of employment, and that employees who fail to comply with policy are subject to discipline or termination of employment.

Enterprise Architecture

Enterprise architecture (EA) is both a function and a model. In terms of a function, the establishment of an enterprise architecture consists of activities to ensure that important business needs are met by IT systems. EA may also involve the construction of a model that is used to map business functions into the IT environment and IT systems in increasing levels of detail.

The Zachman Model

The Zachman enterprise architecture framework, established in the late 1980s, continues to be the dominant EA standard today. Zachman likens IT enterprise architecture to the construction and maintenance of an office building: at a high (abstract, not number of floors) level, the office building performs functions such as containing office space. As we look into increasing levels of detail in the building, we encounter various trades (steel, concrete, drywall, electrical, plumbing, telephone, fire control, elevators, and so on), each of which has its own specifications, standards, regulations, construction and maintenance methods, and so on.

In the Zachman model, IT systems and environments are described at a high, functional level, and then in increasing detail, encompassing systems, databases, applications, networks, and so on. The Zachman framework is illustrated in Table 2-1.

While the Zachman model allows an organization to peer into cross-sections of an IT environment that supports business processes, the model does not convey the relationships between IT systems. Data flow diagrams are used instead to depict information flows.

Data Flow Diagrams

Data flow diagrams (DFDs) are frequently used to illustrate the flow of information between IT applications. Like the Zachman model, a DFD can begin as a high-level diagram, where the labels of information flows are expressed in business terms. Written specifications about each flow can accompany the DFD; these specifications would describe the flow in increasing levels of detail, all the way to field lengths and communication protocol settings.

Table 2-1 Zachman Framework Shows IT Systems in Increasing Levels of Detail

Figure 2-1 Typical data flow diagram (DFD) shows relationship between IT applications

Similar to Zachman, DFDs permit nontechnical business executives to easily understand the various IT applications and the relationships between them. A typical DFD is shown in Figure 2-1.

IT Strategic Planning

In a methodical and organized way, a good strategic planning process answers the question of what to do, often in a way that takes longer to answer than it does to ask. While IT organizations require personnel who perform the day-to-day work of supporting systems and applications, some IT personnel need to spend at least a part of their time developing plans for what the IT organization will be doing two, three, or more years in the future.

Strategic planning needs to be a part of a formal planning process, not an ad hoc, chaotic activity. Specific roles and responsibilities for planning need to be established, and those individuals must carry out planning roles as they would any other responsibility. A part of the struggle with the process of planning stems from the fact that strategic planning is partly a creative endeavor that includes analysis of reliable information about future technologies and practices, as well as long-term strategic plans for the organization itself. In a nutshell, the key question is, In five years, when the organization will be performing specific activities in a particular manner, how will IT systems support those activities?

But it’s more than just understanding how IT will support future business activities. Innovations in IT may help to shape what activities will take place, or at least how they will take place. On a more down-to-earth level, IT strategic planning is about the ability to provide the capacity for IT services that will match the levels of business that the organization expects to achieve at certain points in the future. In other words, if organization strategic planning predicts specific transaction volumes (as well as new types of transactions) at specific points in the future, then the job of IT strategic planning will be to ensure that IT systems of sufficient processing capacity will be up and running when needed.

Discussion of new business activities, as well as the projected volume of current activities at certain times in the future, is most often discussed by a steering committee.

The IT Steering Committee

A steering committee is a body of middle or senior managers or executives that meets from time to time to discuss high-level and long-term issues in the organization. An IT steering committee will typically discuss the future states of the organization and how the IT organization will meet the organization’s needs. A steering committee will typically consist of senior-level IT managers as well as key customers or constituents. This provider-customer dialogue will help to ensure that IT as the organization’s technology service arm will fully understand the future vision of the business and be able to support future business activities, in terms of both capacity and the ability to support new activities that do not yet exist.

NOTE The role of the IT steering committee also serves as the body for assessing results of recent initiatives and major projects, to gain a high-level understanding of past performance in order to shape future activities. The committee also needs to consider industry trends and practices, risks as defined by internal risk assessments, and current IT capabilities.

The role of the IT steering committee is depicted in Figure 2-2.

The steering committee needs to meet regularly, consider strategic issues, and make decisions that translate into actions, tasks, and projects in IT and elsewhere.

Figure 2-2 The IT steering committee synthesizes a future strategy using several inputs.

Policy, Processes, Procedures, and Standards

Policies, procedures, and standards define IT organizational behavior and uses of technology. They are a part of the written record that defines how the IT organization performs the services that support the organization.

Policy documents should be developed and ratified by IT management. Policies state only what must be done (or not done) in an IT organization. That way, a policy document will be durable—meaning it may last many years with only minor edits from time to time.

IT policies typically cover many topics, including

Roles and responsibilities This will range from general to specific, usually by describing each major role and responsibility in the IT department and then specifying which position is responsible for it. IT policies will also make general statements about responsibilities that all IT employees will share.

Development practices IT policy should define the processes used to develop and implement software for the organization. Typically, IT policy will require a formal development methodology that includes a number of specific ingredients such as quality review and the inclusion of security requirements and testing.

Operational practices IT policy defines the high-level processes that constitute IT’s operations. This will include service desk, backups, system monitoring, metrics, and other day-to-day IT activities.

IT processes, documents, and records IT policy will define other important IT processes, including incident management, project management, vulnerability management, and support operations. IT policy should also define how and where documents such as procedures and records will be managed and stored.

NOTE IT policy, like other organization policy, is generally focused on what should be done and on what parties are responsible for different activities. However, policy generally steers clear of describing how these activities should be performed. That, instead, is the role of procedures and standards, discussed later in this section.

The relationship between policies, processes, procedures, and standards is shown in Figure 2-3.

Figure 2-3 Policies, processes, procedures, and standards

Information Security Policy

Security policy defines how an organization will protect its important assets. Like IT policy, information security policy defines several fundamental principles and activities:

Roles and responsibilities Security policy should define specific roles and responsibilities including the roles of specific positions in the organization as well as the responsibilities of all staff members.

Risk management Security policy should define how the organization identifies and treats risks. An organization should perform periodic risk assessments and risk analysis, which will lead to decisions about risk treatment for specific risks that are identified.

Security processes Security policy should define important security processes such as vulnerability management and incident management, and incorporate security in other business processes such as software development and acquisition, vendor selection and management, and employee screening and hiring.

The best practice for information security policy is the definition of a top-down, management-driven information security program that performs periodic risk assessments to identify and focus on the most important risks in the organization. Roles and responsibilities define who is responsible for carrying out these activities. Executive management should have visibility and decision-making power, particularly in the areas of policy review and risk treatment.

It is generally accepted that security policy and security management should be separate from IT policy and IT management. This permits the security function to operate outside of IT, thereby permitting security to be objective and independent of IT. This puts security in a better position to be able to objectively assess IT systems and processes without fear of direct reprisal.

Privacy Policy

One of the most important policies an organization will develop that is related to information security is a privacy policy. A privacy policy describes how the organization will treat information that is considered private because it is related to a private citizen. A privacy policy defines two broad activities in this regard:

Protecting private information An organization that is required to collect, store, or transmit private information is duty bound to protect this information so that it is not disclosed to unauthorized parties. This part of a privacy policy will describe what information is obtained and how it is protected.

Handling private information Aside from the actual protection of private information, some organizations may, in the course of their business activities, transmit some or all of this information to other parts of the organization or to other organizations. A privacy policy is typically forthright about this internal handling and the transmittals to other parties. Further, a privacy policy describes how the information is used by the organization, and by other organizations to which it is transmitted. Privacy policy typically describes how a private citizen may confirm whether his or her private information is stored by the organization, whether it is accurate, and how the citizen can arrange for its removal if he or she wishes.

NOTE Many countries have privacy laws that require an organization to have a privacy policy and to enact safeguards to protect private information.

Procedures

Procedure documents, sometimes called SOPs (standard operating procedures), describe in step-by-step detail how IT processes and tasks are performed. Formal procedure documents ensure that tasks are performed consistently and correctly, even when performed by different IT staff members.

In addition to the actual steps in support of a process or task, a procedure document needs to contain several pieces of metadata:

Document revision information The procedure document should contain the name of the person who wrote the document and who made the most recent changes to the document. The document should also include the name or location where the official copy of the document may be found.

Review and approval The document should include the name of the manager who last reviewed the procedure document, as well as the name of the manager (or higher) who approved the document.

Dependencies The document should specify which other procedures are related to this procedure. This includes those procedures that are dependent upon this procedure, and the procedures that this one depends on. For example, a document that describes the database backup process will depend on database management and maintenance documents; documents on media handling will depend on this document.

IT procedure documents are not meant to be a replacement for vendor task documentation. For instance, an IT department does not necessarily need to create a document that describes the steps for operating a tape backup device when the device vendor’s instructions are available and sufficient. Also, IT procedure documents need not be remedial and include every specific keystroke and mouse click: they can usually assume that the reader has experience in the subject area and only needs to know how things are done in this organization. For example, a procedure document that includes a step that involves the modification of a configuration file does not need to include instructions on how to operate a text editor.

NOTE An IT department should maintain a catalog of its procedure documents, to facilitate convenient document management. This will permit IT management to better understand which documents are in its catalog and when each was last reviewed and updated.

Standards

IT standards are official, management-approved statements that define the technologies, protocols, suppliers, and methods that are used by an IT organization. Standards help to drive consistency into the IT organization, which will make the organization more cost-efficient and cost-effective.

An IT organization will have different types of standards:

Technology standards These standards specify what software and hardware technologies are used by the IT organization. Examples include operating system, database management system, application server, storage systems, backup media, and so on.

Protocol standards These standards specify the protocols that are used by the organization. For instance, an IT organization may opt to use TCP/IP v6 for its internal networks, GRP routing protocols, FTPS for file transfer, SSH for device management, and so forth.

Supplier standards This defines which suppliers and vendors are used for various types of supplies and services. Using established suppliers can help the IT organization through specially negotiated discounts and other arrangements.

Methodology standards This refers to practices used in various processes including software development, system administration, network engineering, and end-user support.

Configuration standards This refers to specific detailed configurations that are to be applied to servers, database management systems, end-user workstations, network devices, and so on. This enables users, developers, and technical administrative personnel to be more comfortable with IT systems, because the systems will be consistent with each other. This helps to reduce unscheduled downtime and to improve quality.

Architecture standards This refers to technology architecture at the database, system, or network level. An organization may develop reference architectures for use in various standard settings. For instance, a large retail organization may develop specific network diagrams to be used in every retail location, down to the colors of wires to use and how equipment is situated on racks or shelves.

NOTE Standards enable the IT organization to be simpler, leaner, and more efficient. IT organizations with effective standards will have fewer types of hardware and software to support, which reduces the number of technologies that must be mastered by the organization. An organization that standardizes on one operating system, one database management system, and one server platform need only build expertise in those technologies. This enables the IT organization to manage and support the environment more effectively than if many different technologies were in use.

Risk Management

Organizations need to understand which activities, practices, and systems are introducing unwanted risk into its operations. The span of activities that seek, identify, and manage these risks is known as risk management. Like many other processes, risk management is a life-cycle activity that has no beginning and no end. It’s a continuous and phased set of activities that includes the examination of processes, records, and systems in order to identify risks. This is continued by an analysis that examines a range of solutions for reducing or eliminating risks, followed by formal decision-making that brings about a resolution to risks.

Risk management needs to support overall business objectives. This support will include the adoption of a risk appetite that reflects the organization’s overall approach to risk. For instance, if the organization is a conservative financial institution, then that organization’s risk management program will probably adopt a position of being risk averse. Similarly, a high-tech startup organization that, by its very nature, is comfortable with overall business risk will probably be less averse to risks identified in its risk management program.

Regardless of its overall position on risk, when an organization identifies risks, the organization can take four possible actions:

Accept The organization accepts the risk as-is.

Mitigate The organization takes action to reduce the risk.

Transfer The organization shares the risk with another entity, usually an insurance company.

Avoid The organization discontinues the activity associated with the risk.

These alternatives are known as risk treatments. Often, a particular risk will be treated with a blended solution that consists of two or more of the actions just listed.

This section dives into the details of risk management, risk analysis, and risk treatment.

The Risk Management Program

An organization that chooses to build a risk management program should establish some principles that will enable the program to succeed. These may include

Objectives The risk management program must have a specific purpose; otherwise, it will be difficult to determine whether the program is successful. Example objectives: reduce number of industrial accidents, reduce the cost of insurance premiums, or reduce the number of stolen assets. If objectives are measurable and specific, then the individuals who are responsible for the risk management program can focus on its objectives in order to achieve the best possible outcome.

Scope Management must determine the scope of the risk management program. This is a fairly delicate undertaking because of the many interdependencies found in IT systems and business processes. However, in an organization with several distinct operations or business units (BUs), a risk management program could be isolated to one or more operational arms or BUs. In such a case, where there are dependencies on other services in the organization, those dependencies can be treated like an external service provider (or customer).

Authority The risk management program is being started at the request of one or more executives in the organization. It is important to know who these individuals are and their level of commitment to the program.

Roles and responsibilities This defines specific job titles, together with their respective roles and responsibilities in the risk management program. In a risk management program with several individuals, it should be clear as to which individuals or job titles are responsible for which activities in the program.

Resources The risk management program, like other activities in the business, requires resources to operate. This will include a budget for salaries as well as for workstations, software licenses, and possibly travel.

Policies, processes, procedures, and records The various risk management activities like asset identification, risk analysis, and risk treatment, along with some general activities like recordkeeping, should be written down.

NOTE An organization’s risk management program should be documented in a charter. A charter is a formal document that defines and describes a business program, and becomes a part of the organization’s record.

The risk management life cycle is depicted in Figure 2-4.

Figure 2-4 The risk management life cycle

The Risk Management Process

Risk management is a life-cycle set of activities used to identify, analyze, and treat risks. These activities are methodical and, as mentioned in the previous section, should be documented so that they will be performed consistently and in support of the program’s charter and objectives.

Asset Identification

The risk management program’s main objective (whether formally stated or not) is the protection of organization assets. These assets may be tangible or intangible, physical, logical, or virtual. Some examples of assets include

Buildings and property These assets include structures and other improvements.

Equipment This can include machinery, vehicles, and office equipment such as copiers and fax machines.

IT equipment This includes computers, printers, scanners, tape libraries (the devices that create backup tapes, not the tapes themselves), storage systems, network devices, and phone systems.

Supplies and materials These can include office supplies as well as materials that are used in manufacturing.

Records These include business records such as contracts, video surveillance tapes, visitor logs, and far more.

Information This includes data in software applications, documents, e-mail messages, and files of every kind on workstations and servers.

Intellectual property This includes an organization’s designs, architectures, software source code, processes, and procedures.

Personnel In a real sense, an organization’s personnel are the organization. Without its staff, the organization cannot perform or sustain its processes.

Reputation One of the intangible characteristics of an organization, reputation is the individual and collective opinion about an organization in the eyes of its customers, competitors, shareholders, and the community.

Brand equity Similar to reputation, this is the perceived or actual market value of an individual brand of product or service that is produced by the organization.

Grouping Assets For risk management purposes, an electronic inventory of assets will be useful in the risk management life cycle. It is not always necessary to list each individual asset: often it is acceptable to instead list classes of assets as a single asset entity for risk management purposes. For instance, a single entry for laptop computers is preferred over listing every laptop computer; this is because the risks for all laptop computers are roughly the same (ignoring behavior differences among individual employees). This eliminates the need to list them individually.

Similarly, groups of IT servers, network devices, and other equipment can be named instead of all of the individual servers and devices, again because the risks for each of them will usually be similar. However, one reason to create multiple entries for servers might be their physical location or their purpose: servers in one location may have different risks than servers in another location, and servers containing high-value information will have different risks than servers that do not contain high-value information.

Sources of Asset Data An organization that is undergoing its initial risk-management cycle has to build its asset database from scratch. Management will need to determine where this initial asset data will come from. Some choices include

Financial system asset inventory An organization that keeps all of its assets on the books will have a wealth of asset inventory information. However, it may not be entirely useful: asset lists often do not include the location or purpose of the asset, and whether it is still in use. Correlating a financial asset inventory to assets in actual use may consume more effort than the other methods for creating the initial asset. However, for organizations that have a relatively small number of highly valued assets (for instance, a rock crusher in a gold mine or a mainframe computer), knowing the precise financial value of an asset is highly useful, because the actual depreciated value of the asset is used in the risk analysis phase of risk management. Knowing the depreciated value of other assets is also useful, as this will figure into the risk treatment choices that will be identified later on.

Interviews Discussions with key personnel for purposes of identifying assets are usually the best approach. However, to be effective, several people usually need to be interviewed to be sure to include all relevant assets.

IT systems portfolio A well-managed IT organization will have formal documents and records for its major applications. While this information may not encompass every single IT asset in the organization, it can provide information on the assets supporting individual applications or geographic locations.

Online data An organization with a large number of IT assets (systems, network devices, and so on) can sometimes utilize the capability of local online data to identify those assets. For instance, a systems or network management system often includes a list of managed assets, which can be a pretty good starting point when creating the initial asset list.

Collecting and Organizing Asset Data It is rarely possible to take (or create) a list of assets from a single source. Rather, more than one source of information is often needed to be sure that the risk management program has identified at least the important, in-scope assets that it needs to worry about.

Unless an organization has a very short list of assets, it is usually useful to organize or classify assets. This will help to get the assets under study into smaller chunks that can be analyzed more effectively. There is no single way to organize assets, but a few ideas include

Geography A widely dispersed organization may want to classify its assets according to their location. This will aid risk managers during the risk analysis phase, since many risks are geographic centric, particularly natural hazards. Mitigation of risks is often geography based: for instance, it’s easier to make sense of building a fence around one data center than building fences around buildings located in individual locations.

Business process Because most organizations rank the criticality of their individual business processes, it can be useful to group assets according to the business processes that they support. This helps the risk analysis and risk treatment phases, because assets supporting individual processes can be associated with business criticality and treated appropriately.

Organizational unit In larger organizations it may be easier to classify assets according to the org unit they support.

Sensitivity Usually ascribed to information, sensitivity relates to the nature and content of the information. Sensitivity usually applies in two ways: to an individual, where the information is considered personal or private, and to an organization, where the information may be considered a trade secret. Sometimes sensitivity is somewhat subjective and arbitrary, but often it is defined in laws and regulations.

Regulated For organizations that are required to follow government or private regulation regarding the processing and protection of information, it will be useful to include data points that indicate whether specific assets are considered in-scope for specific regulations. This is important because some regulations specify how assets should be protected, so it’s useful to be aware of this during risk analysis and risk treatment.

There is no need to choose which of these three methods will be used to classify assets. Instead, an IT analyst should collect several points of metadata about each asset (including location, process supported, and org unit supported). This will enable the risk manager to sort and filter the list of assets in various ways to better understand which assets are in a given location or which ones support a particular process or part of the business.

NOTE Organizations should consider managing information about assets in a fixed-assets application.

Risk Analysis

Risk analysis is the activity in a risk management program where individual risks are identified. A risk consists of the intersection of threats, vulnerabilities, and impact. In its simplest terms, risk is described in the following formula:

Risk = Probability × Impact

This equation implies that risk is always used in quantitative terms, but risk is equally used in qualitative risk analysis.

A risk analysis consists of identifying threats and their impact of realization, against each asset. This usually also includes a vulnerability analysis, where assets are studied to determine whether they are vulnerable to identified threats. The sheer number of assets may make this task appear daunting; however, threat and vulnerability analyses can usually be performed against groups of assets. For instance, when identifying natural and human-made threats against assets, it often makes sense to perform a single threat analysis against all of the assets that reside in a given location. After all, the odds of a volcanic eruption are just as likely for any of the servers in the room—the threat need not be called out separately for each asset.

Threat Analysis The usual first step in a risk analysis is to identify threats against an asset or group of assets. A threat is an event that, if realized, would bring harm to an asset. A typical approach is to list all of the threats that have some realistic opportunity of occurrence; those threats that are highly unlikely to occur can be left out. For instance, the listing of meteorites, tsunamis in landlocked regions, and wars in typically peaceful regions will just add clutter to a risk analysis.

A more reasonable approach in a threat analysis is to identify all of the threats that a reasonable person would believe could occur, even if the probability is low. For example, include flooding when a facility is located near a river, hurricanes for an organization located along the southern and eastern coasts (and inland for some distance) of the United States, or a terrorist attack in practically every major city in the world. All of these would be considered reasonable in a threat analysis.

It is important to include the entire range of both natural and human-made threats. The full list could approach or even exceed 100 separate threats. The categories of possible threats include

Severe storms This may include tornadoes, hurricanes, windstorms, ice storms, and blizzards.

Earth movement This includes earthquakes, landslides, avalanches, volcanoes, and tsunamis.

Flooding This can include both natural and human-made situations.

Disease This includes sickness outbreaks and pandemics, as well as quarantines that result.

Fire This includes forest fires, range fires, and structure fires, all of which may be natural or human-caused.

Labor This includes work stoppages, sickouts, protests, and strikes.

Violence This includes riots, looting, terrorism, and war.

Malware This includes all kinds of viruses, worms, Trojan horses, root kits, and associated malicious software.

Hardware failures This includes any kind of failure of IT equipment or related environmental failures such as HVAC (heating, ventilation, and air conditioning).

Software failures This can include any software problem that precipitates a disaster. Examples are the software bug that caused a significant power blackout in the U.S. Northeast in 2003, and the AT&T long-distance network crash in 1990.

Utilities This includes electric power failures, water supply failures, and natural gas outages, as well as communications outages.

Transportation This may include airplane crashes, railroad derailments, ship collisions, and highway accidents.

Hazardous materials This includes chemical spills. The primary threat here is direct damage by hazardous substances, casualties, and forced evacuations.

Criminal This includes extortion, embezzlement, theft, vandalism, sabotage, and hacker intrusion. Note that company insiders can play a role in these activities.

Errors This includes mistakes made by personnel that result in disaster situations.

Alongside each threat that is identified, the risk analyst assigns a probability or frequency of occurrence. This may be a numeric value, expressed as a probability of one occurrence within a calendar year. For example, if the risk of a flood is 1 in 100, it would be expressed as 0.01, or 1 percent. Probability can also be expressed as a ranking; for example, Low, Medium, and High; or on a numeric probability scale from 1 to 5 (where 5 can be either highest or lowest probability).

An approach for completing a threat analysis is to

Perform a geographic threat analysis for each location. This will provide an analysis on the probability of each type of threat against all assets in each location.

Threat Forecasting Data Is Sparse

One of the biggest problems with risk management is the lack of reliable data on the probability of many types of threats. While the probability of some natural threats can sometimes be obtained from local disaster response agencies, the probabilities of most other threats are difficult to accurately predict.

The difficulty in the prediction of security events sits in stark contrast to volumes of available data related to automobile and airplane accidents, as well as human life expectancy. In these cases, insurance companies have been accumulating statistics on these events for decades, and the variables (for instance, tobacco and alcohol use) are well known. On the topic of cyber-related risk, there is a general lack of reliable data, and the factors that influence risk are not well known from a statistical perspective. It is for this reason that risk analysis still relies on educated guesses for the probabilities of most events.

Perform a logical threat analysis for each type of asset. This provides information on all of the logical (that is, not physical) threats that can occur to each asset type. For example, the risk of malware on all assets of one type is probably the same, regardless of their location.

Perform a threat analysis for each highly valued asset. This will help to identify any unique threats that may have appeared in the geographical or logical threat analysis, but with different probabilities of occurrence.

Vulnerability Identification A vulnerability is a weakness or absence of a protective control that makes the probability of one or more threats more likely. A vulnerability analysis is an examination of an asset in order to discover weaknesses that could lead to a higher-than-normal rate of occurrence of a threat.

Examples of vulnerabilities include

Missing or inoperative antivirus software

Missing security patches

Weak or defective application session management

Mantraps (devices that are designed to permit the passage of persons one at a time) that permit tailgating

In a vulnerability analysis, the risk manager needs to examine the asset itself as well as all of the protective measures that are—or should be—in place to protect the asset from relevant threats.

Vulnerabilities can be ranked by severity or criticality. Vulnerabilities are indicators that show the effectiveness (or ineffectiveness) of protective measures. For example, an antivirus program on a server that updates its virus signatures once per week might be ranked as a Medium vulnerability, whereas the complete absence (or malfunction) of an antivirus program on the same server might be ranked as a High vulnerability. Severity is an indication of the likelihood that a given threat might be realized. This is different from impact, which is discussed later in this section.

NOTE A vulnerability, and its ranking, should not be influenced by the probability that a threat will be realized. Instead, a vulnerability ranking should depend on whether the threat will actually bring about harm to the asset. Also, the ranking of a vulnerability should also not be influenced by the value of the asset or the impact of a realized threat. These factors are covered separately in risk management.

Probability Analysis For any given threat and asset, the probability that the threat will actually be realized needs to be estimated. This is often easier said that done, as there is a lack of reliable data on security incidents. A risk manager still will need to perform some research and develop a best guess, based on available data.

Impact Analysis A threat, when actually realized, will have some effect on the organization. Impact analysis is the study of estimating the impact of specific threats on specific assets.

In impact analysis, it is necessary to understand the relationship between an asset and the business processes and activities that the asset supports. The purpose of impact analysis is to identify the impact on business operations or business processes. This is because risk management is not an abstract identification of abstract risks, but instead a search for risks that have real impact on business operations.

In an impact analysis, the impact can be expressed as a rating such as H-M-L (High-Medium-Low) or as a numeric scale, and it can also be expressed in financial terms. But what is also vitally important in an impact analysis is the inclusion of a statement of impact for each threat. Example statements of impact include “inability to process customer support calls” and “inability for customers to view payment history.” Statements such as “inability to authenticate users” may be technically accurate, but they do not identify the business impact.

NOTE Because of the additional time required to quantify and develop statements of impact, impact analysis is usually performed only on the highest-ranked threats on the most critical assets.

Qualitative Risk Analysis A qualitative risk analysis is an in-depth examination of in-scope assets with a detailed study of threats (and their probability of occurrence), vulnerabilities (and their severity), and statements of impact. The threats, vulnerabilities, and impact are all expressed in qualitative terms such as High-Medium-Low or in quasi-numeric terms such as a 1–5 numeric scale.

The purpose of qualitative risk analysis is to identify the most critical risks in the organization, based on these rankings.

Qualitative risk analysis does not get to the issue of “how much does a given threat cost my business if it is realized?”—nor does it mean to. The value in a qualitative risk analysis is the ability to quickly identify the most critical risks without the additional burden of identifying precise financial impacts.

NOTE Organizations that do need to perform quantitative risk analysis often begin with qualitative risk analysis, to determine the highest-ranked risks that warrant the additional effort of quantitative analysis.

Quantitative Risk Analysis Quantitative risk analysis is a risk analysis approach that uses numeric methods to measure risk. The advantage of quantitative risk analysis is the statements of risk in terms that can be easily compared with the known value of their respective assets. In other words, risks are expressed in the same units of measure as most organizations’ primary unit of measure: financial.

Despite this, quantitative risk analysis must still be regarded as an effort to develop estimates, not exact figures. Partly this is because risk analysis is a measure of events that may occur, not a measure of events that do occur.

Standard quantitative risk analysis involves the development of several figures:

Asset value (AV) This is the value of the asset, which is usually (but not necessarily) the asset’s replacement value.

Exposure factor (EF) This is the financial loss that results from the realization of a threat, expressed as a percentage of the asset’s total value. Most threats do not completely eliminate the asset’s value; instead they reduce its value. For example, if a construction company’s $120,000 earth mover is destroyed in a fire, the equipment will still have salvage value, even if that is only 10 percent of the asset’s value. In this case the EF would be 90 percent. Note that different threats will have different impacts on EF, because the realization of different threats will cause varying amounts of damage to assets.

Single loss expectancy (SLE) This value represents the financial loss when a threat is realized one time. SLE is defined as AV × EF. Note that different threats have a varied impact on EF, so those threats will also have the same multiplicative effect on SLE.

Annualized rate of occurrence (ARO) This is an estimate of the number of times that a threat will occur per year. If the probability of the threat is 1 in 50, then ARO is expressed as 0.02. However, if the threat is estimated to occur four times per year, then ARO is 4.0. Like EF and SLE, ARO will vary by threat.

Annualized loss expectancy (ALE) This is the expected annualized loss of asset value due to threat realization. ALE is defined as SLE × ARO.

ALE is based upon the verifiable values AV, EF, and SLE, but because ARO is only an estimate, ALE is only as good as ARO. Depending upon the value of the asset, the risk manager may need to take extra care to develop the best possible estimate for ARO, based upon whatever data is available. Sources for estimates include

History of event losses in the organization

History of similar losses in other organizations

History of dissimilar losses

Best estimates based on available data

NOTE When performing a quantitative risk analysis for a given asset, the ALE for all threats can be added together. The sum of all ALEs is the annualized loss expectancy for the total array of threats. A particularly high sum of ALEs would mean that a given asset is confronted with a lot of significant threats that are more likely to occur. But in terms of risk treatment, ALEs are better off left as separate and associated with their respective threats.

Developing Mitigation Strategies An important part of risk analysis is the investigation of potential solutions for reducing or eliminating risk. This involves understanding specific threats and their impact (EF) and likelihood of occurrence (ARO). Once a given asset and threat combination has been baselined (that is, the existing asset, threats, and controls have been analyzed to understand the threats as they exist right now), the risk analyst can then apply various hypothetical means for reducing risk, documenting each one in terms of its impact on EF and ARO.

For example, suppose a risk analysis identifies the threat of attack on a public web server. Specific EF and ARO figures have been identified for a range of individual threats. Now the risk analyst applies a range of fixes (on paper), such as an application firewall, an intrusion prevention system, and a patch management tool. Each solution will have a specific and unique impact on EF and ARO (all estimates, of course, just like the estimates of EF and ARO on the initial conditions); some will have better EF and ARO figures than others. Each solution should also be rated in terms of cost (in financial estimate terms or H-M-L) and effort to implement (financial or H-M-L).

NOTE Developing mitigation strategies is the first step in risk treatment, where various solutions are put forward, each with its cost and impact on risk.

Risk Analysis and Disaster Recovery Planning Disaster recovery planning (DRP) and business continuity planning (BCP) utilize risk analysis to identify risks that are related to application resilience and the impact of disasters. The risk analysis performed for DRP and BCP is the same risk analysis that is discussed in this chapter—the methods and approach are the same, although the overall objectives are somewhat different.

Disaster recovery planning and business continuity planning are discussed in depth in Chapter 7.

High-Impact Events The risk manager is likely to identify one or more high-impact events during the risk analysis. These events, which may be significant enough to threaten the very viability of the organization, require risk treatment that belongs in the category of business continuity planning and disaster recovery planning. These topics are discussed in detail in Chapter 7.

Risk Treatment

When risks to assets have been identified through qualitative or quantitative risk analysis, the next step in risk management is to decide what to do about the identified risks. In the risk analysis, one or more potential solutions may have been examined, along with their cost to implement and their impact on risk. In risk treatment, a decision about whether to proceed with any of the proposed solutions (or others) is needed.

Risk treatment pits available resources against the need to reduce risk. In an enterprise environment, not all risks can be mitigated or eliminated, because there are not enough resources to treat them all. Instead, a strategy for choosing the best combination of solutions that will reduce risk by the greatest possible margin is needed. For this reason, risk treatment is often more effective when all the risks and solutions are considered together, instead of each one separately.

When risk treatment is performed at the enterprise level, risk analysts and technology architects can devise ways to bring about the greatest possible reduction in risk. This can be achieved through the implementation of solutions that will reduce many risks for many assets at once. For example, a firewall can reduce risks from many threats on many assets; this will be more effective than individual solutions for each asset.

So far I have been talking about risk mitigation as if it were the only option available when handling risk. Rather, you have four primary ways to treat risk: mitigation, transfer, avoidance, and acceptance. And there is almost always some leftover risk, called residual risk.

Risk Mitigation

Risk mitigation involves the implementation of some solution that will reduce an identified risk. For instance, the risk of malware being introduced onto a server can be mitigated with antivirus software or a network-based intrusion prevention system. Either of these solutions would constitute mitigation of this risk on a given asset.

NOTE An organization usually makes a decision to implement some form of risk mitigation after performing some cost analysis to determine whether the reduction of risk is worth the expenditure of risk mitigation.

Risk Transfer

Risk transfer means that some or all of the risk is being transferred to some external entity, such as an insurance company or business partner. When an organization purchases an insurance policy to protect an asset against damage or loss, the insurance company is assuming part of the risk in exchange for payment of insurance premiums.

Risk Avoidance

In risk avoidance, the organization abandons the activity altogether, effectively taking the asset out of service so that the threat is no longer a threat.

NOTE Organizations do not often back away completely from an activity because of identified risks. Generally this avenue is taken when the risk of loss is great and when the perceived probability of occurrence is high.

Risk Acceptance

Risk acceptance occurs when management is willing to accept an identified risk as-is, with no effort taken to reduce it.

Residual Risk

Residual risk is the risk that is left over from the original risk, after some of the risk has been removed through mitigation or transfer. For instance, if a particular threat had a probability of 10 percent before risk treatment and 1 percent after risk treatment, the residual risk is that 1 percent left over. This is best illustrated by the following formula:

Original Risk – Mitigated Risk – Transferred Risk = Residual Risk

NOTE It is unusual for risk treatment to eliminate risk altogether; rather, various controls are implemented that remove some of the risk. Often, management implicitly accepts the leftover risk; however, it’s a good idea to make that acceptance of residual risk more formal by documenting the acceptance in a risk management log or a decision log.

IT Management Practices

The primary services in the IT organization typically are development, operations, and support. These primary activities require the support of a second layer of activities that together support the delivery of primary IT services to the organization. The second layer of IT management practices consists of

Personnel management

Sourcing

Change management

Financial management

Quality management

Security management

Performance and capacity management

Some of these activities the IT organization undertakes itself, while some are usually performed by other parts of the organization. For instance, most of the personnel management functions are typically carried out by a human resources department.

Personnel Management

Personnel management encompasses many activities related to the status of employment, training, and the acceptance of policy. These personnel management activities ensure that the individuals who are hired into the organization are suitably vetted, trained, and equipped to perform their functions. It is important that they are provided with the organization’s key policies so that their behavior and decisions will reflect the organization’s needs.

Hiring

The purpose of the employee hiring process is to ensure that the organization hires persons who are qualified to perform their stated job duties and that their personal, professional, and educational history is appropriate. The hiring process includes several activities necessary to ensure that candidates being considered are suitable.

Background Verification It is estimated that 30–90 percent of employment candidates exaggerate their education and experience on their résumé, and some candidates commit outright fraud by providing false information about their education or prior positions. Because of this, employers need to perform their own background investigation on an employment candidate to obtain an independent assessment of the candidate’s true background.

Employers should examine the following parts of a candidate’s background prior to hiring:

Employment background An employer should check at least two years back, although five to seven years is needed for mid- or senior-level personnel.

Education background The employer should confirm whether the candidate has earned any of the degrees or diplomas listed on their résumé. There are many “diploma mills,” enterprises that will print a fake college diploma for a fee.

Military service background If the candidate served in any branch of the military, then this must be verified to confirm whether the candidate served at all and whether they received relevant training and work experience.

Professional licenses and certifications If a position requires licenses or certifications, these need to be confirmed, including whether the candidate is in good standing with the organizations that manage the licenses and certifications.

Criminal background The employer needs to investigate whether the candidate has a criminal record. In countries with a national criminal registry like the National Crime Information Center (NCIC) in the United States, this is simpler than in countries like India that have no nationwide database.

Credit background The employer may wish to examine a candidate’s credit and financial history. There are two principal reasons for this type of a check: first, a good credit history indicates the candidate is responsible, while a poor credit history may be an indication of irresponsibility or poor choices (although in many cases a candidate’s credit background is not entirely his or her own doing); second, a candidate with excessive debt and a poor credit history may be considered a risk for embezzlement, fraud, or theft.

Terrorist association Some employers wish to know whether a candidate has documented ties with terrorist organizations. In the United States, an employer can request a verification on whether a candidate is on one of several lists of individuals and organizations with whom U.S. citizens are prohibited from doing business. Lists are maintained by the Office of Foreign Assets Control (OFAC), a department of the U.S. Treasury, and also by the U.S. Department of Commerce and the U.S. Bureau of Industry and Security.

References The employer may wish to contact two or more personal and professional references—people who know the candidate and will vouch for his or her background, work history, and character.

NOTE In many jurisdictions, employment candidates are required to sign a consent form that will allow the employer (or a third-party agent acting on behalf of the employer) to perform the background check.

Background checks are a prudent business practice to identify and reduce risk. In many industries they are a common practice or even required by law. And in addition to performing a background check at the time of hire, many organizations perform them annually for employees in high-risk or high-value positions.

Employee Policy Manuals Sometimes known as an employee handbook, an employee policy manual is a formal statement of the terms of employment, facts about the organization, benefits, compensation, conduct, and other policies.

Employee handbooks are often the cornerstone of corporate policy. A thorough employee handbook usually will cover a wide swath of territory including the following topics:

Welcome This welcomes a new employee into the organization, often in an upbeat letter that makes the new employee glad to have joined the organization.

Policies These are the most important policies in the organization, which include security, privacy, code of conduct (ethics), and acceptable use of resources. In the United States and other countries the handbook may also include an anti-harassment policy.

Compensation This describes when and how employees are compensated.

Benefits This describes company benefit programs.

Work hours This discusses work hours and basic expectations for when employees are expected to report to work and how many hours per week they are expected to work.

Dress code This provides a description and guidelines for required attire in the workplace.

Performance review This describes the performance review policy and program.

Time off This describes compensated and uncompensated time off including holidays, vacation, illness, disability, military duty, and leaves of absence.

Security This discusses basic expectations on the topics of physical security and information security, as well as expectations for how employees are expected to handle confidential and sensitive information.

Regulation If the organization is subject to regulation, this may be mentioned in the employee handbook, so that employees will be aware of this and conduct themselves accordingly.

Safety This discusses workplace safety, which may cover evacuation procedures, emergency procedures, permitted and prohibited items and substances (for example, weapons, alcoholic beverages, other substances and items), procedures for working with hazardous substances, and procedures for operating equipment and machinery.

Conduct This covers basic expectations for workplace conduct, both with fellow employees and with customers, vendors, business partners, and other third parties.

Discipline Organizations that have a disciplinary process usually describe its highlights in the employee handbook.

NOTE Employees are often required to sign a statement that affirms their understanding of and compliance with the employee handbook. Many organizations require that employees sign a new copy of the statement on an annual basis, even if the employee handbook has not changed. This helps to affirm to employees the importance of the employee handbook.

Initial Access Provisioning New employees may need access to computers, networks, and/or applications to perform their required duties. This will necessitate the provisioning of one or more computer or network user accounts that they will use to perform their computer-related tasks.

An access-provisioning process should be used to determine the access privileges that a new employee should be given. A template of job titles and access privileges should be set up in advance so that management can easily determine which access privileges any new employee will receive. But even with such a plan, each new employee’s manager should still formally request these privileges be set up for new employees.

Job Descriptions A job description is a formal document that describes the roles, responsibilities, and experience required. Each position in an organization, from chief executive officer to office clerk, should have a formal job description.

Job descriptions should also state that employees are required to support company policies, including but not limited to security and privacy, code of conduct, and acceptable use policies. By listing these in a job description, an employer is stating that employees in every job description are expected to comply with these and other policies.

NOTE Employers usually are required to include several boilerplate items or statements (such as equal opportunity clauses) in job descriptions to conform to local labor and workplace safety laws.

Employee Development

Once hired into the organization, employees will require training in the organization’s policies and practices so that their contribution will be effective and further the organization’s goals. Regular evaluation will help employees to focus their long-term efforts toward personal and organization goals and objectives, in order to better focus their efforts.

Training To be effective, employees need to receive periodic training. This includes

Skills training This covers the need to learn how to use tools and equipment properly. In some cases, employees are required to receive training and prove competency before they are permitted to use some tools and equipment. Sometimes this is required by law.

Practices and techniques Employees need to understand how the organization uses its tools and equipment for its specific use.

Policies Organizations often impart information about their policies in the context of training. This helps the organization make sure that employees comprehend the material.

Performance Evaluation Many organizations utilize a performance evaluation process that is used to examine each employee’s performance against a set of expectations and objectives. A performance evaluation program also helps to shape employees’ behavior over the long term and helps them to reflect on how their effort contributes toward the organization’s overall objectives. Performance evaluation is frequently used to determine whether (and by how much) an employee’s compensation should be increased.

Career Path In many cultures, employees feel that they can be successful if they understand how they can advance within the organization. A career path program can achieve this by helping employees understand what skills are required for other positions in the organization, and how they can strive toward positions that they desire in the future.

Mandatory Vacations

Some organizations, particularly those that deal with high-risk or high-value activities, enact mandatory vacations of one week or longer for some or all employees. This practice can accomplish three objectives:

Cross training An absence of one week or longer will force management to cross-train other employees, so that the organization is less reliant upon specific individuals.

Audit A minimum absence gives the organization an opportunity to audit the absent employee’s work, to make sure that the employee is not involved in any undesired behavior.

Reduced risk Knowing that they will be away from their day-to-day activities for at least one or two contiguous weeks each year, employees are less apt to partake in prohibited activities.

Termination

When an employee leaves an organization, several actions need to take place:

Physical access to all work areas must be immediately revoked. Depending upon the sensitivity of work activities in the organization, the employee may also need to be escorted out of the work area, and his or her personal belongings gathered by others and delivered to the departed employee.

Each of the employee’s computer and network access accounts needs to be locked. The purpose of this is to protect the integrity of business information by permitting only authorized employees to access it. Locking computer accounts also prevents other employees from accessing information using the former employee’s credentials.

NOTE The issue of whether a former employee’s account should be removed, or merely locked, depends upon the nature of the application or system. In some cases, the record of actions taken by employees (such as an audit log) depends upon the existence of the employee’s ID on the system; if a former employee’s ID is removed, then those audit records may not properly reference who is associated with them.

If the organization chooses to lock, rather than remove, computer or network accounts for terminated employees, those accounts must be locked or restricted in a way that positively prohibits any further access. For instance, merely changing the passwords of terminated accounts to “locked” would be considered a highly unsafe practice, in the event that anyone discovers the password. If changing the account’s password is the only way to lock it, then a long and highly random password must be used and then forgotten, so that even the account administrator cannot use it.

Transfers and Reassignments

In many organizations, employees will move from position to position over time. These position changes are not always upward through a career path, but are instead lateral moves from one type of work to another.

Unless an organization is very careful about its access management processes and procedures, employees who transfer and are promoted tend to accumulate access privileges. This happens because a transferring employee’s old privileges are not revoked, even though those privileges are no longer needed. Over a period of many years, an employee who is transferred or promoted every few years can accumulate many excessive privileges that can signify significant risk, should the individual choose to perform functions in the applications that they are no longer officially authorized to use. This phenomenon is sometimes known as “accumulation of privileges” or “privilege creep.”

Privilege creep happens frequently in companies’ accounting departments. An individual, for example, can move from role to role in the accounting department, all the while accumulating privileges that eventually result in the ability for that employee to defraud his or her employer by requesting, approving, and disbursing payments to themselves or their accomplices. Similarly, this can occur in an IT department when an employee transfers from the operations department to the software development department (which is a common career path). Unless the IT department deliberately removes the transferring employee’s prior privileges, it will end up with an employee who is a developer with access to production systems—a red flag to auditors who examine roles and responsibilities.

Sourcing

The term sourcing refers to the choices that organizations make when selecting the personnel who will perform functions, and where those functions will be performed.

The options include whose personnel will perform tasks:

Insourced The organization hires employees to perform work. These workers can be full time, part time, or temporary.

Outsourced The organization utilizes contractors or consultants to perform work.

Hybrid The organization can utilize a combination of insourced and outsourced workers.

Next, the options include where personnel will perform tasks:

On-site Personnel work in the organization’s work site(s).

Off-site, local Personnel are not located on-site, but are near the organization’s premises, usually in the same community.

Off-site, remote Personnel are in the same country, but not near the organization’s premises.

Offshore Personnel are located in a different country.

NOTE Organizations are often able to work out different combinations of whether personnel are insourced or outsourced and where they perform their work. For instance, an organization can open its own office in a foreign country and hire employees to work there; this would be an example of offshore insourcing. Similarly, an organization can use contractors to perform work on-site; this is on-site outsourcing.

Insourcing

Insourcing, which is the practice of hiring employees for long-term work, is discussed earlier in this chapter in the “Personnel Management” section.

Outsourcing

Outsourcing is the practice of using contractors or consultants to perform work for the organization. An organization will make a decision to outsource a task, activity, or project for a wide variety of reasons:

Project duration An organization may require personnel only for a specific project, such as the development of or migration to a new application. Often an organization will opt to use contractors or consultants when it cannot justify hiring permanent workers.

Skills An organization may require personnel with certain hard-to-find skills, but not need them on a full-time basis. Persons with certain skills may command a higher salary than the organization is willing to pay, and the organization may not have sufficient work to keep such a worker interested in permanent employment with the organization.

Variable demand Organizations may experience seasonal increases and decreases of demand for certain workers. Organizations often cannot justify hiring full-time employees for peak demand capacity, when at other times those workers will not have enough work to keep them busy and productive. Instead, organizations will usually staff for average demand and augment staff with contractors for peak demand.

High turnover Some positions, such as IT helpdesk and call center, are inherently high-turnover positions that are costly to replace and train. Instead, an organization may opt to outsource some or all of the personnel in these positions.

Focus on core activities An organization may wish to concentrate on hiring for positions related to its core purpose and to outsource functions that are considered “overhead.” For instance, an organization that produces computer hardware products may elect to outsource its IT computer support department so that it can focus on its product development and support.

Financial A decision to outsource may be primarily financial. Usually an organization seeking to reduce costs of software development and other activities will outsource and off-shore these activities to service organizations located in other countries.

An organization can outsource many of its functions, including these:

IT helpdesk and support This is often a high-turnover function, as well as variable in demand, making this a good candidate for outsourcing.

Software development An organization that lacks development and programming skills can elect to have contractors or consultants perform this work.

Software maintenance An organization may wish to keep its developers and analysts focused on new software development projects and to leave maintenance of existing software to contractors.

Customer support An organization may choose to outsource its telephone and online support to personnel or organizations in countries with lower labor costs.

NOTE Although outsourcing decisions appear, on the surface, to be economically motivated, some of the other reasons stated earlier may be even more important in some organizations. For example, the flexibility afforded by outsourcing may help to make an organization more agile, which may improve quality or increase efficiency over longer periods.

Outsourcing Benefits Organizations that are considering outsourcing need to carefully weigh the benefits and the costs in order to determine whether the effort to outsource will result in measurable improvement in their processing, service delivery, or finances. In the 1990s, when many organizations rushed to outsource development and support functions to operations in other countries, they did so with unrealistic short-term gains in mind and without adequately considering all of the real costs of outsourcing. This is not to say that outsourcing is bad, but that many organizations made outsourcing decisions without fully understanding it.

Outsourcing can bring many benefits:

Available skills and experience Organizations that may have trouble attracting persons with specialized skills often turn to outsourcing firms whose highly skilled personnel can ply their trade in a variety of client organizations.

Economies of scale Often, specialized outsourcing firms can achieve better economies of scale through discipline and mature practices that organizations are unable to achieve.

Objectivity Some functions are better done by outsiders. Personnel in an organization may have trouble being objective about some activities such as process improvement and requirements definition. Also, auditors frequently must be from an outside firm in order to achieve sufficient objectivity and independence.

Reduced costs When outsourcing is done with offshore personnel, an organization may be able to lower its operating costs and improve its competitive market position.

When an organization is making an outsourcing decision, it needs to consider these advantages together with risks that are discussed in the next section.

Outsourcing Risks While outsourcing can bring many tangible and intangible benefits to an organization, it is not without certain risks and disadvantages. Naturally when an organization employs outsiders to perform some of its functions, it relinquishes some control. The risks of outsourcing include these:

Higher than expected costs Reduced costs were the main driver for offshore outsourcing in the 1990s. However, many organizations failed to fully anticipate the operational realities. For instance, when outsourcing to overseas operations, IT personnel back in U.S.-based organizations had to make many more expensive trips than expected. Also, changes in international currency exchange rates can transform this month’s bargain into next month’s high cost.

Poor quality The outsourced work product may be lower than was produced when the function was performed in-house.

Poor performance The outsourced service may not perform as expected. The capacity of networks or IT systems used by the outsourcing firm may cause processing delays or longer than acceptable response times.

Loss of control An organization that is accustomed to being in control of its workers may feel loss of control. Making small adjustments to processes and procedures may be more time-consuming or increase costs.

Employee integrity and background It may be decidedly more difficult to determine the integrity of employees in an outsourced situation, particularly when the outsourcing is taking place offshore. Some countries, even where outsourcing is popular, lack nationwide criminal background checks and other means for making a solid determination on an employee’s background.

Loss of competitive advantage If the services performed by the outsourcing firm are not flexible enough to meet the organization’s needs, this can result in the organization losing some of its competitive advantage. For example, an organization outsources its corporate messaging (e-mail and other messaging) to a service provider. Later, the organization wishes to enhance its customer communication by integrating its service application with e-mail. The e-mail service provider may be unable or unwilling to provide the necessary integration, which will result in the organization losing a competitive advantage.

Errors and omissions The organization performing outsourcing services may make serious errors or fail to perform essential tasks. For instance, an outsourcing service may suffer a data security breach that may result in the loss or disclosure of sensitive information. This can be a disastrous event when it occurs within an organization’s four walls, but when it happens in an outsourced part of the business, the organization may find that the lack of control will make it difficult to take the proper steps to contain and remedy the incident. If an outsourcing firm has a security breach or other similar incident, it may be putting itself first, and only secondarily watching out for the interests of its customers.

Vendor failure The failure of the organization providing outsourcing services may result in increased costs and delays in service or product delivery.

Differing mission and goals An organization’s employees are going to be loyal to its mission and objectives. However, the employees in an outsourced organization usually have little or no interest in the hiring organization’s interests; instead they will be loyal to the outsourcing provider’s values, which may at times be in direct conflict. For example, an outsourcing organization may place emphasis on maximizing billable hours, while the hiring organization emphasizes efficiency. These two objectives conflict with each other.

Difficult recourse If an organization is dissatisfied with the performance or quality of its outsourced operation, contract provisions may not sufficiently facilitate any remedy. If the outsourced operation is in a foreign country, applying remediation in the court system may also be futile.

Lowered employee morale If a part of an organization chooses to outsource, those employees who remain may be upset, because some of their colleagues may have lost their jobs as a result of the outsourcing. Further, remaining employees may feel that their own jobs may soon be outsourced or eliminated. They may also feel that their organization is more interested in saving money than in taking care of its employees. Personnel who have lost their jobs may vent their anger at the organization through a variety of harmful actions that may threaten assets or other workers.

Audit and compliance An organization that outsources a part of its operation that is in-scope for applicable laws and regulation may find it more challenging to perform audits and achieve compliance. Audit costs may rise, as auditors need to visit the outsourced work centers. Requiring the outsourced organization to make changes to achieve compliance may be difficult or expensive.

Time zone differences Communications will suffer when an organization outsources some of its operations to offshore organizations that are several time zones distant. It will be more difficult to schedule telephone conferences when there is very little overlap between workers in each time zone. It will take more time to communicate important issues and to make changes.

Language and cultural differences When outsourcing crosses language and cultural barriers, it can result in less than optimal communication and results. The outsourcing customer will express its needs through its own language and culture, but the outsourcing provider will hear those needs through its own language and culture. Both sides may be thinking or saying, “They don’t understand what we want” and “We don’t understand what they want.” This can result in unexpected differences in work products produced by the outsourcing firm. Delays in project completion or delivery of goods and services can be a result of this.

NOTE Some of the risks associated with outsourcing are intangible or may lie outside the bounds of legal remedies. For instance, language and time zone differences may introduce delays in communication, adding friction to the business relationship in a way that may not be easily measurable.

Mitigating Outsourcing Risk The only means of exchange between an outsourcing provider and its customer organization are money and reputation. In other words, the only leverage that an organization has against its outsourcing provider is the withholding of payment and through communicating the quality (or lack therein) of the outsourcing provider to other organizations. This is especially true if the outsourcing crosses national boundaries. Therefore, an organization that is considering outsourcing must carefully consider how it will enforce contract terms so that it receives the goods and services that it is expecting.

Many of the risks of outsourcing can be remedied through contract provisions. Some of the remedies are

Service level agreement (SLA) The contract should provide details on every avenue of work performance and communication, including escalations and problem management.

Quality Depending upon the product or service, this may translate into an error or defect rate, a customer satisfaction rate, or system performance.

Security policy and controls Whether the outsourcing firm is safeguarding the organization’s intellectual property, keeping business secrets, or protecting information about its employees or customers, the contract should spell out the details of the security controls that it expects the outsourcing firm to perform. The organization should also require periodic third-party audits and the results of those audits. The contract should contain a “right to audit” clause that allows the outsourcing organization to examine the work premises, records, and work papers on demand.

Business continuity The contract should require the outsourcing firm to have reasonable measures and safeguards in place to ensure resilience of operations and the ability to continue operations with minimum disruption in the event of a disaster.

Employee integrity The contract should define how the outsourcing firm will vet its employees’ background, so that it is not inadvertently hiring individuals with a criminal history, and so employees’ claimed education and work experience are genuine.

Ownership of intellectual property If the outsourcing firm is producing software or other designs, the contract must define ownership of those work products, and whether the outsourcing firm may reuse any of those work products for other engagements.

Roles and responsibilities The contract should specify in detail the roles and responsibilities of each party, so that each will know what is expected of them.

Schedule The contract must specify when and how many items of work products should be produced.

Regulation The contract should require both parties to conform to all applicable laws and regulations, including but not limited to intellectual property, data protection, and workplace safety.

Warranty The contract should specify terms of warranty for the workmanship and quality of all work products, so that there can be no ambiguity regarding the quality of goods or services performed.

Dispute and resolution The contract should contain provisions that define the process for handling and resolving disputes.

Payment The contract should specify how and when the outsourcing provider will be paid. Compensation should be tied not only to the quantity but also to the quality of work performed. The contract should include incentive provisions for additional payment when specific schedule, quantity, or quality targets are exceeded. The contract should also contain financial penalties that are enacted when SLA, quality, security, audit, or schedule targets are missed.

NOTE The terms of an outsourcing contract should adequately reward the outsourcing firm for a job well done, which should include the prospect of earning additional contracts as well as referrals that will help it to earn outsourcing contracts from other customers.

Outsourcing Governance You cannot outsource accountability.

Outsourcing is a convenient way to transfer some operations to an external organization, thereby allowing the outsourcing organization to be more agile and to improve focus on core competencies. While senior managers can transfer these activities to external organizations and even specify rewards for good performance and penalties for substandard performance, those senior managers are still ultimately accountable for the delivery of these services, whether they are outsourced or performed by internal staff.

In the context of outsourcing, the role of governance is the aggregation of activities that control the work performed by external organizations. Governance activities may include

Contracts The overall business relationship between the organization and its service providers should be defined in detail in legal agreements. The terms of legal agreements should define the work to be done (in general), the expectations of all parties, service levels, quality, the terms of compensation, and remedies in case expectations fail to be met.

Work orders Sometimes called Statements of Work (SOWs), work orders describe in greater detail the work that is to be performed. While contracts are expected to change seldom, work orders operate in short-term intervals and are specific to currently delivered goods or services. Like contracts themselves, work orders should include precise statements regarding work output, timeliness, quality, and remedies.

Service level agreements These are documents that specify service levels in terms of the quantity of work, quality, timeliness, and remedies for shortfalls in quality or quantity.

Change management A formal method is needed so that changes in delivery specifications can be formally controlled.

Security If the service provider has access to the organization’s records or other intellectual property, the organization will require that specific security controls be in place.

Quality Minimum standards for quality should be expressed in detail, so that both service provider and customer have a common understanding on the quality of work to be performed.

Metrics Often the outsourcing organization will want to actively measure various aspects of the outsourced activity, in order to have short-term visibility into work output as well as the ability to understand long-term trends.

Audits The outsourcing organization may require that audits of the outsourced work be performed. These audits may be performed by a competent third party (such as a public accounting firm performing a SAS70 audit for financially related services) or by the customer. Often an outsourcing organization will negotiate a “right to audit” clause in the contract, but will only exercise this if they suspect irregularities or issues related to the work performed.

Depending on the nature of specific outsourcing arrangements, the activities just listed may be combined or performed separately.

Benchmarking Benchmarking measures a process in order to compare its performance and quality with the same process in other organizations. The purpose is to discover opportunities for improvement that may result in lower cost, fewer resources, and higher quality.

In the context of outsourcing, benchmarking can be used to measure the performance of an outsourced process with the same process as performed by other outsourcing firms, as well as to compare it with the same process as performed internally by other organizations. The objective is the same: to learn whether a particular outsourcing solution is performing effectively and efficiently. Benchmarking is discussed in further detail in Chapter 4.

Third-Party Service Delivery Management

Service delivery management is the institution of controls and metrics to ensure that services are performed properly and with a minimum of incidents and defects. When activities are transferred to a service provider, service delivery management has some added dimensions and considerations.

When service delivery management is used to manage an external service provider, the service provider must be required to maintain detailed measurements of its work output. The organization utilizing an external service provider needs to also maintain detailed records of work received, as well as to perform its own defect management controls in order to ensure that the work performed by the service provider meets quality standards. Problems and incidents encountered by the organization should be documented and transmitted to the service provider in order to improve quality.

These activities should be included in the service level agreement (SLA) or in the contract in order to ensure that the customer will be able to impose financial penalties or other leverage onto the service provider in order to improve quality while maintaining minimum work output.

Service delivery standards are defined in the international standard, ISO 20000. Relevant controls from this standard can be used to impose a standard method for managing service delivery by the service provider.

Software-as-a-Service Considerations

Software as a Service (SaaS) is an arrangement where an organization obtains a software application for use by its employees, where the software application is hosted by the software provider, as opposed to the customer organization. The primary advantages of using SaaS as opposed to self hosting are

Capital savings The SaaS provider hosts the application on its own servers, thereby eliminating the need to purchase servers and other equipment.

Labor savings The SaaS provider performs all systems and database administration functions, including typical administrative tasks such as applying software or operating system patches, performance and capacity management, software upgrades, and troubleshooting.

NOTE An organization that is considering a SaaS provider for one of its applications will need to ensure that the SaaS provider has adequate controls in place to protect the organization’s data. In particular, the SaaS provider should have controls in place that will prevent one SaaS customer from being able to view the data associated with a different customer.

An organization can consider a SaaS provider to be similar to other service providers. Generally, methods used to determine the integrity and quality of a SaaS provider would be the same as used with other service providers.

Change Management

Change management is a business process that is used to control changes made to an IT environment. A formal change-management process consists of several steps that are carried out for each change:

Request

Review

Approve

Perform change

Verify change

Each step in change management includes recordkeeping. Change management is covered in detail in Chapter 4.

Financial Management

Sound financial management is critical in any organization. Because IT is a cost-intensive activity, it is imperative that the organization be well managed, with short-term and long-term budget planning, and that it track actual spending.

One area where senior management needs to make strategic financial decisions in IT is the manner in which it acquires software applications. At the steering committee level, IT organizations need to carefully weigh “make versus buy” with its primary applications. This typically falls into three alternatives:

Develop the application The organization develops the application using in-house or contracted software developers, designers, and analysts.

Purchase the application The organization licenses the application from a software vendor and installs it on servers that it leases or purchases.

Rent the application This generally refers to the Software-as-a-Service (SaaS) model, where the application service provider hosts the application on its own premises (or on an Internet data center), and the organization using the software pays either a fixed fee or an on-demand fee. The organization will have no capital cost for servers, and little or no development cost (except, possibly, for interfaces to other applications).

The choice that an organization makes is not just about the finances, but is also concerned with the degree of control that the organization requires.

IT financial management is about not only applications, but also the other services that an IT organization provides. Other functions such as service desk, PC build and support, e-mail, and network services can likewise be insourced or outsourced, each with financial and other implications.

NOTE Many larger organizations employ a “chargeback” feature for the delivery of IT services. This is a method where an IT organization charges (usually through budget transfers but occasionally through real funds) for the services that it provides. The advantage to chargeback is that the customers of the IT organization are required to budget for IT services and are less likely to make frivolous requests of IT, since every activity has a cost associated with it. Chargeback may also force an IT organization to be more competitive, as chargeback may invite IT’s customers to acquire services from outside organizations and not from the internal IT organization. Chargeback can thus be viewed as outsourcing to the internal IT organization.

Quality Management

Quality management refers to the methods by which business processes are controlled, monitored, and managed to bring about continuous improvement. The scope of a quality management system in an IT organization may cover any or all of the following activities:

Software development

Software acquisition

Service desk

IT operations

Security

The components that are required to build and operate a quality management system are

Documented processes Each process that is a part of a quality management system must be fully documented. This means that all of the tasks, notifications, records, and data flows must be fully described in formal process documents that are themselves controlled.

Key measurements Each process under quality management must have some key measurement points so that management will be able to understand the frequency and effort expended for the process. Measurement goes beyond simply tallying and must include methods for recognizing, classifying, and measuring incidents, events, problems, and defects.

Management review of key measurements Key measurements need to be regularly analyzed and included in status reports that provide meaningful information to various levels of management. This enables management to understand how key processes are performing, and whether they are meeting management’s expectations.

Audits Processes in a quality management system should be periodically measured by internal or external auditors to ensure that they are being operated properly. These auditors need to be sufficiently independent of the processes and of management itself so that they can objectively evaluate processes.

Process changes When key measurements suggest that changes to a process are needed, a business or process analyst will make changes to the design of a process. Examples of process changes include the addition of data fields in a change request process, the addition of security requirements to the software development process, or a new method for communicating passwords to the users of newly created user accounts.

NOTE An organization should document and measure its quality management processes, just as it does with all of the processes under its observation and control. This will help to confirm whether the quality management system itself is effective.

ISO 9000

Established in the 1980s, ISO 9000 remains the world’s standard for quality management systems. The ISO 9001, 9002, 9003, and 9004 standards have been superseded by the single ISO 9001:2008 Quality Management System standard.

Organizations that implement the ISO 9001:2008 standard can voluntarily undergo regular external audits by an accredited firm to earn an ISO 9001:2008 certification.

NOTE ISO 9000 began as a manufacturing product quality standard. While many manufacturing firms are certified to ISO 9000, the standard is growing in popularity among service providers and software development organizations.

ISO 20000

IT organizations have been adopting the IT Infrastructure Library (ITIL) of IT service management processes as a standard framework for IT processes. Organizations that desire a certification can be evaluated by an accredited external audit firm to the ISO 20000 IT Service Management standard. ISO 20000 supersedes the earlier BS 15000 standard.

The ITIL framework consists of 13 processes in five process groups:

Service Delivery Processes The six processes in this group are capacity management, service continuity and availability management, service level management, service reporting, information security management, and budgeting and accounting. Capacity management is the practice of ensuring that IT systems have sufficient capacity to service business needs. Service continuity and availability management is the practice of guaranteeing that IT systems will function despite disruptive events such as equipment malfunctions and disasters. This is covered in detail in Chapter 7. Security management is covered throughout this book. Service level management and service reporting are covered in Chapter 5.

Control Processes The two processes in this group are configuration management and change management. Configuration management is the practice of recording configuration changes in IT systems; this is discussed in Chapter 5.

Release Processes The process in this group is release management. This is the practice of promoting software and configuration changes onto production systems. This topic is discussed in Chapter 5.

Relationship Processes The two processes in this group are business relationship management and supplier management. Business relationship management is beyond the scope of this book. Supplier management is discussed lightly in this chapter in the earlier section, “Sourcing.”

Resolution Processes The two processes in this group are incident management and problem management. An incident is any event that is not a part of the standard operation of an IT service and which causes an interruption to or reduction in quality of an IT service. A problem is the underlying cause of one or more incidents. These topics are discussed in Chapter 5.

All of these processes are interrelated and together constitute an effective framework for IT’s primary function: delivering valuable services to enable key organization processes.

Security Management

Security management refers to several key activities that all work to identify risks and risk treatment for the organization’s assets. In most organizations these activities should include

Security governance Security governance is the practice of setting organization security policy, and then taking steps to ensure that policy is followed. Security governance also is involved with the management and continuous improvement of other key security activities discussed in this section.

Risk assessment This is the practice of identifying all of the key assets in use by the organization, and identifying vulnerabilities and threats against each asset. This is followed by the development of risk treatment strategies that attempt to mitigate, transfer, avoid, or accept identified risks.

Incident management This practice is concerned with the planned response to security incidents, when they occur in the organization. An incident is defined as a violation of security policy; such an incident may be minor (such as a user choosing an easily guessed password) or major (such as a hacking attack and theft of sensitive information). Some of the aspects of incident management include computer forensics (the preservation of evidence that could be used in later legal action) and the involvement of regulatory authorities and law enforcement.

Vulnerability management This is the practice of proactively identifying vulnerabilities in IT systems, as well as in business processes, which could be exploited to the detriment of the organization. Activities that take place in vulnerability management include security scanning, patch management, and reviewing threat and risk advisories issued by software vendors and security organizations.

Access and identity management These practices are used to control which persons and groups may have access to which organization assets, systems, and functions. Identity management is the activity of managing the identity of each employee, contractor, temporary worker, and optionally, customer. These records are then used as the basis for controlling which buildings, IT systems, and business functions each person is permitted to use.

Compliance management Security management should be responsible for knowing which laws, regulations, standards, requirements, and legal contracts the organization is required to comply with. Verification of compliance may involve internal or external audits and other activities to confirm that the organization is in compliance with all of these legal and other requirements.

Business continuity and disaster recovery planning These practices allow the organization to develop response plans in the event that a disaster should occur that would otherwise threaten the ongoing viability of the organization. Business continuity and disaster recovery planning is covered in detail in Chapter 7.

Optimizing Performance

Performance optimization is concerned with the continual improvement of IT processes and systems. This set of activities is concerned not only with financial efficiency, but also with the time and resources required to perform common IT functions. The primary objective of IT performance optimization is to ensure that the organization is getting the maximum benefit of IT services for the lowest possible expenditure of resources.

Performance optimization is considered a rather mature approach to the management of IT processes and systems. It requires mature processes with key controls and measurement points, and is one of the natural results of effective quality management. See the earlier section “Quality Management” for more information on this perspective.

Performance optimization is a complicated undertaking, because IT systems and processes usually change frequently over time; it can be difficult to attribute specific changes in systems or processes to changes in performance metrics.

Maturity models such as SEI CMMI (Software Engineering Institute Capability Maturity Model Integration) can be used to determine the level of an organization’s processes. SEI CMMI focuses on whether an organization’s processes have a level of maturity associated with measurement and continuous improvement.

The COBIT (Control Objectives for Information and related Technology) framework also contains facilities to identify and measure key performance indicators, with the aim of enabling continuous improvement to processes and technology. The COBIT framework contains 34 key IT processes, along with the means for any individual organization to determine how much (and what kind of) control is appropriate for each organization, based upon its business objectives and how IT supports them.

Organization Structure and Responsibilities

Organizations require structure to distribute responsibility to groups of people with specific skills and knowledge. The structure of an organization is called an organization chart (org chart). Figure 2-5 shows a typical IT organization chart.

Organizing and maintaining an organization structure requires that many factors be taken into account. In most organizations, the org chart is a living structure that changes frequently, based upon several conditions including

Short- and long-term objectives Organizations sometimes move departments from one executive to another so that departments that were once far from each other (in terms of the org chart structure) will be near each other. This provides new opportunities for developing synergies and partnerships that did not exist before the reorganization (reorg). These organizational changes are usually performed to help an organization meet new objectives that require new partnerships and teamwork that were less important before.

Figure 2-5 Typical IT organization chart

Market conditions Changes in market positions can cause an organization to realign its internal structure in order to strengthen itself. For example, if a competitor lowers its prices based on a new sourcing strategy, an organization may need to respond by changing its organizational structure in order to put experienced executives in charge of specific activities.

Regulation New regulations may induce an organization to change its organizational structure. For instance, an organization that becomes highly regulated may elect to move its security and compliance group away from IT and place it under the legal department, since compliance has much more to do with legal compliance than industry standards.

Attrition and available talent When someone leaves the organization (or moves to another position within the organization), particularly in positions of leadership, a space opens in the org chart that often cannot be filled right away. Instead, senior management will temporarily change the structure of the organization by moving the leaderless department under the control of someone else. Often, the decisions of how to change the organization will depend upon the talent and experience of existing leaders, in addition to each leader’s workload and other factors. For example, if the director of IT program management leaves the organization, the existing department could temporarily be placed under the IT operations department, in this case because the director of IT operations used to run IT program management. Senior management can see how that arrangement works out and later decide whether to replace the director of IT program management position or to do something else.

NOTE Many organizations use formal succession planning as a way of preparing for unexpected changes in the organization, especially terminations and resignations. A succession plan helps the organization to temporarily fill an absent position until a long-term replacement can be found.

This structure serves as a top-down and bottom-up conduit of communication. Figure 2-6 depicts the communication and control that an organization provides.

Figure 2-6 Communication and control flow upward and downward in an organization.

Roles and Responsibilities

The topic of roles and responsibilities is multidimensional: it encompasses positions and relationships on the organization chart, it defines specific job titles and duties, and it denotes generic expectations and responsibilities regarding the use and protection of assets.

Individual Roles and Responsibilities

Several roles and responsibilities fall upon all individuals throughout the organization.

Executive management The most senior managers and executives in an organization are responsible for developing the organization’s mission, objectives, and goals, as well as policy. Executives are responsible for enacting security policy, which defines (among other things) the protection of assets.

Owner An owner is an individual (usually but not necessarily a manager) who is the designated owner-steward of an asset. Depending upon the organization’s security policy, an owner may be responsible for the maintenance and integrity of the asset, as well as for deciding who is permitted to access the asset. If the asset is information, the owner may be responsible for determining who may access and make changes to the information.

Manager A manager is, in the general sense, responsible for obtaining policies and procedures and making them available to their staff members. They should also, to some extent, be responsible for their staff members’ behavior.

User Users are individuals (at any level of the organization) who use assets in the performance of their job duties. Each user is responsible for how he or she uses the asset, and does not permit others to access the asset in his or her name. Users are responsible for performing their duties lawfully and for conforming to organization policies.

These generic roles and responsibilities should apply all across the org chart to include every person in the organization.

NOTE The roles and responsibilities of executives, owners, managers, and users should be formally defined in an organization’s security policy.

Job Titles and Job Descriptions

A job title is a label that is assigned to a job description. It denotes a position in the organization that has a given set of responsibilities, and which requires a certain level and focus of education and prior experience.

NOTE The exam may present questions that address proper procedures for the audit of a specified job title. When considering your response, you should consider the job role assigned with the specific title rather than focusing on the title itself. Questions that address job titles are intended to examine understanding of their related roles—an example being the Network Management role associated with the Network Engineer title.

An organization that has a program of career advancement may have a set of career paths or career ladders that are models showing how employees may advance. For each job title, a career path will show the possible avenues of advancement to other job titles, and the experience required to reach those other job titles.

Job titles in IT have matured and are quite consistent across organizations. This consistency helps organizations in several ways:

Recruiting When the organization needs to find someone to fill an open position, the use of standard job titles will help prospective candidates more easily find positions that match their criteria.

Compensation baselining Because of the chronic shortage of talented IT workers, organizations are forced to be more competitive when trying to attract new workers. To remain competitive, many organizations periodically undertake a regional compensation analysis to better understand the levels of compensation paid to IT workers in other organizations. The use of standard job titles makes the task of comparing compensation far easier.

Career advancement When an organization uses job titles that are consistent in the industry, IT workers have a better understanding of the functions of positions within their own organizations and can more easily plan how they can advance.

The remainder of this section includes many IT job titles with a short description (not a full job description by any measure) of the function of that position.

Virtually all organizations also include titles that denote the level of experience, leadership, or span of control in an organization. These titles may include executive vice president, senior vice president, vice president, senior director, director, general manager, senior manager, manager, and supervisor. Larger organizations will use more of these, and possibly additional titles such as district manager, group manager, or area manager.

Executive Management Executive managers are the chief leaders and policy-makers in an organization. They set objectives and work directly with the organization’s most senior management to help make decisions affecting the future strategy of the organization.

CIO (chief information officer) This is the title of the topmost leader in a larger IT organization.

CTO (chief technical officer) This position is usually responsible for an organization’s overall technology strategy. Depending upon the purpose of the organization, this position may be separate from IT.

CSO (chief security officer) This position is responsible for all aspects of security, including information security, physical security, and possibly executive protection (protecting the safety of senior executives).

CISO (chief information security officer) This position is responsible for all aspects of data-related security. This usually includes incident management, disaster recovery, vulnerability management, and compliance.

CPO (chief privacy officer) This position is responsible for the protection and use of personal information. This position is found in organizations that collect and store sensitive information for large numbers of persons.

Software Development Positions in software development are involved in the design, development, and testing of software applications.

Systems architect This position is usually responsible for the overall information systems architecture in the organization. This may or may not include overall data architecture as well as interfaces to external organizations.

Systems analyst A systems analyst is involved with the design of applications, including changes in an application’s original design. This position may develop technical requirements, program design, and software test plans. In cases where organizations license applications developed by other companies, systems analysts design interfaces to other applications.

Software developer, programmer This position develops application software. Depending upon the level of experience, persons in this position may also design programs or applications. In organizations that utilize purchased application software, developers often create custom interfaces, application customizations, and custom reports.

Software tester This position tests changes in programs made by software developers.

Data Management Positions in data management are responsible for developing and implementing database designs and for maintaining databases.

Database architect This position develops logical and physical designs of data models for applications. With sufficient experience, this person may also design an organization’s overall data architecture.

Database administrator (DBA) This position builds and maintains databases designed by the database architect and those databases that are included as a part of purchased applications. The DBA monitors databases, tunes them for performance and efficiency, and troubleshoots problems.

Database analyst This position performs tasks that are junior to the database administrator, carrying out routine data maintenance and monitoring tasks.

Network Management Positions in network management are responsible for designing, building, monitoring, and maintaining voice and data communications networks, including connections to outside business partners and the Internet.

Network architect This position designs data and (increasingly) voice networks and designs changes and upgrades to the network as needed to meet new organization objectives.

Network engineer This position builds and maintains network devices such as routers, switches, firewalls, and gateways.

Network administrator This position performs routine tasks in the network such as making minor configuration changes and monitoring event logs.

Telecom engineer Positions in this role work with telecommunications technologies such as data circuits, phone systems, and voicemail systems.

Systems Management Positions in systems management are responsible for architecture, design, building, and maintenance of servers and operating systems. This may include desktop operating systems as well.

Systems architect This position is responsible for the overall architecture of systems (usually servers), both in terms of the internal architecture of a system, as well as the relationship between systems. This position is usually also responsible for the design of services such as authentication, e-mail, and time synchronization.

Systems engineer This position is responsible for designing, building, and maintaining servers and server operating systems.

Storage engineer This position is responsible for designing, building, and maintaining storage subsystems.

Systems administrator This position is responsible for performing maintenance and configuration operations on systems.

Operations Positions in operations are responsible for day-to-day operational tasks that may include networks, servers, databases, and applications.

Operations manager This position is responsible for overall operations that are carried out by others. Responsibilities will include establishing operations shift schedules.

Operations analyst This position may be responsible for the development of operational procedures; examining the health of networks, systems, and databases; setting and monitoring the operations schedule; and maintaining operations records.

Controls analyst This position is responsible for monitoring batch jobs, data entry work, and other tasks to make sure that they are operating correctly.

Systems operator This position is responsible for monitoring systems and networks, performing backup tasks, running batch jobs, printing reports, and other operational tasks.

Data entry This position is responsible for keying batches of data from hardcopy sources.

Media librarian This position is responsible for maintaining and tracking the use and whereabouts of backup tapes and other media.

Security Operations Positions in security operations are responsible for designing, building, and monitoring security systems and security controls, to ensure the confidentiality, integrity, and availability of information systems.

Security architect This position is responsible for the design of security controls and systems such as authentication, audit logging, intrusion detection systems, intrusion prevention systems, and firewalls.

Security engineer This position is responsible for designing, building, and maintaining security services and systems that are designed by the security architect.

Security analyst This position is responsible for examining logs from firewalls, intrusion detection systems, and audit logs from systems and applications. This position may also be responsible for issuing security advisories to others in IT.

User account management This position is responsible for accepting approved requests for user access management changes and performing the necessary changes at the network, system, database, or application level. Often this position is carried out by personnel in network and systems management functions; only in larger organizations is user account management performed in security or even in a separate user access department.

Security auditor This position is responsible for performing internal audits of IT controls to ensure that they are being operated properly.

Service Desk Positions at the service desk are responsible for providing frontline support services to IT and IT’s customers.

Helpdesk analyst This position is responsible for providing frontline user support services to personnel in the organization.

Technical support analyst This position is responsible for providing technical support services to other IT personnel, and perhaps also to IT customers.

Segregation of Duties

Information systems often process large volumes of information that is sometimes highly valuable or sensitive. Measures need to be taken in IT organizations to ensure that individuals do not possess sufficient privileges to carry out potentially harmful actions on their own. Checks and balances are needed, so that high-value and high-sensitivity activities involve the coordination of two or more authorized individuals. The concept of segregation of duties (SOD), also known as separation of duties, ensures that single individuals do not possess excess privileges that could result in unauthorized activities such as fraud or the manipulation or exposure of sensitive data.

The concept of segregation of duties has been long-established in organization accounting departments where, for instance, separate individuals or groups are responsible for the creation of vendors, the request for payments, and the printing of checks. Since accounting personnel frequently handle checks and currency, the principles and practices of segregation of duties controls in accounting departments are the norm.

IT departments are lagging behind somewhat, since the functions in IT are less-often involved in direct monetary activities (except in certain industries such as banking). But thanks to financial scandals in the 1980s and 1990s that involved the illicit manipulation of financial records, the need for full and formal IT-level segregation of duties is now well recognized.

NOTE At its most basic form, the rule of segregation of duties specifies that no single individual should be permitted or able to perform high-value, high-sensitivity, or high-risk actions. Instead, two or more parties must be required to perform these functions.

Segregation of Duties Controls

Preventive and detective controls should be put into place to manage segregation of duties matters. In most organizations, both the preventive and detective controls will be manual, particularly when it comes to unwanted combinations of access between different applications. However, in some transaction-related situations, controls can be automated, although they may still require intervention by others.

Some examples of segregation of duties controls include

Transaction authorization Information systems can be programmed or configured to require two (or more) persons to approve certain transactions. Many of us see this in retail establishments where a manager is required to approve a large transaction or a refund. In IT applications, transactions meeting certain criteria (for example, exceeding normally accepted limits or conditions) may require a manager’s approval to be able to proceed.

Split custody of high-value assets Assets of high importance or value can be protected using various means of split custody. For example, a password to an encryption key that protects a highly valued asset can be split in two halves, one half assigned to two persons, and the other half assigned to two persons, so that no single individual knows the entire password. Banks do this for central vaults, where a vault combination is split into two or more pieces so that two or more are required to open it.

Workflow Applications that are workflow-enabled can use a second (or third) level of approval before certain high-value or high-sensitivity activities can take place. For example, a workflow application that is used to provision user accounts can include extra management approval steps in requests for administrative privileges.

Periodic reviews IT or internal audit personnel can periodically review user access rights to identify whether any segregation of duties issues exist. The access privileges for each worker can be compared against a segregation of duties control matrix. Table 2-2 shows an example matrix.

When SOD issues are encountered during a segregation of duties review, management will need to decide how to mitigate the matter. The choices for mitigating a SOD issue include

Reduce access privileges Management can reduce individual user privileges so that the conflict no longer exists.

Introduce a new mitigating control If management has determined that the person(s) need to retain privileges that are viewed as a conflict, then new preventive or detective controls need to be introduced that will prevent or detect unwanted activities. Examples of mitigating controls include increased logging to record the actions of personnel, improved exception reporting to identify possible issues, reconciliations of data sets, and external reviews of high-risk controls.

Table 2-2 Example Segregation of Duties Matrix Identifies Forbidden Combinations of Privileges

NOTE An organization should periodically review its SOD matrix, particularly if new roles or high-value applications are added or changed.

Auditing IT Governance

IT governance is more about business processes than it is about technology. This will make audits of IT governance rely more on interviews and documentation reviews than on inspections of information systems. Effective or ineffective IT governance is discernable in interviews of IT personnel as well as of business customers and end users.

NOTE Governance questions on the exam will consider the ISACA’s COBIT strategies as the standard, but will be generic enough in nature to ensure that an understanding of other common IT governance methods will remain applicable to the test-taker. Focus here on the measures and instruments used to validate the governance model.

Problems in IT governance will manifest themselves through a variety of symptoms:

Discontentment among staff or end users Burned-out or overworked IT staff, low IT morale, high turnover, and malaise among end users (about IT-supported systems) can indicate an IT department that lacks maturity and is falling behind on its methodology or is applying Band-Aid fixes to systems.

Poor system performance Excessive incidents of unscheduled downtime, a large backlog of support tasks, and long wait times indicate a lack of attention to the quality of applications.

Nonstandard hardware or software A mix of hardware or software technologies among applications or end-user systems may indicate a lack of technology standards, or the failure to enforce standards that are already in place.

Project dysfunction An IT department suffering from late projects, aborted projects, and budget-busting projects indicates a lack of program and project management discipline.

Highly critical personnel A disproportionate over-reliance on a few IT personnel indicates that responsibilities are not fairly apportioned over the entire IT staff. This may be a result of a lack of training, unqualified personnel, or high turnover.

Reviewing Documentation and Records

The heart of an IT audit is the examination of documentation and records. They tell the story of IT control, planning, and day-to-day operations. When auditing IT governance, the IS (information systems) auditor will need to review many documents:

IT charter, strategy, and planning These documents will indicate management’s commitment to IT strategic planning as a formally required activity. Other documents that should be sought include IT steering committee meeting agendas, minutes, and decision logs.

IT organization chart and job descriptions These documents give an indication of the organization’s level of maturity regarding the classification of employees and their specific responsibilities. An org chart also depicts the hierarchy of management and control. Job description documents describe detailed responsibilities for each position in the IT organization. An IS auditor’s interviews should include some inquiry into the actual skills and experience of IT personnel, to see whether they correspond to their respective job descriptions.

HR/IT employee performance review process The IS auditor should review the process and procedures used for employee performance reviews. In particular, the IS auditor should view actual performance goals and review documents to see how well individual employees’ goals align with IT department objectives. Further, any performance problems identified in performance reviews can be compared with documents that describe the outcomes of key IT projects.

HR promotion policy It will be helpful for the IS auditor to determine whether the organization has a policy (written or not) of promoting from within. In other words, when positions become available, does the organization first look within its ranks for potential candidates, or are new hires typically outsiders? This will influence both employee morale and the overall effectiveness of the IT organization.

HR manuals Documents such as the employee handbook, corporate policies, and HR procedures related to hiring, performance evaluation, and termination should exist, reflect regular management reviews, and reflect practices that meet the organization’s business needs.

Life-cycle processes and procedures Processes such as the software development life cycle and change management should reflect the needs of IT governance. The IS auditor should request records from the software development life cycle (specifically, documents that describe specific changes to IT systems and supporting infrastructure) and change management process to see how changes mandated at the steering group level are carried out.

IT operations procedures IT operations process documents for activities such as service desk, monitoring, and computer and network operations should exist. The IS auditor should request records for these activities to determine whether these processes are active.

IT procurement process An IT organization needs to take a consistent and effective approach to the procurement process. The process should reflect management attention to due diligence, so that any supplier risks are identified and mitigated in the procurement phase and reflected in the service agreement contract. The goods and services provided by suppliers should be required to adhere to the organization’s IT policies, processes, and standards; exceptions should be handled in an exception process. Records should exist that reflect ongoing attention to this process.

Quality management documents An IT organization that is committed to quality and improvement will have documents and records to support this objective.

Like any other facets of an audit, the IS auditor needs to conduct several interviews and walkthroughs to gain a level of confidence that these documents reflect the actual management and operations of an IT organization. These interviews should include staff from all levels of management, as well as key end users who can also attest to IT’s organization and commitment to its governance program and the maturity of its processes.

NOTE The IS auditor should also review the processes related to the regular review and update of IT governance documents. Regular reviews attest to active management involvement in IT governance. The lack of recent reviews might suggest that management began a governance program but has subsequently lost interest in it.

Reviewing Contracts

The IS auditor who is examining IT governance needs to examine the service agreements between the organization and its key IT-related suppliers. Contracts should contain several items:

Service levels Contracts should contain a section on acceptable service levels and the process followed when service interruptions occur. Service outages should include an escalation path so that management can obtain information from appropriate levels of the supplier’s management team.

Quality levels Contracts should contain specifications on the quality of goods or services delivered, as well as remedies when quality standards are not met.

Right to audit Contracts should include a right-to-audit clause that permits the organization to examine the supplier’s premises and records upon reasonable notice.

Third-party audits Contracts should include provisions that require the supplier to undergo appropriate and regular audits. Audit reports from these audits should be available upon request, including remediation plans for any significant findings found in the audit reports.

Conformance to security policies Suppliers should be required to provide goods or services that can meet the organization’s security policies. For instance, if the organization’s security policy requires specific password-quality standards, then the goods or services from suppliers should be able to meet those standards.

Protection and use of sensitive information Contracts should include detailed statements that describe how the organization’s sensitive information will be protected and used. This is primarily relevant in an online, SaaS (Software as a Service), or ASP (application service provider) model where some of the organization’s data will reside on systems or networks that are under the control of a supplier. The contract should include details that describe how the supplier tests its controls to ensure that they are still effective. Third-party audits of these controls may also be warranted, depending upon the sensitivity of the information in question.

Conformance to laws and regulations Contracts should require that the supplier conform to all relevant laws and regulations. This should include laws and regulations that the organization itself is required to conform to; in other words, compliance with laws and regulations should flow to and include suppliers. For example, if a health-care organization is required to comply with HIPAA (Health Insurance Portability and Accountability Act, a U.S. law that requires specific protections of patient health-care information when in electronic form), any suppliers that store or manage the organization’s health-care-related information must be required to also be in compliance with HIPAA regulations.

Incident notification Contracts should contain specific language that describes how incidents are handled and how the organization is notified of incidents. This includes not only service changes and interruptions, but also security incidents. The supplier should be required to notify the organization within a specific period, and also provide periodic updates as needed.

Source code escrow If the supplier is a software organization that uses proprietary software as a means for providing services, the supplier should be required to regularly deposit its software source code into a software escrow. A software escrow firm is a third-party organization that will place software into a vault, and release it to customer organizations in the event of the failure of the supplier’s business.

Liabilities Contracts should clearly state which parties are liable for which actions and activities. They should further specify the remedies taken should any party fail to perform adequately.

Termination terms Contracts should contain reasonable provisions that describe the actions taken if the business relationship is terminated.

NOTE While the IS auditor may not be required to understand the nuances of legal contracts, the auditor should look for these sections in contracts with key suppliers. The IS auditor should also look for other contractual provisions in supplier contracts that are specific to any unique or highly critical needs that are provided by a supplier.

Reviewing Outsourcing

When an auditor is auditing an organization’s key processes and systems, those processes and systems that are outsourced require just as much (if not more) scrutiny than if they were performed by the organization’s own staff using its own assets. However, it may be difficult to audit the services provided by a third-party supplier for several reasons:

Distance The supplier may be located in a remote region, and travel to the supplier’s location may be costly.

Lack of audit contract terms The organization may not have a clause in its contract with the supplier that requires cooperation with auditors. While it may be said that the organization should have negotiated a right-to-audit clause, this point may be moot at the time of the audit.

Lack of cooperation The supplier might not cooperate with the organization’s auditors. Noncooperation takes many forms, including taking excessive time to return inquiries and providing incomplete or inadequate records. An audit report may include one or more findings (nonconformities) related to the lack of cooperation; this may provide sufficient leverage to force the supplier to improve its cooperation, or for the organization to look for a new supplier.

An ideal situation is one where a supplier undergoes regular third-party audits that are relevant to the services provided, and where the supplier makes those audit results available on request.

Summary

IT governance is the top-down management and control of an IT organization. Governance is usually undertaken through a steering committee that consists of executives from throughout the organization. The steering committee is responsible for setting overall strategic direction and policy, ensuring that IT strategy is in alignment with the organization’s strategy and objectives. The wishes of the steering committee are carried out through projects and tasks that steer the IT organization toward strategic objectives. The steering committee can monitor IT progress through a balanced scorecard.

Enterprise architecture provides a meaningful way to depict complex IT environments in functional terms. The Zachman framework is most often used to represent IT architecture in various layers of detail. Similarly, data flow diagrams illustrate the relationship between IT applications.

The IT steering committee is responsible for IT strategic planning. The IT steering committee will develop and approve IT policies, and appoint managers to develop and maintain processes, procedures, and standards, all of which should align with each other and with the organization’s overall strategy.

Security governance is accomplished using the same means as IT governance: it begins with board-level involvement that sets the tone for risk appetite and is carried out through the chief information security officer (CISO), who develops security and privacy policies, as well as strategic security programs including incident management, vulnerability management, and identity and access management.

Risk management is the practice of identifying key assets and the vulnerabilities they may possess and the threats that may harm them if permitted. This is accomplished through a risk assessment that identifies assets, threats, and vulnerabilities in detail, and is followed by specific risk treatment strategies used to mitigate, transfer, avoid, or accept risks. A risk assessment may be qualitative, where threats and risks are labeled on scales such as “high,” “medium,” and “low”; or it may be quantitative, where risks are expressed in financial terms.

Key management practices will help ensure that the IT organization will operate effectively. These practices include personnel management, which encompasses the hiring, development, and evaluation of employees, as well as onboarding and offboarding processes, and development of the employee handbook and other policies. Another key practice area is sourcing, which is the management of determining where and by whom key business processes will be performed; the basic choices are insourced or outsourced, and on-site or off-site. The third key practice area is change management, the formal process whereby changes are applied to IT environments in a way that reduces risk and ensures highest reliability. The next practice area is financial management, a key area, given that IT organizations are cost-intensive and require planning and analysis to guarantee the best use of financial resources. Another practice area is quality management, where processes are carefully measured and managed so that they may be continuously improved over time. The next practice area is security management, which encompasses several activities including risk assessments, incident management, vulnerability management, access and identity management, compliance management, and business continuity and disaster recovery planning.

The IT organization should have a formal management and reporting structure, as well as established roles and responsibilities, and written job descriptions. Roles and responsibilities should address the need for segregation of duties, to ensure that high-value and high-risk tasks must be carried out by two or more persons and recorded.

The IS auditor who is auditing IT governance and risk management needs to examine organization policies, processes, and records that reflect active involvement by steering committees, management, and staff. The IS auditor must determine whether the IT organization is operating in alignment with overall organization objectives and according to the wishes of executive management.

Notes

IT executives and the board of directors are responsible for imposing an IT governance model encompassing IT strategy, information security, and formal enterprise architectural mandates.

Strategic planning is accomplished by the steering committee, addressing the near-term and long-term requirements aligning business objectives and technology strategies.

Policies, procedures, and standards allow validation of business practices against acceptable measures of regulatory compliance, performance, and standard operational guidelines.

Risk management involves the identification of potential risk and the appropriate response for each threat based on impact assessment using qualitative and/or quantitative measures for an enterprisewide risk management strategy.

Assigned IT management roles ensure that resource allocation, enterprise performance, and operational capabilities coordinate with business requirements by validating alignment with standards and procedures for change management and compliance with sourcing, financial, quality, and security controls.

Formal organizational structure ensures alignment between operational roles and responsibilities within the enterprise, where a separation of duties ensures individual accountability and validation of policy alignment between coordinated team members.

Regular audit of the IT governance process ensures alignment with regulatory and business mandates in the evolving enterprise by ensuring all documentation, contracts, and sourcing policies are reviewed and updated to meet changes in the living enterprise.

Questions

1. IT governance is most concerned with:

A. Security policy

B. IT policy

C. IT strategy

D. IT executive compensation

2. One of the advantages of outsourcing is:

A. It permits the organization to focus on core competencies.

B. Reduced costs.

C. Greater control over work performed by the outsourcing agency.

D. Elimination of segregation of duties issues.

3. An external IS auditor has discovered a segregation of duties issue in a high-value process. What is the best action for the auditor to take?

A. Implement a preventive control.

B. Implement a detective control.

C. Implement a compensating control.

D. Document the matter in the audit report.

4. An organization has chosen to open a business office in another country where labor costs are lower and has hired workers to perform business functions there. This organization has:

A. Outsourced the function

B. Outsourced the function offshore

C. Insourced the function on-site

D. Insourced the function at a remote location

5. An organization has discovered that some of its employees have criminal records. What is the best course of action for the organization to take?

A. Terminate the employees with criminal records.

B. Immediately perform background checks, including criminal history, on all existing employees.

C. Immediately perform background checks, including criminal history, on all new employees.

D. Immediately perform background checks on those employees with criminal records.

6. The options for risk treatment are:

A. Risk mitigation, risk reduction, and risk acceptance

B. Risk mitigation, risk reduction, risk transfer, and risk acceptance

C. Risk mitigation, risk avoidance, risk transfer, and risk acceptance

D. Risk mitigation, risk avoidance, risk transfer, and risk conveyance

7. Annualized loss expectancy (ALE) is defined as:

A. Single loss expectancy (SLE) times annualized rate of occurrence (ARO)

B. Exposure factor (EF) times the annualized rate of occurrence (ARO)

C. Single loss expectancy (SLE) times the exposure factor (EF)

D. Asset value (AV) times the single loss expectancy (SLE)

8. A quantitative risk analysis is more difficult to perform because:

A. It is difficult to get accurate figures on the impact of a realized threat.

B. It is difficult to get accurate figures on the frequency of specific threats.

C. It is difficult to get accurate figures on the value of assets.

D. It is difficult to calculate the annualized loss expectancy of a specific threat.

9. An IS auditor is examining the IT standards document for an organization that was last reviewed two years earlier. The best course of action for the IS auditor is:

A. Locate the IT policy document and see how frequently IT standards should be reviewed.

B. Compare the standards with current practices and make a determination of adequacy.

C. Report that IT standards are not being reviewed often enough.

D. Report that IT standards are adequate.

10. The purpose of a balanced scorecard is:

A. To measure the efficiency of an IT organization

B. To evaluate the performance of individual employees

C. To benchmark a process in the organization against peer organizations

D. To measure organizational performance and effectiveness against strategic goals

Answers

1. C. IT governance is the mechanism through which IT strategy is established, controlled, and monitored through the balanced scorecard.

2. A. Outsourcing is an opportunity for the organization to focus on core competencies. When an organization outsources a business function, it no longer needs to be concerned about training employees in that function. Outsourcing does not always reduce costs, because cost reduction is not always the primary purpose for outsourcing in the first place.

3. D. The external auditor can only document the finding in the audit report. An external auditor is not in a position to implement controls.

4. D. An organization that opens a business office in another country and staffs the office with its own employees is not outsourcing, but is insourcing. Outsourcing is the practice of using contract labor, which is clearly not the case in this example. In this case the insourcing is taking place at a remote location.

5. B. An organization that has discovered that some employees have criminal records should have background checks performed on all existing employees, and also begin instituting background checks (which should include criminal history) for all new employees. It is not necessarily required to terminate these employees; the specific criminal offenses may not warrant termination.

6. C. The options for risk treatment are the actions that management will take when a risk has been identified. The options are risk mitigation (where the risk is reduced), risk avoidance (where the activity is discontinued), risk transfer (where the risk is transferred to an insurance company), and risk acceptance (where management agrees to accept the risk as-is).

7. A. Annualized loss expectancy (ALE) is the annual expected loss to an asset. It is calculated as the single loss expectancy (SLE—the financial loss experienced when the loss is realized one time) times the annualized rate of occurrence (ARO—the number of times that the organization expects the loss to occur).

8. B. The most difficult part of a quantitative risk analysis is a determination of the probability that a threat will actually be realized. It is relatively easy to determine the value of an asset and the impact of a threat event.

9. C. IT standards that have not been reviewed for two years are out of date. If the IS auditor finds an IT policy that says that IT standards can be reviewed every two years, then there is a problem with IT policy as well; two years is far too long between reviews of IT standards.

10. D. The balanced scorecard is a tool that is used to quantify the performance of an organization against strategic objectives. The focus of a balanced scorecard is financial, customer, internal processes, and innovation/learning.