The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
Risks
Desired Controls
A.
CONTROL ENVIRONMENT: To ensure project objectives are achieved.
1.
Project scope and
benefits are not clear or
do not meet
organizational needs.



2.
System does not have
the oversight and
support from all of the
necessary sponsors,
management and other
stakeholders.




3.
4.
Necessary tasks or
deliverables are
omitted.
System is not delivered
timely.













5.
Inadequate financial
and/or human
resources.
6.
Stakeholders do not
have information
necessary to make
progress and
decisions.







A project charter outlines the project organizational structure,
objectives, goals and scope of the project.
There is a defined process for keeping the charter up-to-date and, in
particular, evaluating and communicating changes in scope.
The extent and impact of organizational change is evaluated and
addressed throughout the project.
An established organizational structure exists including a steering
committee and a project team, both including operational and IT
personnel.
There is a high-level sponsor who exercises control over the project.
The appropriate level(s) of management are involved in the project –
consider senior and operating management.
Audit, legal, compliance and all other appropriate areas are included,
as needed.
The Board of Directors is involved, as appropriate.
The team has a formal, written project plan.
The project plan includes all of the traditional phases of systems
development (e.g. requirements definition and analysis, design,
construction, testing, training, conversion, implementation and postmortem).
Tasks and deliverables are defined at an adequate level of detail.
The plan requires management/user approval at specified points.
Timeframes have been established with adequate information and
feedback from stakeholders and IT, and appear realistic.
A project baseline is captured to benchmark and manage slippage.
Milestones are determined for key tasks and deliverables.
The critical path is identified.
Go-no go decision points are identified in advance.
There is a defined process for risk identification and mitigation.
Project plan is adhered to, regularly updated and variances are
identified and analyzed for their impact on schedule and budget.
Delays and budget increases are communicated to and approved by
the project team and steering committee.
All relevant parties are notified of the impact delays.
Process exists for identifying and assigning resources.
There is accountability for establishing and approving project budget
and monitoring actual project costs.
Approvals are required for additional budget and staffing.
Defined process is in place for reporting status.
Relevant status is reported to various constituencies including: the
Board of Directors, sponsors, management and other stakeholders.
Status reports include: scope changes, milestone reporting, budget
analysis and action items.
1 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
Risks
Desired Controls
B.
SYSTEM FUNCTIONALITY: To ensure the system meets user needs.
1.
Requirements are not
clearly understood and
documented.


Data architecture is not
well understood.
Necessary data is not
populated in new
system.

2.
C.
1.
2.
All constituencies of users and other stakeholders are identified.
Users are involved throughout the entire project from initial
requirements through implementation.
 Business processes are well understood and documented.
 Requirements are documented, kept up-to-date and validated by
appropriate functional personnel.
 Security and control requirements are defined and tested.
 Desired service levels are determined.
System functionality
 Extensive involvement of users in designing test scripts to ensure all
does not fulfill
scenarios are included.
requirements.
 Formal user acceptance testing (UAT) with sign-off indicating
system meets user needs.
DATA INTEGRITY: To ensure the integrity, completeness and accuracy of master data.




3.
4.
Data validation rules
are not clearly defined
and documented.
Data converted from
another system is not
valid.









5.
6.
Data converted from
another system is
incomplete.
Data converted from
another system is
inaccurate.




Data dictionary, data flow diagrams, entity-relationship overviews
and other relevant information is well documented.
Legacy data is identified and evaluated for conversion.
Historical data needs are addressed.
Various data sources for related data are rationalized to determine
the best approach (e.g., one or the other, only records in two or
more).
A plan exists and responsibility is assigned for the creation of data
which can not be converted from other systems.
Required data is identified.
Data types and valid values are determined.
Interface requirements are evaluated.
Data is "scrubbed" and "cleansed" prior to conversion.
The parameters for data scrubbing are clearly defined and
documented (e.g. eliminating old records, consolidating redundant
data, matching or writing off old outstanding items).
Specific fields are mapped.
Data validation routines are in place during the conversion.
A strategy exists for the treatment of invalid data (accept with error,
reject whole record, reject data elements).
Follow-up and resolution procedures and responsibilities are defined
and documented for data not meeting validation criteria.
Data scrubbing procedures include assessment of completeness.
Balancing routines are used by the conversion programs to verify
record counts and control totals.
Automated integrity checks (e.g., control totals, check sums) are
built into conversion programs.
A QA methodology is defined and documented to verify (on some
sample basis) the accuracy of critical data against source
documents or other reliable sources.
2 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
Risks
Desired Controls
Data manually
populated into new
system is incomplete,
inaccurate or invalid.

