Software Risk Management, Risk Analysis, Control & Assessment

Software risk assessment employing software controls analysis methodology to identify and evaluate software controls used to manage and reduce risk in computer software. This discussion offers a template for enumerating and analyzing controls in computer programs to reduce business risk.  The controls analysis method will help determine if additional controls or procedures are warranted based on a cost/benefit of risk reduction.

Some examples of software which should be considered for risk assessment are:

• Spreadsheet used periodically to analyze data

• Department- or Group-level database such as Microsoft Access

• Financial package such as Quick Books or a custom developed application

• Process-control computer

• Security/fire systems

• Corporate-wide CRM databases

Software Controls Analysis (SCA) should be implemented as a standard operating procedure within your general business risk assessment procedures.  The assessment should be conducted on a scheduled basis.  The frequency of the SCA will depend on your business as well as the criticality of the computer programs.  Typically SCA review cycles range from one to five years.  The reason for the repeated application of the SCA process is that there is nothing more consistent in business than change - especially when it comes to computer software.

We recommend that you develop preprinted forms (or a database system) to record all information in the risk assessment process.

The Risk Assessment Methodology

An outline of the key steps in a SCA process follows.  You may use this information as a risk assessment template.

I.   Starting Software Risk Analysis

1)  Inventory all computer systems.  This inventory would include key attributes of the programs such as:

a)       Purpose

b)       Location

c)       Responsible Person

d)       General importance to the business

i)       High

ii)      Medium

iii)     Low

2)  Prioritize the IT Computer Controls Analyses of the above systems based on the general importance (1d above) of each.

3)  Establish one or more teams to perform the SCAs.  Ideally, the team members should represent several disciplines within the company, such as software, finance, management and system subject-matter specialist.

Software Risk Management Steps

II.   Software Risk Management Steps

1)   Identify system output(s).

2)   For each output determine the events that could happen to the output or information.  Some events to consider are:

a)  Long-term unavailability of output

b)  Intermediate-term unavailability

c)  Short term unavailability - may be seconds or minutes in some cases

d)  Premature dissemination of time-critical information (e.g., web post too early)

e)  Dissemination of output to unauthorized individuals (e.g., classified or sensitive information)

f)  Missing or lost output (e.g., batch run of retirement checks � one check missing)

g)  Errors/miscalculations in output

3)   For each event in 2 above determine the criticality / importance to the business.  The criticality is most often distilled to a dollar amount of loss to the business.  This dollar amount may be derived by considering some of the following results stemming from the events:

a)       Theft/loss of money

b)       Lost lead time for products

c)       Loss of information to a competitor

d)       Incorrect decisions based on erroneous data

e)       Law suit

f)        Fire/Flood, or other preventable disaster

4)   Determine the probability (high, medium, low) of occurrence of each risk event identified in 2 above.

5)  For each event cataloged in 2 above identify one or more possible scenarios that could cause the event to happen.  For a first-time SCA develop these scenarios without regard to any existing controls.  Determine the probability (high, medium, low) of occurrence for each scenario.  It is helpful to discuss how the event could happen when determining the probability.

6)   At this step we determine if further work needs to be done based upon the event-criticality versus the scenario-probability (C/P index).  You may decide that you do not want to pursue further assessment for C/P indexes of Low/Low. If a software system has only a Low/Low C/P index, then the SCA process stops here � time to wrap up the documentation and file it for future review.

7)   For those software systems that have C/P indexes other than Low/Low you will want to complete the SCA.

8)   For each output-event-scenario combination, define controls that might be put into place to prevent the instance.  For first- time SCAs identify controls that already exist and mark them as existing. Types of controls are:

a)    Separation of duties

b)    Internet fire wall installation

c)    Emergency power backup

d)    Fire suppression/flood detection system installation

e)    Password protection/expiration of passwords

f)     Inclusion of software system in company disaster recovery plan

9)    Determine the cost of each new control

10)  Analyze the cost versus the potential loss to determine if implementation of each control is justified.

11)  For those controls to be implemented determine a schedule for implementation.

12)  Last step is to schedule a review of the SCA at some future date.

Software Risk Management Process Summary

III.   Summary

Overall the process for software risk assessment is pretty simple:

1. Catalog application programs

2. Prioritize order of SCA processing

3. Identify program outputs

4. Identify what can go wrong with the outputs

5. Identify controls that will prevent/detect problems with the output

6. Evaluate the cost/benefit of implementing the controls

7. Track control implementation and schedule an SCA review