Skip navigation

Or Doc Computer Audit, January 14, 2005

Download original document:
Brief thumbnail
This text is machine-read, and may contain errors. Check the original document to verify accuracy.
Report No. 2005-04
January 14, 2005

Department of Corrections:
AFAMIS
Application Controls Review

PURPOSE
The Department of Correction’s (department)
Automated
Financial
Accounting
Manufacturing Inventory System (AFAMIS) is
its main financial computer application. The
purpose of this audit was to evaluate the
effectiveness of computer controls governing
AFAMIS, including system development,
security, data integrity, and disaster recovery
and contingency planning.

Secretary of State
Audit Report

Bill Bradbury, Secretary of State

Cathy Pollino, State Auditor, Audits Division

Summary

RESULTS IN BRIEF
Department management did not use generally
accepted controls for system development and
maintenance. In addition, many critical system
development phases and processes were not
adequately performed during the department’s
project to upgrade to the OneWorld XE version
of the system. As a result, the system was in a
general state of disrepair and the department’s
project to upgrade AFAMIS was in jeopardy of
failure. In addition, during our review we
identified approximately $177,000 in contract
payments that were made contrary to state
contracting rules.
Controls to secure AFAMIS programs, data,
and online functions were also insufficient and
ineffective. Access to AFAMIS data and
programs was not properly restricted and the
department’s ability to provide reliable internal
control was limited. As a result, the integrity
and confidentiality of the system was at
significant risk of compromise. Details of
security findings and recommendations were
provided to the department in a confidential
report in accordance with ORS 192.501 (23),
which allows exemption of such information
from public disclosure.
Application controls to ensure integrity of
AFAMIS data files were inadequate. Key data
files used by the department’s AFAMIS
implementation, and which will be utilized by
its OneWorld XE version, were not always
complete, accurate or valid. As a result, the
department is less able to safeguard or manage

1

its financial assets and resources and the
financial information it provides to outside
entities may not accurately reflect its
operations.
The department also had not developed disaster
recovery and contingency plans to restore
AFAMIS or its critical business functions in the
event of a disaster or major disruption.
RECOMMENDATIONS
We recommend that department management:
•

Adopt comprehensive system development
methodologies to govern changes to
AFAMIS and seek guidance from the
Department of Administrative Services to
resolve information technology resource and
expertise issues and explore system
alternatives.

•

Comply with state contracting rules and
consult with the Department of Justice to
resolve identified contract compliance
issues.

•

Take immediate action to implement
recommendations to resolve security issues
included in our confidential report.

•

Develop and implement plans to establish
data integrity for key data files and maintain
that integrity once it has been achieved.

•

Fully develop, test, implement and maintain
disaster recovery and business continuity
plans.

AGENCY’S RESPONSE
Department of Corrections management
generally agrees with the recommendations.

S e c r e t a r y o f S t a t e Audit Report No. 2005-04 • January 14, 2005

Background and
Introduction
The Department of Corrections
(department) was established by the
Oregon Legislature in 1987. Its
mission is to promote public safety
by holding offenders accountable
for their actions and reducing the
risk of future criminal behavior.
The department’s Automated
Financial
Accounting
Manufacturing Inventory System
(AFAMIS) was purchased and
implemented in the early 1990’s
and serves as its main financial
accounting system. During our
audit, AFAMIS had over 700 active
user profiles.
AFAMIS interfaces with the
Statewide Financial Management
Application and the Oregon State
Payroll Application through both
manual and automated processes.
Prior to July 2004, the
department’s Business and Finance
Division was responsible for the
maintenance and operation of
AFAMIS, and the Information
Systems
Services
Division
provided mainframe and network
support.
Subsequently,
the
department’s
newly
formed
General Services Division assumed
responsibility for those functions.
JD Edwards, a national software
company, developed AFAMIS and
the
department
hired
other
consultants to modify the system to
better fit its needs. In 1997, JD
Edwards announced it would no
longer support the World version of
AFAMIS that the department
implemented. As a result, in 2001
the department committed to
convert to the vendor’s OneWorld
XE version of the software.
Another
software
company,
PeopleSoft, purchased JD Edwards
in 2003 and announced it would not
support OneWorld XE after
February 2005.