1.
In-bound and outbound data does not
meet needs of
interfacing systems.


2.
Data transmitted to and
from other systems is
incompatible or invalid.
7.
8.
D.
Potential sources for data to be input are identified and carefully
evaluated.
 Adequate plans and resources are established for entry and
verification of the data.
 Manual or automated controls exist to check data entry against
validation rules.
 A QA methodology is defined and documented to verify (on some
sample basis) the accuracy of critical data against source
documents or other reliable sources.
Unauthorized or
 Roles and responsibilities for master file maintenance are clearly
erroneous additions,
defined, documented and communicated.
modifications or
 Procedures for requesting, approving and modifying master data are
deletions degrade the
clearly defined, documented and communicated.
integrity of master data.  Master file maintenance duties are adequately segregated between
data stewards/owners, data custodians, database administrators
and super-users.
INTERFACES: To ensure the completeness, accuracy, timeliness and security over data
transmitted between systems.










All interfaces are known and documented.
Interface specification and requirements are defined and
documented, including: specific files/tables, data fields, data
validation rules and time parameters.
All interface specifications and requirements are thoroughly tested.
Front-end hard edits, at the application or database level, are used
wherever possible to ensure valid data.
When soft edits are used, the procedures for addressing those
warnings are defined and documented. The impact of allowing data
to pass to other systems is evaluated.
For each interface, suspense and rejection criteria are defined and
documented.
A cumulative record is maintained of suspended and rejected items.
Operational procedures are defined and documented for monitoring
and resolving suspended and rejected items.
The source system is used to make corrections to suspended and
rejected items.
When a corrected transaction is resent, the original suspense or
reject entry is cleared indicating a successfully transmission, a new
suspense, or reject entry.
Automated balancing procedures account for corrections.
Receiving system re-calculates control totals and has programmatic
controls for comparing totals. Error codes/abends and follow-up
procedures are defined and documented.
3 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
3.
4.
E.
1.
2.
Risks
Desired Controls
Data transmitted to and
from other systems is
inaccurate or
incomplete.


Sensitive data and
transactions are not
properly secured.


Source system records the disposition of a transaction or batch.
Check sums and other integrity checks are in place to ensure
consistency between what is received and sent.
 For batch interfaces, there are adequate balancing procedures to
account for each record: sent, held in suspense, rejected and
processed successfully.
 For on-line interfaces, programmatic controls in both systems are
integrated for sending, evaluating and responding to return codes;
and the corresponding operational procedures are defined.
 Manual reconciliation procedures are in place to detect any
abnormalities.
 Usable audit trails exist between systems.
Data is not transmitted
 Point of failure analysis is performed for interfaces.
to and from other
 Interfaces are monitored for availability.
systems in a timely
 Batch jobs are scheduled according to requirements and monitored
manner.
for success.
 Programmatic and procedural controls exist for follow-up and
resolution of data and transactions not transmitted according to predefined time requirements.
SECURITY: To ensure the confidentiality, integrity and availability of the system and data.
Unauthorized user
gains access to the
system.












Security methodology/approach is defined and documented.
The application's security architecture is evaluated for security risks,
considering all layers of the security environment.
Process exists for data classification.
Risk analysis is performed to identify sensitive transactions.
Security is granted on a minimum required basis (per HIPAA).
Application security supports adequate segregation of duties.
Each user has a unique user IDs (preferably JHED LID).
There is no use of shared / generic / default / guest accounts.
Passwords are adequately complex (6 characters, combination of
alpha lower / upper case, numeric and special characters).
Password changes are forced periodically (e.g., quarterly).
Password history is maintained and re-use is limited by time or
number of passwords.
Account is locked out after 5 unsuccessful attempts, requiring an
administrator to reset.
Application is set to time-out after a reasonable period of inactivity.
Authorized use warning banner is displayed at login (to disclaim that
activity is monitored/logged).
4 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
3.
Risks
Desired Controls
Privileges granted are
excessive or
inappropriate.



4.
Unauthorized use of
the system is not
detected in a timely
manner.







5.
6.
Data can be viewed,
modified or deleted
outside of the
application.
Remote access to the
system is exploited to
gain unauthorized
access to system and
data.








