NARRATIVE—IT ENVIRONMENT AND CHANGE CONTROL MANAGEMENT PROCESS The IT audit of client ABC Company is for the fiscal year

[answerhappygod]

NARRATIVE—IT ENVIRONMENT AND CHANGE CONTROL MANAGEMENT
PROCESS
The IT audit of client ABC Company is for the fiscal year ended
12/31/2021. In various planning meetings with client/entity
personnel, you gathered the following information pertaining to the
client’s relevant financial applications. These are the
applications that will form the scope of this year’s audit:
The o/s hosting the applications are the ones hosting the
databases. All of the above relevant applications, except for
HR&P, are located in the entity’s headquarters premises,
computer room, first floor, in Melbourne, FL. HR&P is
outsourced, meaning that the application, its database and o/s, as
well as all related servers are located outside the client’s
premises. For description of the processes and procedures regarding
this outsourced application, refer to the auditor’s service
organization report.
During the fiscal year, there were no significant modifications
performed for the Bill-Inv System, Legacy System, Kronos, and
HR&P relevant applications. SAP and APS2, however, were
significantly upgraded to their current versions in March 1st and
November 15th, respectively.
Client ABC Company has three IT-related departments, all
reporting to the IT Director. The IT director reports directly to
the entity’s Chief Financial Officer. The IT departments and their
supporting personnel are listed below:

Narrative It Environment And Change Control Management Process The It Audit Of Client Abc Company Is For The Fiscal Year 1 (163.63 KiB) Viewed 69 times

Purchased Applications (SAP, Bill-Inv System, and APS2) The client's process for selecting and purchasing new applications is conducted taking into consideration the economic and operational impact. Whenever the need for acquiring software is identified, both management personnel and representatives of the end user community (users) establish design requirements and compatibilities for the soon-to-be acquired application. According to the IT Director and the I&O Manager, once a need has been identified and requirements have been established, IT management personnel are responsible for evaluating at least three alternatives considering cost-benefit relationships and the impact to the IT environment. Once evaluated, an alternative is preliminary selected and discussed with business managers to ensure alignment between information systems and business initiatives. Applications exceeding $100,000, and/or having the potential of impacting IT risks are subject to risk assessments and business impact analyses. Upon completion of such analyses, the selected alternative (supported with analysis documentation) is submitted to the Chief Financial Officer for final approval. Once a selection of the application is made, IT personnel perform full backups of the old application. IT personnel then prepare a separate environment for users to start testing whether the new application runs as expected, and whether the data are accurate. They also compare the new application against the old application (i.e., parallel testing). After testing is done, users provide acceptance and support for the installation of the new application in the production environment. IT personnel is then responsible for advising all affected users of the installation dates. The above is part of the entity's policy for selecting and purchasing new applications; however, such policy has not been revised and/or updated during the past 5 years. A policy should be reviewed and updated at least once a year to reflect changes in the entity's processing environment. All changes or upgrades to purchased applications are performed by application vendor personnel and sent back to the entity for installation. Per the ASP&S Manager, changes or upgrades received from the vendors are currently not tracked or logged. The client acknowledges there are available Web-based tools and techniques that can track or log these types of changes, but feel their costs may not be justified. Because these changes or upgrades are from the vendor, the entity trusts that they have been adequately tested (at the vendor site) before the vendor forwards them to the client. Therefore, the entity does not perform full backups of the existing application before the implementation of the changes or upgrades. IT personnel do install the changes/upgrades received in a separate test environment. Tests are performed thoroughly to ensure the new changes are consistent and will conform to current business needs. Test results, if successful, are communicated verbally to the manager in charge. In addition to the IT personnel approval, there are no additional approvals required before implementation of the changes/upgrade into production. IT personnel are responsible for advising all affected users of installation dates in the production environment. The above procedures have been formalized into a policy. The policy is updated annually.