As of September 2004, the
department had not completed its
conversion to OneWorld XE.

Audit Objectives, Scope
and Methodology
The purpose of our audit was to
evaluate the effectiveness of key
general and application computer
controls for the department’s
AFAMIS application.
Our specific audit objectives were
to
determine
whether
the
department:
Ÿ

Used comprehensive
development
life
methodologies
to
changes to the system.

system
cycle
control

Ÿ Ensured AFAMIS programs,
data, and online functions were
adequately secured.

Ÿ Implemented

application
controls to ensure AFAMIS
data
remained
complete,
accurate and valid during input,
processing and output.

Ÿ Provided disaster recovery and
contingency planning to ensure
AFAMIS could be restored with
minimal business impact after a
disruption.
During our audit we interviewed
various department personnel,
examined documents supporting
controls, and analyzed electronic
data. We also evaluated compliance
with applicable laws, rules and
regulations pertaining to AFAMIS
and our audit objectives. We
performed our fieldwork between
May 2003 and October 2004.
We used the IT Governance
Institute’s
(ITGI)
publication,
“Control
Objectives
for
Information
and
Related
Technology,” (CobiT) to identify
generally accepted and applicable
internal control objectives and
practices for information systems.
We
conducted
our
audit
according to generally accepted
government auditing standards. We

2

also conducted our audit according
to Information Systems Audit and
Control Association standards for
information systems auditing.

Audit Results
System Development and
Maintenance of AFAMIS
Was Unstructured and
Problematic
During our audit the department
was in the process of upgrading its
AFAMIS application to the
vendor’s OneWorld XE version.
Because of that development, we
focused our work on the system
development
processes
the
department used during the upgrade
as well as procedures to maintain
the existing system.
Developing
or
acquiring
information technologies to satisfy
business needs is a necessary but
high-risk activity. To properly
develop, acquire and maintain
computer applications requires
significant resources including
people, applications, facilities and
other technologies. The processes
for managing and controlling these
resources should be part of a
System Development Life Cycle
(SDLC) methodology with defined
phases that address application
development and/or acquisition,
deployment,
maintenance
and
retirement.
Each phase of the SDLC is an
incremental step that lays a
foundation for the next phase.
Following
structured
SDLC
methodologies
reduces
the
likelihood
that
disruptions,
unauthorized alterations, or errors
could be introduced during
development.
In
addition,
following
formal
SDLC
methodologies throughout the life
cycle helps ensure that applications
will continue to satisfy business
needs in the most efficient and
economical manner until they are
formally retired or replaced.

S e c r e t a r y o f S t a t e Audit Report No. 2005-04 • January 14, 2005

The IT Governance Institute has
developed a maturity model for
system development methodologies
based on the Software Engineering
Institute’s Capability Maturity
Model. The Software Engineering
Institute is part of Carnegie Mellon
University. The maturity model
categorizes and describes controls
over the processes of acquiring and
maintaining application software.
Some of the mo del’s critical
success factors include:
Ÿ

Presence of formal, accepted,
understood and enforced system
development and maintenance
methodologies.

Ÿ

Strong senior management
support for system development
and
maintenance
methodologies.

Ÿ

Existence of clear, understood
and
accepted
information
technology
acquisition
practices.

Ÿ

An
approach
and
effort
expended that is proportionate
to the business relevance of the
application.

These critical success factors
were notably absent in the
department’s system development
approach. Department management
indicated that they did not use
formal SDLC methodologies for
system
development
and
maintenance. In addition, most
critical system development phases
and processes were not adequately
performed during the department’s
project to upgrade to the OneWorld
XE version of the system. The
maturity model describes this
approach to system development
and maintenance as “Level 1” or
“Initial/Ad Hoc”.
Department staff also did not
follow a formal project plan, or
provide
adequate
project
management during the OneWorld
XE upgrade project. As a result, the
project proceeded before project
managers determined what tasks
actually needed to be done, the