Process exists for defining the security roles within the system.
Formal process exists for granting, modifying or revoking user
access to the system. Approval is required, documented and
maintained
Functional management is responsible for security coordination,
including:
o Identifying the population of user groups,
o Deciphering the permissions/rights required for each user group
to perform their job function,
o Allocating individual users (or job titles) to each group,
o Approving new users, and
o Regularly re-certifying the appropriateness of privileges
User activity (e.g., failed and successful logins) is captured.
Audit trails adequately capture the user, date/time and modification
relative to:
o System and security administrator activity
o Business transactions
All access to PHI (including view-only) is recorded and retrievable.
Tools and processes are in place to isolate system activity which
meets defined criteria (e.g., sensitive transactions, changes to
sensitive data, security changes).
Procedures exist for regularly monitoring audit trails.
Audit logs are maintained according to defined retention periods.
Audit logs are secured from unauthorized use, modification or
deletion.
Restrict users from authentication at the database level to prevent
direct access to data.
Access to all database objects (e.g., tables, views) and special
utilities privileges are restricted to authorized administrators, with
adequately segregated duties.
Strong password controls are implemented at the DBMS level.
All remote access channels are identified and security risks
evaluated, according to the business and system administration
needs.
Encryption is used for all sensitive or confidential messages and
data transmitted across public networks. (consider PHI)
All remote users are authenticated, with unique IDs.
Based on the known remote access requirements, guidelines should
be documented of what remote users and activities are authorized.
All remote access traffic is logged and monitored to detect
suspicious activity.
5 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
7.
Risks
Desired Controls
Application or data is
compromised as a
result of operating
system vulnerabilities.




8.
Application and data is
compromised as a
result of theft or
destruction of physical
IT assets.





Employ an operating system admin, whose job responsibilities
include configuring the system to minimize security vulnerabilities
and monitoring the system for suspicious security events.
Routine process exists for monitoring and installing releases and
patches.
The op sys is "hardened" upon implementation, including:
o Disable all unnecessary services, particularly insecure ones (e.g.,
anonymous ftp, telnet, ftp, etc.)
o Document purposes for needed services particularly insecure
ones
o Set default security features to most restrictive
o Rename admin accounts to ensure they do not identify the
accounts as administrators
o Change default passwords
o Disable guest accounts
o Tightly restrict access to system logs
o Size log files for adequate retention
o Review and restrict default file, directory and other permissions to
appropriate IS personnel
Analysis is performed to determine criteria for suspicious security
activity, which then is logged and monitored.
Routine process exists for performing system vulnerability scanning.
The host, database and application servers, as well as network
controllers, are all physically secured.
Access to sensitive IT processing areas is adequately restricted to
necessary personnel only. Logs of entry and exit are maintained.
Physical security controls include:
o Locked doors,
o Locked cabinets or doors were application servers are housed,
o Card key access and/ or biometric controls,
o Entry codes are changes periodically, and
o Visitors to sensitive areas are signed in and escorted.
Environmental conditions meet equipment specifications including
the use of:
o Electrical supplies, including UPS and emergency power and
conditioning equipment,
o HVAC systems and controls,
o Static control, and
o Fire alarm and suppression systems.
6 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
9.
F.
1.
Risks
Desired Controls
Unauthorized use of
IT resources obtained
by penetration of the
network perimeter and
sub-nets.

Testing is not adequate
to prevent or minimize
unforeseen problems
upon implementation
into production.

A comprehensive risk assessment has been conducted to identify all
potential network vulnerabilities. The level of trust is classified for
interconnected systems.
 There is adequate firewall protection provided at the perimeter, subnet and/or application level.
 Routers are protected by secure authentication and access control.
 Adequate change control procedures are used for modifications to
firewalls, routers and other network controllers.
 Firewall and router configuration file information is encrypted.
 Firewall and router logs are reviewed regularly.
 The wireless network resides on the internal side or trusted side of
an organization’s perimeter firewall, and is adequately secured.
 Policies, procedures and tools are in place for intrusion detection
and incident response.
TESTING: To ensure the system functions as intended in the production environment.




2.
3.
Individual functions, as
well as the complete
processing of business
transactions, within the
application do not
function properly.
Business transactions
are not processed
completely due to
problems with in-bound
or out-bound
interfaces.





