Electronic Information System (EIS)
October 2007
Table of Contents
Introduction
Audit Objective
Audit Scope
Audit Opinion
Statement of Assurance
Summary of Internal Control Strengths
Summary of Internal Control Weaknesses
Approach & Methodology
Findings and Recommendations
Appendix A: Audit Criteria & Conclusions
Appendix B: Role & Responsibilities of a System Owner
Executive Summary
Introduction
The audit of the Electronic Information System (EIS) is part of the CIHR Risk-Based Annual Internal Audit Plan 2007-08 approved by the CIHR Governing Council.
The Electronic Information System (EIS) is the key information system used by the Canadian Institutes of Health Research (CIHR) staff, primarily within the Research and the Resource Planning and Management Portfolios respectively, to administer grants and awards offered through the agency. The primary input to the EIS is applications for grants and awards, from researchers and students.
The EIS is used for:
- storing, managing, sorting, and reviewing the grants and awards applications;
- identifying, selecting, and managing Peer Review Committee members who assess, rank, and recommend applications for funding;
- awarding and paying grants and awards;
- tracking related files;
- adjusting and monitoring grants and awards (including eligibility verifications and financial monitoring, grants and awards terminations, and transfers between universities and other entities); and
- obtaining statistics on program outputs for management decision-making and for reporting to Parliament and to the health community.
Accordingly, the EIS houses varying levels of personal and organizational information related to the processing of grants and awards, from application to payment, to termination.
Audit Objective
The objective of the audit was to assess the adequacy and effectiveness of internal controls over the confidentiality, integrity, and availability of information processed through CIHR's EIS.
Audit Scope
The scope of the audit encompassed business activities transacted through the EIS and included both automated and manual transactions.
Audit Opinion
The system of internal controls supporting the EIS has moderate issues: a number of control weaknesses was identified, but the overall risk exposure is limited because either the likelihood or impact of the risk is not high. Please see the detailed report for an assessment of each audit criterion.
Statement of Assurance
In my professional judgement as Chief Audit Executive, sufficient and appropriate audit procedures have been conducted and evidence gathered to support the accuracy of the opinion provided in this report. The audit of the EIS was conducted in accordance with the Federal Government Policy on Internal Audit and related professional standards. The audit opinion is based on a comparison of conditions that existed at the time of the audit against established audit criteria that had been agreed upon with management. The evidence that has been gathered is sufficient to provide senior management with the proof of the opinion.
Summary of Internal Control Strengths
CIHR staff were very cooperative with the audit team throughout the audit. We thank them for their help and advice.
The audit team observed several internal controls that were properly designed and were operating effectively:
- Staff involved with the EIS are aware of the need to implement effective internal controls to ensure the confidentiality, integrity, and availability of data;
- CIHR schedules and performs backups of the EIS application and data to support the recovery of the EIS in the event of a disaster;
- CIHR uses change management tools effectively to manage and track changes to the EIS application and support IT infrastructure;
- CIHR has implemented an In-House Application User Group (IHAUG) to ensure that changes to the EIS are aligned with strategic and business plans, and are communicated and coordinated with the user community; and
- CIHR manages applicant paper files well, and makes them available in a timely manner when required.
Summary of Internal Control Weaknesses
As noted above, the EIS has moderate issues, as a number of internal control weaknesses was identified, but the overall risk exposure is limited.
- Controls over the confidentiality of information within the EIS need improvement, specifically:
- Access to application files and the EIS and its data.
- Full compliance with the Government Security Policy and Privacy Impact Assessment Policy.
- Controls over the integrity of information within the EIS need improvement, specifically:
- Consistent and timely processing of applications in accordance with CIHR guidelines.
- Audit trail of control activities such as applicant eligibility assessment performed by Program Coordinators, reviews and sign-offs of EIS reports by staff, and changes to applications or applicant information within the EIS.
- Segregation of duties for reviewing any changes to Committee Recommendations.
- Timely reconciliation and follow-up of potential unspent funds from prior years.
- The governance structure for maintaining and enhancing the EIS needs improvement.
- Controls over the availability of information within the EIS need improvement through the development of a Business Continuity Plan.
Other, lower-risk findings have been issued in a letter to management's attention.
Dev Loyola-Nazareth
Chief Audit Executive
Canadian Institutes of Health Research
Detailed Report
Approach & Methodology
The audit of the EIS was conducted in accordance with the Federal Government Policy on Internal Audit. The principal audit techniques used included:
- Interviews with CIHR management and staff involved with the EIS;
- Reviews of relevant system documentation and its compliance with the Federal Government and CIHR policies, guidelines, and procedures;
- Analysis of the system of automated and manual internal controls within the EIS; and
- Analysis of the system of internal controls within the IT infrastructure supporting the EIS.
The approach used to address the audit objective included the development of audit criteria consistent with the Control Objectives for Information and related Technology (COBIT) from the IT Governance Institute, against which observations were made and conclusions drawn. The audit criteria and related conclusions are included in Appendix A to this report.
Audit fieldwork was conducted between April and July 2007.
Findings and Recommendations
Based on a combination of the evidence gathered through interviews, documentary reviews, and analysis, each of the audit criteria was assessed and a conclusion for each criterion was determined. The EIS was found to have moderate issues1 overall. The audit has identified the following areas where internal controls can be improved.
| Observation | Impact | Recommendation |
|---|---|---|
| Findings and Recommendations related to the confidentiality of information within the EIS | ||
| 1. Controls over access to information need to be improved. | ||
| a. No formal policy and procedures for the approval of EIS access. Although the Software Application Officer (SAO) within Information Technology Management Services (ITMS) and the Application and Dataset Officer within Research Planning and Resourcing (RPR) review requests for access to the EIS, there is currently no process in place to ensure that access to the EIS, to the EIS servers, and to the room housing the EIS servers is formally approved by management before being granted to users. There is also no process in place to review access on a regular basis to ensure that it remains appropriate. It should be noted that, in the absence of a formal policy, access to the server room is managed by the Deputy Chief Information Officer, Software and Infrastructure Management, ITMS, through her approval of a working list of individuals who have been granted access to the room. Moreover, it was noted during testing that many users had access to EIS functionality that was not required to perform their job functions. For example, three individuals other than the Grants and Awards Officers had access to finance modules. |
The absence of clearly defined policies and procedures for approving the appropriateness and extent of access to the EIS increases the risk of unauthorized access to the EIS application, which can compromise the confidentiality and integrity of the underlying data. Without proper management reviews of user access, there is an increased risk that inappropriate user access privileges remain undetected, and that logical and physical security is ineffective. |
We recommend that policies and procedures be developed and implemented to ensure that the extent of access to the EIS is approved by management before being granted to users, and then reviewed on a regular basis to ensure it remains appropriate. This includes performing an analysis of incompatible roles to ensure that, if users have more than one role, the roles do not present a conflict of duties risk. We recommend further that documentation relating to these control activities be retained for audit trail purposes. |
| b. Continued EIS access when it is no longer needed. There is currently no formal process in place to ensure that access to the EIS application, to the EIS servers, and to the room housing the EIS servers is removed for employees whose employment is terminated or who change job responsibilities. It should be noted that, when an employee leaves CIHR, Human Resources requests relevant managers to action the removal of physical and network access; however, the EIS application access is not considered in this process. |
Without timely removal of all access to the EIS, there is an increased risk of unauthorized access, which can compromise the integrity of the underlying data. |
We recommend that policies and procedures be developed and implemented to ensure timely removal of all logical access to the EIS application and servers, and physical access to the room housing the EIS servers, from employees whose employment has been terminated or who have changed job functions. We recommend further that documentation relating to these control activities be retained for audit trail purposes. |
| c. Insufficient EIS password parameters. EIS passwords are set to be the same as the username when the account is created and are not forced to be changed when the user first logs on to the system. In addition, passwords are not required to be complex, do not expire, and can be reused. |
Lack of effective password parameters increases the possibility of unauthorized access to the system. | We recommend that password parameters be strengthened: Password length should be set at a minimum of eight characters (including alpha, numeric, and special characters). Passwords should expire every 60 to 90 days. The password history should be set to prevent reuse of at least 5 previous passwords. |
| d. Use of generic or shared accounts. Several generic or shared accounts (39 out of a total of 343 active user accounts) exist in the EIS and within the network directory. It was noted that these accounts were not locked and that there are no controls in place to monitor the use of these accounts or regularly change the account passwords. |
The absence of separate accounts for each user or administrator results in a loss of accountability and formalized audit trail for each individual user's actions. | We recommend that generic system accounts be locked, where possible, to prevent end user login. Where generic accounts cannot be locked, we recommend that their use be logged and monitored to detect unauthorized use. In addition, we recommend that password controls be implemented to ensure that passwords are reset on a regular basis to mitigate the risk that passwords may be learned or guessed. |
| e. Too much access to application files in transit. ResearchNet, WebForms, and Common CV are systems used by applicants to submit their applications electronically. All CIHR network users have full (read/write/modify/execute) access to the network locations where application files from ResearchNet, WebForms, and Common CV are temporarily stored prior to being imported into the EIS database. It should be noted that the average user would not be expected to know of these locations. |
Unrestricted access increases the risk of unauthorized access to and modification of grants and awards applications. | We recommend that access to the network locations where ResearchNet, WebForms, and Common CV application files are stored be restricted to users who require the access to perform their jobs. |
| 2. Full compliance with Government Policy needs to be given priority. | ||
| Incomplete EIS-related risk management activities. A threat and risk assessment for the EIS has been completed; however, a privacy impact assessment and a certification and accreditation report2 have yet to be completed as required by Government Policy. |
Lack of comprehensive risk management activities increases the possibility that EIS-related risks are not identified and mitigated and that the EIS does not operate in compliance with the Government Security Policy and Privacy Impact Assessment Policy. | We recommend that CIHR conduct a privacy impact assessment and complete a certification and accreditation report for the EIS. |
| Findings and Recommendations related to the integrity of information within the EIS | ||
| 3. Controls over the complete and timely processing of applications need to be fully implemented. | ||
| Inconsistent use of the Application Processing Checklist. During our discussions with CIHR staff, it was noted that some Peer Review Committees (approximately 10 out of 52 Committees) use an Application Processing Checklist in their review of applications to help ensure their completeness and compliance with CIHR guidelines, while other Committees do not. |
The Application Processing Checklist can be an effective control for ensuring the consistent and timely processing of applications in accordance with CIHR guidelines. Without such a control, there is an increased risk that some steps will be overlooked in the processing of applications. | We recommend that all Peer Review Committees use the Application Processing Checklist to support the consistent and timely processing of applications in accordance with CIHR guidelines. |
| 4. An audit trail of control activities is required to demonstrate due diligence. | ||
| a. No evidence of assessment of applicant eligibility. There is currently no evidence within the EIS of the applicant eligibility assessment performed by Program Coordinators. It was also noted that the criteria used to determine eligibility is not specified in the EIS. |
The lack of evidence of the eligibility assessment increases the risk that it may not have been carried out and that ineligible applicants may be considered for funding. The lack of eligibility criteria in the EIS increases the risk that eligibility assessments may not be performed in a consistent manner. | We recommend that evidence of the applicant eligibility assessments and the related criteria be made available in the EIS. This can be achieved by having an "Eligibility Assessment Performed"; box in the EIS, to be checked off by Program Coordinators. Eligibility criteria should also be made available directly in the EIS. |
| b. No evidence of reviews and sign-offs. Evidence of performance of reviews and/or sign-offs for a number of manual control activities could not be found during the audit. Examples include: The review carried out by the Program Delivery Systems (PDS) group, which compares the information inputted into the EIS with the information recorded on the recommendation sheet, to ensure that the information was entered accurately and completely. The review and follow up of reports generated to ensure that there are no duplicate applications for a competition and that any new PIN numbers provided are valid and are not duplicates. PIN numbers are assigned to applicants for access to ResearchNet and WebForms in order to register and to submit applications for funding. Other examples are included in the Management Letter that addresses lower-risk findings. Those examples are related to: the timely communication of funding and related decisions, to applicants; the accurate, complete, and timely transfer of payment information from the EIS to Free Balance; and the accuracy, completeness, and timeliness of EIS reports used for decision-making. In all these cases, staff indicated that the review of the reports is taking place, but the reports are discarded once the review is completed and all issues rectified. |
The lack of evidence of the performance of control activities increases the risk that due diligence activities have not been performed consistently or at all. If the control activities are not carried out, there is an increased risk that errors may go undetected, impacting the integrity of EIS data. | We recommend that evidence of the performance of EIS-related manual control activities be maintained and that the appropriate document be initialed/signed and dated by the person performing the control activity as evidence of completion of the activity. |
| c. Informal process for changes to EIS information prior to Grants and Awards (G&A) stage. There is currently no written request form or documentation required for changes to applications or applicant information within the EIS prior to the G&A stage. This is the stage at which CIHR has committed funds. Only the Program Delivery Systems group within RPR can make the changes. The process, however, is informal in that someone can call or drop by to ask the group to make a change and there is no requirement that such requests be in writing and, consequently, there is no audit trail evidence to support changes. |
Without a written request form for changes to information within the system, there is no way to track which changes have been made, who requested the change, the reason for the change, and whether the change was valid and authorized. This increases the risk of unauthorized changes to information within the system, and/or changes that are not necessary or required. | We recommend that a formal process and related change request form be developed and required for significant changes to information within the system. The request form should capture the proposed change and the date requested, the reason for the change, and the individual requesting the change. These forms should be duly approved by management. Independent reviews of these changes should be made on a sample basis to ensure they are appropriate. The request forms should be retained for audit trail purposes. |
| 5. Segregation of duties needs to be enhanced. | ||
| Lack of independent review of changes to recommendation information. Any changes made to the Committee Recommendation Screen in the EIS prompts the automatic printing of a report of these changes. The changes pertain to the funding recommendations made by the Peer Review Committees. The changes for grants are reviewed by staff within the Research Portfolio. The changes for awards are reviewed by staff in the Research Capacity Development division within the Research Portfolio. However, the same individuals could also be the originators of the changes. |
If individuals who perform reviews of data also have access to make changes to such data, there is an increased risk that inappropriate or incorrect changes will be made to information within the EIS, thereby decreasing the integrity of the information within the system. | We recommend that the changes to the Committee Recommendation Screen be reviewed by a party that did not initiate the change, in order to improve segregation of duties. |
| 6. Potential unspent funds from prior years need to be followed up. | ||
| Backlog in unspent funds reconciliation process. An annual confirmation by institutions and applicants of project expenditures and unspent funds is to be carried out annually according to CIHR guidelines. During the year under audit, the position for the individual responsible for this process had been vacant for approximately eight months. The position has now been staffed; however, there is a backlog of approximately 1 year in the paperwork and reconciliations for the institutions, according to the responses and confirmations obtained. |
The delays in the reconciliation process increase the risk that potential errors with regards to unspent funds owed to CIHR will not be detected in a timely manner. | We recommend that a strategy and plan be implemented to ensure that reconciliations of unspent funds are brought up to date and that any potential unspent funds from prior years are followed up and collected in a timely manner. |
| 7. The governance structure for maintaining and enhancing the EIS needs to be improved. | ||
| Undefined system ownership. There is currently no identified system owner for the EIS. A system owner's responsibilities include approving strategic decisions on the direction of EIS, as well as serving as the accreditation authority for the system. Appendix B describes the typical role and responsibilities of a system owner. |
The lack of an EIS owner increases the risk that the EIS will not have a clear strategic direction, and that risks facing the system are not adequately addressed. | We recommend that a system owner be identified to assume the governance role and responsibility for the EIS. |
| Findings and Recommendations related to the availability of information within the EIS | ||
| 8. Controls over the availability of EIS information need to be improved. | ||
| Lack of a Business Continuity Plan. There is currently no formal Disaster Recovery Plan (DRP) or Business Continuity Plan (BCP) in place to support the timely recovery of the EIS, although the process to develop a formal BCP was initiated in 2005. |
Although CIHR schedules and performs backups of the EIS system and data to support the recovery of the EIS, certain business operations may need to be shut down temporarily or even permanently in the event of a disaster. A comprehensive and complete business continuity plan and, at a more specific level, a disaster recovery plan (DRP) will help to minimize the adverse effects if a disaster does occur. | We recommend that CIHR prioritize the development of a DRP and the completion of a BCP. The BCP should be reviewed and understood by users, as well as updated and tested on a regular basis. |
Other lower-risk findings have been issued in a letter to management's attention.
Appendix A: Audit Criteria & Conclusions
Based on a combination of the evidence gathered through interviews, documentation review, and analysis, each of the audit criteria list below was assessed and a conclusion for each criterion was determined using the following definitions:
| Conclusion on Audit Criteria | Definition of Opinion |
|---|---|
| Well Controlled | Well managed, no material weaknesses noted or only minor improvements are needed. |
| Moderate Issues | Control weaknesses, but exposure is limited because either the likelihood or impact of the risk is not high. |
| Significant Improvements Required | Requires significant improvements in the area of material financial adjustments or control deficiencies represent serious exposure. |
Overall Conclusion
The audit has concluded that the system of internal controls supporting the EIS has moderate issues: a number of control weaknesses was identified, but the overall risk exposure is limited because either the likelihood or impact of the risk is not high.
1. Confidentiality of Information
Adequate and effective internal controls have been established to ensure that EIS information is treated with appropriate confidentiality, in accordance with the Government of Canada's laws, policies, and guidelines.
| # | Criteria | Reference to Observations | Conclusions |
|---|---|---|---|
| 1. | Information security tools and techniques are used to restrict access to information resources (e.g., data files, utilities, transactions, programs). Management reviews and approves the implementation and configuration of information security tools and techniques. | 1.c., 1.d. | Significant Improvements Required |
| 2. | System owners authorize the nature and extent of user access privileges and such privileges are periodically reviewed by system owners to ensure access privileges remain appropriate. User access is controlled through passwords or other mechanisms. Passwords are changed periodically. | 1.a., 1.b., 7. | Significant Improvements Required |
| 3. | Physical access to the building and immediate surroundings of computer equipment is monitored and is restricted to individuals who require such access to perform their job responsibilities. Management approval is required before access is granted. | 1.a., 1.b. | Moderate Issues |
| 4. | System-specific risk management requirements of the Government of Canada's laws, policies, and guidelines have been addressed, including a threat and risk assessment, a privacy impact assessment, and a certification and accreditation report. | 2., 7. | Significant Improvements Required |
| 5. | System Operator-Developer segregation of duties is appropriate and system access is restricted to authorized personnel. | Well Controlled |
2. Integrity of Information
Adequate and effective internal controls have been established to ensure that EIS information is authorized, accurate, and complete.
| # | Criteria | Reference to Observations | Conclusion |
|---|---|---|---|
| 6. | Processing is monitored by management to ensure successful and timely completion, including a review and resolution of any exceptions. | Well Controlled | |
| 7. | Access to production processing control language and executable programs is defined to restrict the ability to execute, modify, delete, or create to appropriate individuals. | 1.e. | Significant Improvements Required |
| 8. | New systems and modifications to systems are tested in accordance with test plans that include, as appropriate, system and unit testing, interface testing, parallel testing, capacity testing, and user acceptance testing. | Well Controlled | |
| 9. | Access to the test and production environments is appropriately restricted. | Well Controlled | |
| 10. | User and other requests for modifications to systems including upgrades and fixes released by vendors are approved by management and implemented if consistent with information systems' plans and management's intentions. | Well Controlled | |
| 11. | New network and communication software and modifications to network and communication software are tested in accordance with test plans that include, as appropriate, system and unit testing, interface testing, parallel testing, capacity testing, and user acceptance testing. | Well Controlled | |
| 12. | User and other requests for modifications to network infrastructure and communications software including upgrades and fixes released by vendors are approved by management and implemented if consistent with information systems' plans and management's intentions. | Well controlled | |
| 13. | All valid registrations are recorded accurately, completely, and on a timely basis. | 4.b. | Moderate Issues |
| 14. | All valid applications are processed accurately, completely, and on a timely basis. | 3., 4.b. | Moderate Issues |
| 15. | Applicants are assessed for eligibility using established criteria which are based on the program's Terms and Conditions. | 4.a. | Moderate Issues |
| 16. | Funding decisions are fair, transparent, and free of bias. | Well Controlled | |
| 17. | Valid decisions by reviewers are recorded accurately and in a timely fashion for all applications. | 4.b. | Moderate Issues |
| 18. | Funding commitments do not exceed available program budget/funds (FAA Section 32). | Well Controlled | |
| 19. | Funding allocations to applicants are appropriately approved (FAA Section 34). | Out of scope (not performed in the EIS) | |
| 20. | Funding and related decisions are communicated to applicants in a timely manner. | 4.b. | Moderate Issues |
| 21. | Payments are generated (in EIS) using awarded amounts and authorized terms and are accurately recorded in the proper period. | Well Controlled | |
| 22. | Payment information is transferred accurately and completely to Free Balance on a timely basis. | 4.b. | Moderate Issues |
| 23. | Changes to agreements or funding levels are justified and implemented using appropriate mechanisms. | Well Controlled | |
| 24. | All unspent amounts are collected and recorded in the correct period. | 6. | Moderate Issues |
| 25. | Agreement closeout procedures are conducted in a timely manner to ensure that agreement responsibilities of both parties have been met. | 6. | Moderate Issues |
| 26. | EIS Reports used for decision making are accurate, complete, and timely. | 4.b. | Moderate Issues |
| 27. | All valid additions/changes to master data files are inputted completely, accurately, and in a timely manner. | 1.a., 4.b., 4.c., 5. | Significant Improvements Required |
| 28. | Segregation of duties is appropriate and system access is restricted to authorized personnel. | 1.a., 5. | Significant Improvements Required |
3. Availability of Information
Adequate and effective internal controls have been established to ensure that EIS information is available to the user when needed for business operations.
| # | Criteria | Reference to Observations | Conclusion |
|---|---|---|---|
| 29. | An enterprise-wide business continuity plan, based on a business impact assessment, has been prepared and approved by management. The plan is regularly tested and updated to reflect the results of such tests. | 8. | Significant Improvements Required |
| 30. | Management and users plan and schedule backup and retention of data, and erasure and release of media when retention is no longer required. Management periodically reviews retention and release records. | Well Controlled | |
| 31. | Automated data retention tools have been implemented to manage the backup and retention data plan and schedule. | Well Controlled |
Appendix B: Role & Responsibilities of a System Owner
Management should ensure that all information assets (data and related systems) have an appointed owner. The business owner of a system is usually the owner of the primary business functions served by the system (i.e., the system's largest stakeholder). In the context of the EIS, an essential role of the business owner is to ensure the EIS supports the current operations and strategic vision of CIHR, and is appropriately available, secure, and sustainable.
Key responsibilities for the business owner as the system owner of the EIS include:
- Ensure the EIS' long and short-term requirements are considered in the formulation of information technology strategies and long and short-term plans;
- Ensure performance standards are established for the EIS;
- Review system performance reports, ensure adequate action is taken upon identification of inefficient performance, and formulate and implement solutions;
- Develop the system's upgrade and enhancements plans to integrate the functionality mandated by business requirements and vendor upgrades into the production system. This includes developing system enhancement and testing procedures;
- Have final approval on enhancements to the EIS and ensure user acceptance testing is completed; Ensure adequate backup and recovery procedures are implemented and there is a tested business continuity plan; and
- Ensure the availability and quality of user training and related materials, and the reliability and preparedness of help desk and other technical support processes and personnel.
The system owner should also be responsible for overseeing the management, control, and review of system security and the maintenance and reviews of data security, reliability, and integrity. To ensure the security of the EIS and its data the system owner should have the final decision on data classification and access rights. This includes determining who should have access and what access privileges are granted. When determining a user's access privileges, the system owner should ensure that segregation of duties is maintained and that job requirements are fulfilled. The system owner should receive lists of users granted access to their information, on a regular basis. Reviews should ordinarily occur on a continuous basis, to ensure that controls and rules are consistently applied and to provide a secure environment on a day-to-day basis.
A system owner typically delegates day-to-day custodianship to a systems administrator and delegates security responsibilities to a security administrator. The system owner, however, remains accountable.
In the role of ensuring the EIS is meeting the programs' and CIHR's requirements, the system owner should be involved in all decisions involving the replacement of the EIS and the development of a new system. In the development of a new system the system owner is accountable to ensure:
- the design meets the system requirements;
- adequate controls, audit trails, security, backup, recovery and restart procedures are included in the design;
- the design and development of the system meet all appropriate business standards; and
- all required user and system documentation for the system is complete and accurate.
The system owner is accountable for formally accepting the new system as complete and ready for production. Although accountability remains with the system owner, responsibility for many of the above requirements may be delegated to information technology personnel within Information Technology Management Services (ITMS).
Management Action Plan
October 2007
| Observation | Recommendation | Action Plan September 28, 2007 | Initial Timeframe |
|---|---|---|---|
| Findings and Recommendations related to the confidentiality of information within the EIS | |||
| 1. Controls over access to information need to be improved. | |||
| a. No formal policy and procedures for the approval of EIS access. Although the Software Application Officer (SAO) within Information Technology Management Services (ITMS) and the Application and Dataset Officer within Research Planning and Resourcing (RPR) review requests for access to the EIS, there is currently no process in place to ensure that access to the EIS, to the EIS servers, and to the room housing the EIS servers is formally approved by management before being granted to users. There is also no process in place to review access on a regular basis to ensure that it remains appropriate. It should be noted that, in the absence of a formal policy, access to the server room is managed by the Deputy Chief Information Officer, Software and Infrastructure Management, ITMS, through her approval of a working list of individuals who have been granted access to the room. Moreover, it was noted during testing that many users had access to EIS functionality that was not required to perform their job functions. For example, three individuals other than the Grants and Awards Officers had access to finance modules. |
We recommend that policies and procedures be developed and implemented to ensure that the extent of access to the EIS is approved by management before being granted to users, and then reviewed on a regular basis to ensure it remains appropriate. This includes performing an analysis of incompatible roles to ensure that, if users have more than one role, the roles do not present a conflict of duties risk. We recommend further that documentation relating to these control activities be retained for audit trail purposes. | Responsibility: ITMS Action: A process should be defined and a procedure written, not a policy, for granting access to the EIS system, EIS servers and the physical access to the server room. ITMS will work closely with other groups within CIHR to define the process and write the procedures for access requests as well as performing the review of user roles. We will also ensure that audit trails of these activities are documented. |
January 2008 |
| b. Continued EIS access when it is no longer needed. There is currently no formal process in place to ensure that access to the EIS application, to the EIS servers, and to the room housing the EIS servers is removed for employees whose employment is terminated or who change job responsibilities. It should be noted that, when an employee leaves CIHR, Human Resources requests relevant managers to action the removal of physical and network access; however, the EIS application access is not considered in this process. |
We recommend that policies and procedures be developed and implemented to ensure timely removal of all logical access to the EIS application and servers, and physical access to the room housing the EIS servers, from employees whose employment has been terminated or who have changed job functions. We recommend further that documentation relating to these control activities be retained for audit trail purposes. | Responsibility: ITMS Action: In conjunction with item 1a, exit procedures will also be documented for staff that is terminating or changing roles within CIHR. We will also ensure that audit trails of these activities are documented. |
January 2008 |
| c. Insufficient EIS password parameters. EIS passwords are set to be the same as the username when the account is created and are not forced to be changed when the user first logs on to the system. In addition, passwords are not required to be complex, do not expire, and can be reused. |
We recommend that password parameters be strengthened: Password length should be set at a minimum of eight characters (including alpha, numeric, and special characters). Passwords should expire every 60 to 90 days. The password history should be set to prevent reuse of at least 5 previous passwords. | Responsibility: ITMS Action: There are numerous ways to secure passwords. We are currently starting a project to upgrade the EIS database to Oracle 10g. Oracle 10g has many more password security features than our current version. We expect this project to be complete by March 2008. At the same time we will be doing an analysis to see which is the best secure password option for CIHR. |
June 2008 |
| d. Use of generic or shared accounts. Several generic or shared accounts (39 out of a total of 343 active user accounts) exist in the EIS and within the network directory. It was noted that these accounts were not locked and that there are no controls in place to monitor the use of these accounts or regularly change the account passwords. |
We recommend that generic system accounts be locked, where possible, to prevent end user login. Where generic accounts cannot be locked, we recommend that their use be logged and monitored to detect unauthorized use. In addition, we recommend that password controls be implemented to ensure that passwords are reset on a regular basis to mitigate the risk that passwords may be learned or guessed. | Responsibility: ITMS/RPR Action: As recommended. | January 2008 |
| e. Too much access to application files in transit. ResearchNet, WebForms, and Common CV are systems used by applicants to submit their applications electronically. All CIHR network users have full (read/write/modify/execute) access to the network locations where application files from ResearchNet, WebForms, and Common CV are temporarily stored prior to being imported into the EIS database. It should be noted that the average user would not be expected to know of these locations. |
We recommend that access to the network locations where ResearchNet, WebForms, and Common CV application files are stored be restricted to users who require the access to perform their jobs. | Responsibility: ITMS Action: As recommended. | November 2007 |
| 2. Full compliance with Government Policy needs to be given priority. | |||
| Incomplete EIS-related risk management activities. A threat and risk assessment for the EIS has been completed; however, a privacy impact assessment and a certification and accreditation report3 have yet to be completed as required by Government Policy. |
We recommend that CIHR conduct a privacy impact assessment and complete a certification and accreditation report for the EIS. | Responsibility: System Owner(s) Action: As stated below, ITMS will start a project to define the System Owner(s). Once identified, we can proceed with a plan for a PIA contingent on funding (est. 20k). Upon completion of the PIA, the EIS can go through the CIHR certification and accreditation process. It is expected to complete the PIA within 60 days from a contract being issued. The Statement of Work is currently in Draft and a Request for Contract will be completed before the end of October 2007. | December 2008 |
| Findings and Recommendations related to the integrity of information within the EIS | |||
| 3. Controls over the complete and timely processing of applications need to be fully implemented. | |||
| Inconsistent use of the Application Processing Checklist. During our discussions with CIHR staff, it was noted that some Peer Review Committees (approximately 10 out of 52 Committees) use an Application Processing Checklist in their review of applications to help ensure their completeness and compliance with CIHR guidelines, while other Committees do not. |
We recommend that all Peer Review Committees use the Application Processing Checklist to support the consistent and timely processing of applications in accordance with CIHR guidelines. | Responsibility: RPR Action: As recommended. |
Align with Standard Operating Procedures (SOP) project led by Research Planning and Resourcing, started in May 2007, and expected to have procedures and an implementation plan written by the end of December 2007.4 |
| 4. An audit trail of control activities is required to demonstrate due diligence. | |||
| a. No evidence of assessment of applicant eligibility. There is currently no evidence within the EIS of the applicant eligibility assessment performed by Program Coordinators. It was also noted that the criteria used to determine eligibility is not specified in the EIS. |
We recommend that evidence of the applicant eligibility assessments and the related criteria be made available in the EIS. This can be achieved by having an "Eligibility Assessment Performed" box in the EIS, to be checked off by Program Coordinators. Eligibility criteria should also be made available directly in the EIS. | Responsibility: RPR Action: The "Eligibility Assessment Performed" box in the EIS has been identified within and is already aligned with the SOP Project implementation plan. The Eligibility Criteria will be developed as part of program planning and analysis. |
Align with Standard Operating Procedures (SOP) project. December 2007 |
| b. No evidence of reviews and sign-offs. Evidence of performance of reviews and/or sign-offs for a number of manual control activities could not be found during the audit. Examples include: The review carried out by the Program Delivery Systems (PDS) group, which compares the information inputted into the EIS with the information recorded on the recommendation sheet, to ensure that the information was entered accurately and completely. The review and follow up of reports generated to ensure that there are no duplicate applications for a competition and that any new PIN numbers provided are valid and are not duplicates. PIN numbers are assigned to applicants for access to ResearchNet and WebForms in order to register and to submit applications for funding. Other examples are included in the Management Letter that addresses lower-risk findings. Those examples are related to: the timely communication of funding and related decisions, to applicants; the accurate, complete, and timely transfer of payment information from the EIS to Free Balance; and the accuracy, completeness, and timeliness of EIS reports used for decision-making. In all these cases, staff indicated that the review of the reports is taking place, but the reports are discarded once the review is completed and all issues rectified. |
We recommend that evidence of the performance of EIS-related manual control activities be maintained and that the appropriate document be initialed/signed and dated by the person performing the control activity as evidence of completion of the activity. | Responsibility: RPR Action: This observation should be reviewed as part of the SOP Project. A procedure for the audit recommendations will be created and communicated to Program Delivery staff in November 2007. This procedure will instruct staff on the review, signoff and evidence filing of the performance of reviews/audits. The revised procedure immediately addresses the issue and can be executed starting with the December 2007 committee meetings. The process can be reviewed again in alignment with the Standard Operating Procedure project. A procedure for the follow-up of duplicate applications and PIN numbers will be created. Evidence of the performance of EIS-related manual control activities will be filed in either a PIN file for PIN numbers or the competition file for applications. The procedure will be created and communicated in November 2007 at which time it can be implemented. |
Align with Standard Operating Procedures (SOP) project. December 2007 |
| c. Informal process for changes to EIS information prior to Grants and Awards (G&A) stage. There is currently no written request form or documentation required for changes to applications or applicant information within the EIS prior to the G&A stage. This is the stage at which CIHR has committed funds. Only the Program Delivery Systems group within RPR can make the changes. The process, however, is informal in that someone can call or drop by to ask the group to make a change and there is no requirement that such requests be in writing and, consequently, there is no audit trail evidence to support changes. |
We recommend that a formal process and related change request form be developed and required for significant changes to information within the system. The request form should capture the proposed change and the date requested, the reason for the change, and the individual requesting the change. These forms should be duly approved by management. Independent reviews of these changes should be made on a sample basis to ensure they are appropriate. The request forms should be retained for audit trail purposes. | Responsibility: RPR Action: This observation should be reviewed as part of the SOP Project. Program Delivery Systems will develop an Application Data Change Request form which requires management's approval (Deputy Director signoff) before being actioned. The form once actioned can be filed in the application file for audit trail purposes. The form will be developed in November 2007 for use starting December 2007. The process can be reviewed again in alignment with the Standard Operating Procedure project. |
Align with Standard Operating Procedures (SOP) project. December 2007 |
| 5. Segregation of duties needs to be enhanced. | |||
| Lack of independent review of changes to recommendation information. Any changes made to the Committee Recommendation Screen in the EIS prompts the automatic printing of a report of these changes. The changes pertain to the funding recommendations made by the Peer Review Committees. The changes for grants are reviewed by staff within the Research Portfolio. The changes for awards are reviewed by staff in the Research Capacity Development division within the Research Portfolio. However, the same individuals could also be the originators of the changes. |
We recommend that the changes to the Committee Recommendation Screen be reviewed by a party that did not initiate the change, in order to improve segregation of duties. | Responsibility: RPR Action: As recommended. The procedure for audit recommendations mentioned above in 4b will address the recommendation to have a party other than the person initiating the change to perform the audit. The revised procedure immediately addresses the issue and can be executed starting the December 2007 committee meetings. The process can be reviewed again in alignment with the Standard Operating Procedure project. |
Align with Standard Operating Procedures (SOP) project. December 2007 |
| 6. Potential unspent funds from prior years need to be followed up. | |||
| Backlog in unspent funds reconciliation process. An annual confirmation by institutions and applicants of project expenditures and unspent funds is to be carried out annually according to CIHR guidelines. During the year under audit, the position for the individual responsible for this process had been vacant for approximately eight months. The position has now been staffed; however, there is a backlog of approximately 1 year in the paperwork and reconciliations for the institutions, according to the responses and confirmations obtained. |
We recommend that a strategy and plan be implemented to ensure thatreconciliations of unspent funds are brought up to date and that any potential unspent funds from prior years are followed up and collected in a timely manner. | Responsibility: Chief Financial Officer Action: An action plan to bring the reconciliations of unspent balances up to date has now been implemented. Significant progress has been made and approximately 97% of the backlog from the previous year has been cleared. We are continuing to follow up on the remainder. Reminders will be sent out to institutions before the end of September 2007 requesting return of unspent funds to CIHR for expired grants. |
December 2007 |
| 7. The governance structure for maintaining and enhancing the EIS needs to be improved. | |||
| Undefined system ownership. There is currently no identified system owner for the EIS. A system owner's responsibilities include approving strategic decisions on the direction of EIS, as well as serving as the accreditation authority for the system. Appendix B describes the typical role and responsibilities of a system owner. |
We recommend that a system owner be identified to assume the governance role and responsibility for the EIS. | Responsibility: EMC Action: The EIS system owner has been identified as the Vice-President, Research. |
Closed. |
| Findings and Recommendations related to the availability of information within the EIS | |||
| 8. Controls over the availability of EIS information need to be improved. | |||
| Lack of a Business Continuity Plan. There is currently no formal Disaster Recovery Plan (DRP) or Business Continuity Plan (BCP) in place to support the timely recovery of the EIS, although the process to develop a formal BCP was initiated in 2005. |
We recommend that CIHR prioritize the development of a DRP and the completion of a BCP. The BCP should be reviewed and understood by users, as well as updated and tested on a regular basis. | Responsibility: ITMS Action: An IT Disaster Recovery Plan will be ready for March 2008. BCP activities will have to be coordinated with the other BCP activities within CIHR. |
IT Disaster Recovery Plan: March 2008 Update of CIHR BCP: October 2008 |
Other lower-risk findings have been issued in a letter to management's attention.
- See Appendix A for a definition of opinions.
- Certification is a comprehensive evaluation of the technical and non-technical security features of an IT system and other related safeguards to establish the extent to which the system meets a specific set of security requirements. Accreditation is the official authorization by management for the operation of an IT system, and acceptance by management of the associated residual risk. Accreditation is based on the certification process as well as other management considerations.
- Certification is a comprehensive evaluation of the technical and non-technical security features of an IT system and other related safeguards to establish the extent to which the system meets a specific set of security requirements. Accreditation is the official authorization by management for the operation of an IT system, and acceptance by management of the associated residual risk. Accreditation is based on the certification process as well as other management considerations.
- The SOP project’s goal is to simplify and standardize CIHR's competition management processes and procedures from application to decision. Objectives are to simplify and standardize internal processes for CIHR funding programs; design standard operating procedures; maximize operational efficiency and use of resources by defining internal standards; and align role profiles with standard operating procedures.
Supplemental content (right column)
- Modified: