Risk Analysis Control & Assessment
Risk Analysis, Control & Assessment
Computer Database Software Risks
Controls Assessment is a risk assessment and risk management method used to identify and evaluate controls to manage
and reduce risk in computer software.
This discussion offers a framework for enumerating and analyzing controls in computer programs so as to reduce business risk.
The controls assessment method will help determine if additional
controls or procedures are warranted based on cost benefit assessment.
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 Assessment (SCA)
should be implemented as a
standard operating procedure risk assessment in your business. The assessment is conducted on a scheduled basis. The
frequency of the SCA will depend on your business as well as the criticality
of the computer program. Typically review cycles range from 1 to 5 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
computers.
We
recommend that you develop preprinted forms (or a database system) to record
all information in the process.
The Assessment Process
An outline
of the key steps in a SCA process follows:
I.
Starting SRA
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 Assessment & Risk Management Steps
II.
Risk Assessment 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 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 an 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.
Process Summary
III.
Summary
Overall the process for program risk assessment is pretty simple:
Catalog application programs
Prioritize order of SCA processing
Identify program outputs
Identify what can go wrong with the outputs
Identify controls that will prevent/detect problems with the output
Evaluate the cost/benefit of implementing the controls
Track control implementation and schedule an SCA review
Additional resources for software risk assessment:
Risk Management in Software Development Projects