feasibility of those tasks, how long
they would take to complete, how
much they would cost, or whether
users could effectively use the
system after implementation.
In addition, while reviewing the
OneWorld XE upgrade, we noted
several contract compliance issues.
In one instance, the department
paid approximately $8,000 for
services performed before the
existence of a valid contract, and
approximately
$24,000
for
deliverables already paid for under
“fixed fee” contract provisions. If
those
payments
had
been
appropriate, total contract payments
would have exceeded the contract
“not-to-exceed”
amount
by
approximately $30,000. In addition,
approximately $145,000 was paid
to another contractor for training,
application development and other
services associated with the
upgrade to OneWorld XE without a
valid contract.
The
most
significant
consequences resulting from the
department’s informal approach to
system development was that its
AFAMIS World implementation
had significant security and internal
control weaknesses, data integrity
issues, and notable operational
inefficiencies. In addition, the
department’s project to upgrade
AFAMIS to the OneWorld XE
version was in jeopardy of failure,
with little likelihood of being
completed before February 2005,
when PeopleSoft indicated it would
discontinue
support
of
the
application.
As of March 30, 2004, the
department spent approximately
89 percent of budgeted project
funds or approximately $721,000,
having implemented only two of its
seven modules. One of those
modules was not fully functional
and the other was not being used.
Although these issues were
symptomatic of the department’s
lack of SDLC methodologies and
inadequate project management,
3

many other factors contributed to
the problem. One of the most
significant was the department’s
insufficient
allocation
of
information technology resources
and expertise assigned to AFAMIS
and the upgrade project. External
limitations and forces from its
software vendors also significantly
added to the overall risk and
complicated
the
department’s
decisions.
We recommend that department
management adopt and apply
comprehensive
system
development
life
cycle
methodologies
and
project
management strategies. In addition,
department management should
ensure that the most critical system
development tasks or phases are
successfully completed before
proceeding further with the
OneWorld XE upgrade project.
We also recommend that the
department seek guidance and
expertise from the Information
Resources Management and State
Controller’s Divisions of the
Department of Administrative
Services to resolve information
technology resource and expertise
issues
and
explore
system
alternatives to address pending
issues arising from PeopleSoft’s
decision to discontinue its support
of the OneWorld XE application.
Agency’s Response:
The Department of Corrections
(DOC)
agrees
with
the
recommendation. In an effort to
explore system alternatives, the
department
consulted
with
Solutions Consulting, LLC (a
quality
assurance
contractor)
earlier this year to review the
project, consider options, identify
weaknesses in the project, and
make recommendations to the
DOC. The study confirmed a
number
of
valid
criticisms
regarding DOC’s management of
the project; as a result, the
department is taking a more formal
project management approach.

S e c r e t a r y o f S t a t e Audit Report No. 2005-04 • January 14, 2005

The department has implemented
a
comprehensive
System
Development Life Cycle (SDLC)
methodology and plans to apply
this methodology to all future
information technology projects.
The
department
will
use
information technology resources
and expertise available from the
Department
of
Administrative
Services (DAS), as well as explore
system alternatives through the
completion of a comprehensive
feasibility study.
The department restructured the
project management effort by
developing a "OneWorld Upgrade"
steering committee to oversee the
project. Also, a new project
manager has completed an
integrated project plan.

control allocated according to
“least-access” principles.
Ÿ

Ÿ

Ÿ

Logical
access
control
technologies configured to link
users and resources according
to access rules.
Procedures for managing user
accounts to ensure timely action
relating
to
requesting,
establishing,
issuing,
suspending and closing user
accounts.
Mechanisms to monitor security
activity to enable timely
response to security incidents.

We also recommend that the
department fully comply with state
contracting rules and consult with
the Department of Justice (DOJ) to
resolve
specific
contract
compliance issues identified.

We
concluded
that
the
department’s security framework to
protect its system was inadequate.
Specifically, the department had
not provided adequate controls to
ensure AFAMIS screens and
functions were protected from
unauthorized access, modification
or loss. In addition, access to
AFAMIS data and programs was
not properly restricted at the system
level.

Agency’s Response:
The DOC agrees with the
recommendation and will consult
with the DOJ to resolve the
contract compliance issues stated
within the report.

As a result, the department’s
ability to award access to provide
reliable internal control was limited
and the integrity and confidentiality
of the system was at significant risk
of compromise.