Once implementation of changes or upgrades to purchased applications is performed, IT personnel, led by the ASP&S Manager, perform various tests to validate the integrity, accuracy, and completeness of the information. In-House Developed Applications (Legacy System and Kronos) As discussed with both, I&O Manager and ASP&S Manager, the process of developing in-house applications or implementing changes to in-house applications is a standard and common process. The process may result from (1) users identifying system needs; (2) errors being identified and requiring fix; and/or (3) applications themselves forcing implementation of new patches/upgrades. Requests for developing in-house applications or implementing their changes are submitted by users who complete an online "System Modification Request Form" (SMRF). The SMRF is a Web- based tool the entity uses to track and control requests, and includes information, such as the name of the application or system, requester's name, date, department(s) affected, and a description of the requested change. Additionally, the tool provides information on the programmer who will work with the change and the estimated completion date. Once the SMRF is completed and requirements are established, the ASP&S Manager assesses the impact of the change. If the in-house application or change is deemed significant, it is considered as a project and additional resources are allocated. On the other hand, if the in-house application or change is considered to have a minor impact or maintenance, it is assigned to either the Software Programmer, Analyst Programmer, or SAP Administrator, and performed directly in the production environment. Therefore, there is no evidence like test methodologies, test plans and results, and project implementation schedules, maintained for these types of changes. There is also no separate environment established for developing or testing these “minor impact" in-house application or changes. When determined to be significant, in-house applications or their changes are worked in a development environment separate from production. Full application and data backups are not performed prior to developing the in-house application or implementing the changes. Nonetheless, test procedures are documented, and successful results support final implementation. Testing is performed by selected users from the IT and business area. Test procedures performed consist of recreating normal operation transactions and verifying/monitoring the results for accuracy. Test procedures also validate the integrity and completeness of the information. After testing is done and in order to ensure proper segregation of duties, programmers are not allowed to migrate their own changes into the production environment. Instead, they turn in their work to independent, non-programmer personnel (quality assurance team, for example) for migration into the live environment. Both, the I&O Manager and the ASP&S Manager, indicate that in order to manage and maintain version control, a Software Version Control Configuration Manager (SVCCM) tool is used. This tool allows the identification of changes, labeling them by "revision number," "revision letter," "revision level," or simply just "revision." Change revisions are associated with a timestamp and the name of the user making the change. The SVCCM tool also allows revisions to be compared and restored, as well as combined with other types of files. The above process has not been formally documented in the form of a policy or procedure, nor establishes how it prevents unauthorized changes to the in-house based applications. Additionally, there is currently no version control or management system process used or in place for the entity's purchased applications. The above information was also corroborated with the client's Software Programmer, Analyst Programmer, and the SAP Administrator.

Databases The entity's process for acquiring and implementing databases is similar to the one conducted for purchased applications, according to the IT Director and the I&O Manager. The process for maintaining databases differs. Changes to the databases supporting all relevant applications, except for Legacy System and Kronos, are mostly dependent on application changes and, thus, are subject to the same application maintenance procedures previously described. Both proprietary databases supporting the Legacy System and Kronos applications are administered and maintained by application programmers (i.e., Software Programmer, Analyst Programmer, and the SAP Administrator). Per conversation with these programmers, whenever a report or particular information is needed from any of these databases, programmers access the live databases to submit a job or generate appropriate queries to produce the desired report. The database architecture for SAP, Bill-Inv System, and APS2 is a separate database, accessed by the relevant financial application. On the other hand, the database architecture for the Legacy System and Kronos is integrated or individual database used by the particular relevant application. As discussed with the Database Support Specialist, data dictionaries contain definitions and representations of the data elements stored in the entity's databases. Examples of these would be precise definitions of data elements, integrity constraints, stored procedures, general database structure, and space allocations, among others. Definition of the format of a telephone number field would be an example of one of the uses of a data dictionary. If such format is defined in the data dictionary, the field will be consistent throughout the database even if several different tables hold telephone numbers. Data dictionaries for all purchased applications are only maintained with the purpose of defining data relationships between entities, data/field structures, and to represent data elements. These tasks are used consistently throughout the entity's data dictionaries. Data dictionaries for the in-house applications have been defined within the application code itself. Networks Except for HR&P (outsourced to the ADP service organization), all relevant applications are supported by the local network. As discussed with the Network/LAN Administrator, the network consists of a single domain in which all users are grouped and divided using a hierarchical structure. Client computers and peripherals at the entity are connected through switches to the servers located in the computer room. These servers are protected using two firewalls. A network infrastructure diagram, including the locations that are networked together, the equipment used, the activities that are supported by the networked relevant applications, and the interrelationships within the network is not available. Per the Network/LAN Administrator, whenever configuration changes, upgrades, and/or new network software changes are required (frequently firewall-related changes), these are requested not by regular users, but by IT personnel. Users often do not have the technical background or expertise to define network solution requirements. Network-related change requests are reviewed and approved by the I&O Manager. Once requirements are approved, the needed changes are worked by in-house personnel (typically the Network/LAN Administrator) with support from vendors or external networking consultants, as appropriate. Changes are then tested prior to the implementation into production. Installations of changes are performed during off-peak hours in order to minimize services disruption. The process of requesting, testing, and implementing network changes is done verbally and no documentation is maintained supporting the procedures performed. If documented, this information would be retained to provide insight for the general support of the network, particularly during maintenance activities or if any disruptions occur.