There is a documented test strategy and methodology, with project
sponsor sign-off to indicate approval of the nature and extent of
testing, which includes:
o Unit and functional testing,
o Integration and system testing,
o Stress and volume testing,
o Regression testing,
o User acceptance testing (UAT), and
o Parallel testing to compare system results with legacy systems,
where applicable.
Standard tools are in place for documenting expected results prior to
actual testing.
Test scenarios and test data are representative of production and of
the areas of risk identified throughout the implementation.
The population of test scenarios and test data is validated by
thorough reviews from users and other stakeholders.
An appropriate level of supervision should be carried out (e.g. by
senior staff approving test plans and reviewing test results).
A unit testing master plan includes all functions (including: modules,
menus, data entry forms, batch processes, reports, etc.) to be used.
System tests are executed to evaluate the system behaviors for the
entirety of business transactions.
Unit and system testing addresses documented user requirements.
All interfaces are unit tested.
A complete integration test is carefully designed and executed to
evaluate the flow of transactions and data between systems.
7 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
4.
5.
6.
G.
1.
Risks
Desired Controls
Problems detected
during testing and retested are not
appropriately
addressed.

Training plan is not
adequate to ensure all
users are adequately
trained prior to go-live.


Procedures are defined for monitoring and documenting actual test
results and comparing them to expected results.
 Standard tools and procedures are in place for recording, prioritizing,
escalating, tracking and reporting on discrepancies, problems and
issues encountered during various phases of testing.
 Procedures are defined for making additional changes to address
problems and re-testing, until results are satisfactory, when
unexpected results arise.
Users are not satisfied
 Users, representing all constituencies, perform UAT to verify the
with the functionality of
system functionality meets their requirements and the integrity of
the system.
transactions and outputs.
 There is formal sign-off of UAT to indicate the system satisfies user
requirements.
Users are not satisfied
 A QA environment, which mirrors production as closely as possible,
with the performance of
is used for final integration, UAT and parallel tests.
the system.
 Automated tools are employed to support stress/volume/load testing
of the system.
 Target service levels are established and documented to support the
construction and testing of the system.
TRAINING AND DOCUMENTATION: To ensure that appropriate personnel are equipped to
design, construct, test, implement, support and use the system.






2.
Training materials are
not adequate.

The training plan is documented and approved.
The training plan outlines specific needs for all end users and
technical personnel.
The training timeframe correspond with the “go live” date to ensure
all users are trained timely; prior to go-live but not too early to
prevent skill degradation.
All personnel requiring training have been identified and catalogued
in a master plan for enrollment and tracking purposes.
The training environment simulates production and contains realistic
mock data.
Appropriate personnel are designated as subject matter experts.
Subject matter experts are thoroughly trained and will deliver training
to end users (e.g., Train the Trainer approach).
The effectiveness of the training program and learning experiences
are evaluated and assessed.
The training materials include the following as a minimum:
o Instructor guides - printed, step-by-step guide describing
relevant business processes and demonstration of system
transactions.
o Classroom exercises - procedures that instruct the student to
enter specific field data and navigation commands.
o Applied exercises - “real world” scenarios and supporting data,
which are completed by users to ensure that they understand
how to use the system in realistic work environments.
o Error message explanation – identifies various error messages
and describes how to interpret them.
8 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
3.
4.
5.
6.
7.
Risks
Desired Controls
System personnel
(including, but not
limited to: Developers,
Operations, Production
Support, Help Desk,
Security) do not have
the requisite skills and
knowledge to perform
their job.
Functional/operational
personnel do not have
adequate
understanding of the
system to effectively
define functional
requirements and
perform testing.
Vendor supplied
documentation is too
generic.
Technical
documentation is not
sufficient to support ongoing troubleshooting
and maintenance.


Users are not proficient
in using the system.



All users are trained prior to go-live and are proficient in:
o Navigating through the system,
o Using various input screens,
o Producing various output records,
o Identifying and interpreting different error messages, and
o Using the help function.

Customized documentation is developed to reflect unique business
processes and workflows.

Technical documentation is created to sufficiently support application
and database maintenance.
Documentation adequately:
o Outlines the hardware, software and operating system,
o Details the programs in the program library, and
o Lists all documentation in the repository and database.
Users have been properly identified and organized into functional
groups that have a specific set of knowledge and expertise in using
the system.
Current communication channels are identified to deliver and receive
information most effectively.
A communication plan exists to motivate and prepare each individual
to be trained for his or her role in the future environment.
User manuals have been prepared and will be revised for
subsequent changes.
Operations support and help desk procedures have been
documented and include:
o Contact lists,
o Troubleshooting tips and techniques,
o FAQ, and
o Procedures to be used to identify, report, escalate, and solve
problems.