AFAMIS Data and
Programs Were Not
Appropriately Safeguarded

Because of the sensitive nature of
system security, we have issued a
separate report outlining specific
details of our findings as well as
recommendations
to
improve
security. That confidential report
was prepared in accordance with
ORS 192.501 (23), which allows
exemption of such information
from public disclosure.

Executive
management
is
responsible for establishing an
overall approach to security and
internal control to ensure protection
of resources and to maintain
integrity of computer systems.
Key elements that should be
addressed within the security
framework include:
Ÿ

Ÿ

Processes for identifying and
classifying data and assigning
levels of protection accordingly.
Rules for granting user access
to system resources to ensure an
appropriate level of internal

We
recommend that
the
department take immediate action
to implement the recommendations
included in our confidential report.
Agency’s Response:
The DOC agrees
recommendation. The
has taken immediate
implemented some of
and will develop

4

with this
department
action, has
the issues,
plans for

implementing the remainder of the
issues included in the confidential
report.

Application Controls Did
Not Ensure Integrity of Key
AFAMIS Data Files
Application controls may consist
of
manual
or
programmed
processes and include methods for
ensuring that:
Ÿ

Only complete, accurate and
valid data are entered and
updated in a computer system.

Ÿ

Processing accomplishes
correct task.

Ÿ

Processing
expectations.

Ÿ

Data are maintained.

results

the
meet

AFAMIS is a complex financial
accounting
and
management
application using numerous data
files. In order for the system to
function as intended, critical files
must maintain integrity throughout
data input, processing and output.
We
concluded
that
the
department did not employ
adequate application controls to
ensure integrity of its AFAMIS
system. Therefore, key data files
used by the department’s AFAMIS
implementation, and which will be
utilized by its OneWorld XE
version, were not always complete,
accurate or valid.
Specific data file integrity issues
included:
Ÿ

Accounts payable and accounts
receivable sub-ledger totals did
not reconcile to general ledger
totals.

Ÿ

Transactions
were
inconsistently entered into
expenditure
accounts.
We
questioned the validity of
account classifications for 24 of
33 expenditure transactions
tested.

Ÿ

Vendor master files contained
numerous duplicate entries.

S e c r e t a r y o f S t a t e Audit Report No. 2005-04 • January 14, 2005

Ÿ

Budget ledger files contained
invalid user defined codes.

Ÿ

Some transactions that were
entered into the Statewide
Financial
Management
Application (SFMA) were not
entered into AFAMIS.

Ÿ

The file containing purchasing
and
approving
authority
parameters was incomplete.
Specifically, we selected a
sample of 87 expenditures and
found that 50 transactions were
signed by individuals who were
not included in the department’s
authority listing.

Some of the above data integrity
issues occurred because staff was
not always aware of how AFAMIS
worked,
what
automated
application controls were in place,
or how controls functioned. Very
few individuals understood the
system sufficiently to answer even
routine
inquiries
regarding
AFAMIS data or data integrity
issues. In some instances, only one
individual could provide potential
reasons for data abnormalities; in
other instances, no explanation was
offered. In addition, the department
had not developed a functional
chart of accounts to provide
guidance to staff entering data so
transactions would be posted to
appropriate accounts in a consistent
manner. Further, the department
did not appropriately monitor
important files to ensure they were
reconciled
and
differences
resolved.
Because of AFAMIS data
integrity issues, the department is
less able to safeguard or manage its
financial assets and resources. In
addition, the financial information
it provides to outside entities may
not accurately reflect its operations.
For example, during a 2003
financial audit, various expenditure
accounts were deemed unauditable
because of posting errors and
misclassifications.

implement plans to establish data
integrity for key data files and
maintain that integrity once it has
been achieved. In doing so, it
should:
Ÿ

Establish
more
effective
automated and manual error
prevention,
detection
and
correction controls.

Ÿ

Ensure that staff responsible for
AFAMIS has a comprehensive
understanding of accounting
and
information
system
controls.

Ÿ

Develop and implement
functional chart of accounts.

Ÿ

Perform periodic reconciliations
of AFAMIS account balances to
ensure integrity within the
system and to ensure that
balances are accurately posted
to SFMA.