Operating Systems As discussed with the Operating Systems Support Specialist, the process for acquiring o/s is similar to the process followed for applications (refer to above). Procedures in place to implement and maintain (test) the entity's o/s supporting the relevant financial applications follow: UNIX AIX VX (SAP)-Changes or upgrades to UNIX AIX VX are provided by the vendor, IBM. All updates are installed directly into the production environment, because there are no separate environments available to test UNIX AIX VX changes. As a mitigating control, prior to the implementation of UNIX AIX changes or upgrades into production, copy of the existing o/s as well as its application data are backed up, allowing local IT personnel to restore the system to its previous state, should any disruptions in processing occur as a result of the operating system change. OS 400 VX (Bill-Inv System and APS2) - All testing related to changes to OS 400 VX is performed in a separate test environment in order to assess any impact that required changes may have to the o/s itself or to the production environment. Testing also ensures the integrity, accuracy, and completeness of the hosted information. Prior to implementation of the changes, the o/s is backed up, allowing restoration of the system to its previous state, should any disruptions in processing arise from the change. All changes are performed during off-peak hours (normally during weekends), allowing the entity to minimize system downtime. Once tested, changes are implemented into production. Windows VX (Legacy System)-Updates to Windows are installed directly into the production environment because there are no separate environments available. As a mitigating control, updates that are deemed necessary are deployed first into the less critical servers to undergo compatibility testing with existing applications. Documentation supporting test plans and procedures performed as well as results of the tests related to the Windows updates is not kept. Linux VX (Kronos) - Changes or upgrades to Linux are not frequent and are dependent on the application and database it hosts. Whenever changes/upgrades are required, these are provided by the software vendor. Per the Operating Systems Support Specialist, the software vendor performs testing on those changes and provides supporting documentation evidencing results. Testing performed ensures the integrity, accuracy, and completeness of the hosted application information. Upon receipt, changes or upgrades are installed into the Linux o/s's production environment. Application Controls For all relevant applications, default application controls validate for mandatory fields, format type, and size of data input. These application controls also number events and transactions (individually and sequentially) thereby verifying accountability among users. Further, default application controls run warning messages to IT personnel when data processing fails, or when calculations are not performed accurately nor completely. The messages, with description of the failures, are stored in a log file for further review. Standard queries generate daily reports with control totals and statistics for output reviews, and in order to detect exceptions and inconsistencies. These reports are forwarded to responsible individuals or departments for further review and to correct any exceptions noted.

Future Plans In terms of the entity's plans to upgrade or replace existing applications, databases, network, and/or operating systems in the near future, the IT Director along with the I&O Manager and ASP&S Manager, indicate that they will evaluate the possibility of upgrading the current version of the OS/400 VX to a newest version. Update to such current version is expected to take place during the next year. No other plans to upgrade or replace existing systems are set for the immediate future. Finding # Description of Finding Area and/or Application Affected Risk Associated with Finding 1 2 3 4 5 6 7 8 9