8.
Changes in operational
procedures and
workflows are not
defined, documented
and communicated.
Technical personnel requiring training have been identified.
Technical personnel and their job functions have been inventoried to
identify training needs and schedule courses.
Super users have been identified.

9 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
Risks
Desired Controls
H.
ACTIVATION (GO-LIVE) AND BACKOUT PLANNING: To minimize problems and disruptions
during implementation.
1.
Contingency plans are
not adequate to
address unforeseen
problems during
implementation.







2.
3.
4.
5.
I.
1.
Human resources are
inadequate,
unreachable or
unavailable to support
go-live.
Other resources, such
as facilities and
equipment, are
inadequate or
unavailable for go-live.
Problem management
procedures, including
escalation, are not
clearly defined,
documented and
communicated.










A back-out or contingency plan exists to handle any issues that may
be encountered during go-live.
Go-live procedures have been documented and disseminated.
An issue tracking mechanism is in use.
Cutover plans have been communicated to appropriate individuals.
Technical restoration needs and alternative end-user processing
procedures have been addressed.
Unrecoverable components of the legacy system have been backed
up in case of installation failure.
Procedures for proper legacy system shut-down/sun-setting have
been documented.
The cut-over plan has been communicated to the entire
implementation team.
The go-live has been adequately staffed to support responsibilities
outlined in the cutover plan including super users, help desk,
technical, and operations personnel).
Job assignments and locations have been clearly defined.
Critical resources have been considered in the go-live plan.
Communication hardware, cabling, and software have been properly
configured.
Special supplies and equipment such as forms, printers, and
workstations have been obtained prior to Go-Live.
The individual(s) with the authority to declare a back-out has been
identified.
Back-out procedures have been clearly documented for multiple
scenarios.
Develop a corrective action plan for all problems encountered.
Time frames have been established for reverting to the legacy
system after cutover in the event of a failure of the new system.
Critical resources have been identified.
Back-out criteria have been defined and are based on critical factors
that would cause concern with continuing the implementation plan.
Contingency and back- 
out plans are not

defined to address
known potential and
unforeseen problems
during implementation.
BACKUP, RECOVERY AND DISASTER RECOVERY: To minimize the loss of data and the
duration of system outages to an acceptable level.
Impact assessment
and recovery objectives
are not defined and
documented.






A methodology exists for application assessment.
Service levels are defined and documented.
Recovery time objectives are determined based on the tolerance
level for duration of outage.
Recovery point objectives are determined based on the point in time
and/or point in business cycle to which to recover.
Requirements and assessment address data retention, as well as
tolerance levels for loss of data.
Dependencies are identified and incorporated in recovery plans.
10 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
2.
3.
J.
1.
2.
Risks
Desired Controls
Hardware, system
software, application
programs and/or data
are not available for
recovery.

Concurrent
development
overwrites changes
made by others.

Change management
process is not clearly
defined and
documented.

Regularly scheduled, automated full backups are captures and
retained according to established retention periods.
 Incremental or differential backups are scheduled and automated at
appropriate intervals.
 Automated notifications are generated for backup problems and
addressing labeling procedures.
 Based on assessment, backups may be retained on-site to ensure
timely operational recovery.
 Backups are rotated off-site to ensure availability in the event of a
disaster at the primary location.
 Frequency of off-site rotation is adequate, according to assessment
and tolerance levels.
Excessive delays or
 Disaster declaration and escalation procedures are defined and
inability to recover
documented.
system and data.
 There is a documented disaster recovery plan for the application.
 The DR plan is stored offsite.
 The DR plans are periodically tested.
 Test results are documented and evaluated.
 DR plans are regularly updated based on the results of testing and
changes to the application.
 Inventories, configurations and specifications of the system are
documented, kept up-to-date and rotated off-site.
 The DR plan addresses all components of the application – technical
infrastructure, system software, application programs and data.
 There are alternate processing locations and strategies (e.g., hotsite, quick ship, etc.) for all components of the environment.
 The DR plan includes up-to-date contact information.
 There are documented operational downtime procedures for the
duration of system outages.
CHANGE AND CONFIGURATION MANAGEMENT: To ensure the integrity of programs and
changes and to prevent adverse events resulting from changes.



