Updated On 12/26/2017 2:19:04 AM
Controls Analysis for Computer Software Risk 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:
Microsoft Access is a fully capable database and it's primary limitations is the number of concurrent users it will support. Generally, we recommend a limit of 10 to 15 users.
We create databases large and small. Some of our databases help run entire small businesses. We also handle unique businesses such as flyrod manufacturing, cheese making, marina management, and cable tv inventory.
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
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
recommend that you develop preprinted forms (or a database system) to record
all information in the risk assessment process.
The Risk Assessment Methodology
of the key steps in a SCA process follows. You may use this information as
a risk assessment template.
Starting Software Risk Analysis
computer systems. This inventory would include key attributes of the
programs such as:
importance to the business
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
Software Risk Management Steps
For each output
determine the events that could happen to the output or information.
Some events to consider are:
unavailability of output
c) Short term
unavailability - may be seconds or minutes in some cases
dissemination of time-critical information (e.g., web post too early)
of output to unauthorized individuals (e.g., classified or sensitive
Missing or lost
output (e.g., batch run of retirement checks with one check missing)
Errors/miscalculations in output
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:
Lost lead time
information to a competitor
decisions based on erroneous data
f) Fire/Flood, or
other preventable disaster
probability (high, medium, low) of occurrence of each risk event identified
in 2 above.
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.
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.
those software systems that have C/P indexes other than Low/Low you will want
to complete the SCA.
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:
fire wall installation
suppression/flood detection system installation
protection/expiration of passwords
of software system in company disaster recovery plan
Determine the cost of
each new control
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
Overall the process for software 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