a

Agency’s Response:
The DOC agrees with the
recommendation. It is important to
note, however, that the data
integrity issues are not related to
the
performance
of
the
department’s financial accounting
software, but to the increased
complexity
of
accounting
transactions due to the growth of
the department. To ensure data
integrity, the department has
developed and is implementing the
following plan for key data files:
Ÿ The department’s controller is
monitoring the update to the
chart of accounts to ensure
functionality. An Accountant 2
is currently updating the
expenditures and inventory
accounts in the chart of
accounts.
Ÿ An Accountant 2 has been
reassigned
to
reconcile
AFAMIS to the Statewide
Financial
Management
Application (SFMA) on a
monthly basis to ensure that
balances are accurately posted
to the SFMA.

We recommend that department
management
develop
and

Ÿ An Accountant 1 was hired and
is
scheduled
to
begin
employment
with
the
department in January 2005.
This position is responsible for
reviewing
and
approving
payments prior to input into
AFAMIS to ensure data
integrity.
Ÿ The department will hire an
Accountant 3 with a start date
of February 1, 2005. This
position will be responsible for
reviewing
and
reconciling
certificates of participation and
other funds information entered
into AFAMIS and SFMA.

Disaster Recovery and
Business Continuity
Planning Were Not
Performed
Disaster recovery and business
continuity planning are critical
controls for safeguarding assets and
ensuring the viability of the
department’s information systems
and functions in the event of a
major disruption. Ensuring that
adequate disaster recovery planning
occurs is the responsibility of
senior management.
Important elements in disaster
recovery and business continuity
planning include:
Ÿ

Performing a business impact
analysis to identify time -critical
aspects of critical business
processes.

Ÿ

Identifying
and
selecting
appropriate
recovery
alternatives that meet the
recovery time requirements.

Ÿ

Developing, designing, and
documenting detailed recovery
strategies into written plans.

Ÿ

Periodically testing chosen
recovery strategies, maintaining
the plan and ensuring that key
people are aware and trained in
their responsibilities.

Backup and offsite storage of
critical system files is also a key

5

S e c r e t a r y o f S t a t e Audit Report No. 2005-04 • January 14, 2005

ingredient in recovering an
information
system
after
a
significant event. Although the
department was backing up
AFAMIS programs and files, it had
not developed disaster recovery and
business continuity plans to restore
the
application
or
business
operations in the event of a
disaster.
Because the department performs
a critical public safety mission, an
inability or significant delay in
recovering
its
systems
or
continuing business operations
would pose an unacceptable risk.
We recommend that department
management fully develop, test,
implement and maintain disaster
recovery and business continuity
plans to better ensure timely
recovery of critical systems and
business functions.
Agency’s Response:
The DOC agrees with the
recommendation. The department
initiated a project to complete a
Business and Disaster Recovery
Plan for all business functions and
corresponding automated systems.
The methodology being employed
includes all the elements mentioned
in this report. Major milestones
are:
Ÿ Development of a business
impact analysis, scheduled for
completion January 31, 2005.
Ÿ Identification and selection of
recovery alternatives, scheduled
for completion April 30, 2005.
Ÿ Finalization and documentation
of the business continuity and
disaster recover plan, scheduled
for November 30, 2005.

6

7

Secretary of State
Audits Division
255 Capitol St. NE, Suite 500
Salem, OR 97310

Auditing to Protect the
Public Interest and Improve
Oregon Government

AUDIT M ANAGER:

Neal E. Weatherspoon, CPA, CISA, CISSP

AUDIT STAFF :

Shandi C. Frederickson, CPA
David T. Moon, CPA
Virginia L. Teller, CISA
Ben A. McClelland

DEPUTY STATE AUDITOR: Charles A. Hibner, CPA

The courtesies and cooperation extended by the officials and staff of
the Department of Corrections were commendable and much
appreciated.

This report, a public record, is intended to promote the best possible
management of public resources. Copies may be obtained from our website on
the internet at:
http://www.sos.state.or.us/audits/audithp.htm
by phone at 503-986-2255
or by mail from:
Oregon Audits Division
255 Capitol Street NE, Suite 500
Salem, OR 97310

8