Check-out mechanism locks programs from being modified by other
developers.
Adequate library management and versioning tools are in place to
enable: synchronization of various components, source to load
correspondence, delta analysis and audit trails.
A change management policy and procedures are documented and
communicated to all affected parties (e.g., IT, users).
There is a clear definition of the scope of the policy and procedures,
including exclusions for changes not subject to adherence (e.g., data
updates).
Exclusions/exceptions to compliance with the change management
policy or procedures are evaluated for risk and compensating
controls.
11 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
3.
Risks
Desired Controls
Change requests are
not properly initiated,
tracked and approved.





4.
Inadequate
coordination of all
aspects of the change.



5.
Changes are not
adequately tested.
6.
Unauthorized changes
are made to previously
tested and approved
changes.
7.
Unauthorized or
inappropriate programs
(or changes) are
implemented into
production, bypassing
the defined process.












8.
9.
The integrity of
production programs is
not maintained.
Inability to back-out a
change or revert to a
prior version.







All changes are tracked throughout their lifecycle.
Priorities are assigned to determine how resources are allocated
between all user enhancement requests, production problems,
technical infrastructure changes, etc.
Users participate in the prioritization process.
There is evidence of Management approval of each request and
assignment of resources to initiate work on each change.
Aging reports are run and evaluated to identify outstanding change
requests.
User communities are involved throughout the change's lifecycle.
Various components of the same changes are coordinated. This
could include (as applicable): bundling in a release, crossreferencing changes to one another, scheduling changes based on
dependencies, etc.
Adequate communication exists with other applications or
infrastructure groups.
Testing procedures and documentation are commensurate with the
nature and risk of the change.
See section E.
Access to the QA environment is adequately restricted to authorized
QA personnel. Developers do not have access to QA.
Changes are promoted from development rather than made in the
QA environment.
On-going regression testing is performed in the QA environment.
Policy requires management approval which indicates adequate
testing, documentation, user involvement and coordination.
Policy requires an independent approval which indicates readiness
by all affected parties.
There are separate logical environments for development, testing,
QA, training and production.
There is segregation of duties between development, QA and
production access.
Access to the production environment is restricted to authorized
production support personnel.
Developers do not have access to production.
Changes are not made directly into production, but rather promoted
from QA.
Access to the production environment is restricted to authorized
production support personnel.
Developers do not have access to production.
Changes are not made directly into production, but rather promoted
from QA.
The correspondence from source to load is verifiable.
Integrity checking tools and procedures are in place.
A back-out and reversion plan is documented with specific
procedures, including escalation and communication.
Procedures for change implementation include creation and/or
verification of successful backup.
12 of 13
The Johns Hopkins Institutions
Office of Hopkins Internal Audits
New System Implementation – Control Matrix
Control Objective
Risks
Desired Controls
K.
SYSTEM MANAGEMENT: To ensure adequate performance and availability of the system
and minimize delays or disruptions to processing.
1.
Proactive measures
are inadequate to
prevent deteriorating
performance and
system outages.






2.
System problems are
not detected in a timely
manner.



3.
Problems are not
recorded, tracked and
resolved in a timely
manner.





Periodic preventative maintenance is scheduled and performed in
accordance with vendor specifications and minimizes the impact on
operations.
System is reviewed for known vulnerabilities and software patches
promptly installed.
Response time and service level targets are defined and
documented and actual data is collected and evaluated.
The relevant thresholds, conditions and parameters (e.g., memory,
processing speed, disk capacity, dialog processes, database size)
are established for monitoring.
Monitoring procedures are in place for system performance and
resource utilization to identify performance bottlenecks.
Automated and manual alert, escalation and troubleshooting
procedures are in place when defined conditions are met.
Historical problem reports are reviewed for relationships and trends.
Operations has adequate automated tools to monitor for problems
and documented procedures for recording, investigating, and
resolving or escalating problems.
Operations' responsibilities and procedures address (as applicable):
job monitoring, tape mounting, media integrity and availability, and
output production and distribution.
Users have clear procedures for reporting the problems they detect.
A Help Desk function exists to intermediate between end users and
problem management personnel.
All problems get recorded in a central repository for tracking and
reporting, which includes key data such as: description of the
problem, affected users, work on the problem, opened/closed and
elapsed time for resolution.
Criticality levels are assigned for problems to dictate priority.
There are clearly defined escalation procedures for application,
system software, hardware and network problems; which the Help
Desk cannot address.
13 of 13