Assesing the Risks

The risk assessment process provides a structured means of evaluating information and applying professional judgment as to the most important areas for audit examination.
A detailed risk assessment is undertaken during the planning phase of the engagement to confirm that the lines of enquiry and the initial objectives have indeed focused on the most important risks associated with the program or activity being audited.
The objective statements for the audit, as outlined in the Risk-based Audit Plan, may need to be amended if the more detailed risk assessment reveals additional risks or assigns higher or lower risk scores to those risks already identified.
The steps involved in performing a detailed risk assessment are:

• Identify the risks associated with the achievement of the auditee's objectives and expected results
• Assess the relative significance of the risks in terms of the likelihood of each risk occurring and the impact should it occur
• Determine on a preliminary basis whether management's assertions on controls are likely to prevent or mitigate the occurrence of the risks of greatest concern and
• Plan to focus audit objectives and scope on testing the existence or adequacy and effectiveness of key controls over areas of greatest risk. Appendix G provides a Template for Documenting Engagement Risk Assessment.

Sources of Information

Some of the key documents and information that the audit manager can use to gain a good understanding include:

• Acts and related legislation or regulations
• Policy, procedures and standards manuals and directives
• Results of previous audits or evaluations by the AES or by the Office of the Auditor General
• Organization charts
• Job descriptions and delegation instruments
• Listings of key personnel
• Process and system maps or flowcharts
• Operational and financial data and reports
• Planning and performance reports (i.e. the INAC Performance Report, the INAC Report on Plans and Priorities)
• Management meeting reports or minutes
• Management control frameworks, e.g. results-based management and accountability frameworks (RMAFs), risk-based audit frameworks (RBAFs)
• Risk assessments
• Management studies or reports

In addition to reviewing documentation and analyzing financial and non-financial performance information, the audit manager may also want to consider visiting sites and observing operations, interviewing management, field staff, central agency representatives or subject matter experts, and reviewing any available internal controls documentation.

Understanding the Audit Entity

The audit manager needs to develop a sound understanding of the program, activity, organization or initiative being audited, including its management practices, business processes, policies and procedures, and external and internal environments.The audit manager needs to be focused on all important aspects of risk management, control, and governance processes for the program, activity, organization or initiative being audited.

Planning Scenario

The planning phase normally consists of three distinct, but often overlapping, activities, i.e. gaining an understanding of the nature of the program, activity, organization or initiative being audited, determining and assessing risks, and determining the most appropriate audit objectives, scope and criteria to be employed.

Holding an Opening Meeting

During an opening meeting, the audit manager should clarify with the auditee the known details of the program, activity or organization to be audited, e.g. mandate, resources, structure, and should explain the auditee's responsibilities in the process. The audit manager can request copies of documents deemed to be important to acquiring a good understanding of the auditee's activities.
If the auditee has any suggestions for the audit objectives or scope, or has raised any concerns that the audit might address, these can be discussed at this time.

Notifying the Auditee

Before any work formally commences on an audit, AES informs the auditee in writing normally via a bilingual e-mail message, with terms of reference attached. The auditee is normally the most senior manager directly responsible or accountable for the program, activity, organization or initiative. In some cases, there may be a shared accountability or an intersection of line and functional authority, e.g. national programs delivered at the regional level. In these cases, more than one auditee will be identified and informed of the audit. The individuals identified in regions as the Audit and Evaluation Coordinators should be copied on the communication.
The initial communication with the auditee is normally drafted by the audit manager and issued by the Director, Audit and Assurance Services. In the event of highly sensitive audit engagements the CAEE may be called upon to issue the announcement. The communication specifies information known at the outset of the engagement such as the initial objectives and scope, any specific considerations or concerns, and the names of the auditors assigned to the audit. The communication could request the scheduling of an opening meeting and the identification of a primary contact to facilitate the coordination of the audit work if an Audit and Evaluation Coordinator has not been identified to do so.
Shortly after the formal communication has been issued, the audit manager or Director should follow-up by telephone, if necessary, to ensure that the auditee has received the notification and taken the appropriate steps to schedule the opening meeting or otherwise facilitate the audit commencement. The audit manager can also address any questions that the auditee may have concerning the audit.

Planning

During the planning portion of the audit, the auditor notifies the client of the audit, discusses the scope and objectives of the examination in a formal meeting with organization management, gathers information on important processes, evaluates existing controls, and plans the remaining audit steps.

Audit Process

Although every audit project is unique, the audit process is similar for most engagements and normally consists of four stages: Planning (sometimes called Survey or Preliminary Review), Fieldwork, Audit Report, and Follow-up Review. Client involvement is critical at each stage of the audit process. As in any special project, an audit results in a certain amount of time being diverted from your department's usual routine. One of the key objectives is to minimize this time and avoid disrupting ongoing activities.

Risk Mitigation Tools

-Tools and processes used to “fortify” your business by developing defenses ahead of time.
Alternate Data Centers
Contracting secondary locations will enable an organization to recover critical technologies if the primary technology infrastructure fails.

Alternate Suppliers
Seeking out and documenting contingency agreements with alternate suppliers for your organization’s critical inputs will allow you to continue normal activities in the event that one of your critical suppliers experiences an interruption or ceases to supply you for any reason.

Backup Power
Securing backup power will enable your core activities to continue as normal with minimal, if any, downtime or loss in productivity.

Change Management Processes
Initiating and controlling organizational, process, technology or resource adjustments with the end objective of ensuring an appropriate level of performance and availability throughout the transition.
Cross-Trained Personnel
Ensuring that multiple staff members can fulfill the duties of each critical job within your organization will remove any personnel single points of failure and enable regular activities to continue even if an employee is absent, unable to work or is no longer employed by the organization.

Data Backup
Replicating data at an alternate location and/or on alternate media will help protect against the loss of the primary data source and also simplify and expedite recovery efforts, thus minimizing downtime.

Fire Protection Systems
Developing working relationships with your local fire department and other first responders, as well as taking fire protective measures of your own (i.e. using fire retardant file cabinets and ensuring that sprinkler systems work properly), will not only help protect personnel, information and facilities, but also minimize the effects of a fire on your core operational activities.

Insurance
Carrying appropriate insurance can help minimize financial complications as a result of major facility or equipment loss, an inability to deliver products or services or if one or more of your employees are injured in an accident

IT Security Measures
Taking appropriate measures to protect hardware, software, data storage, and communications technology will reduce downtime and organization inefficiency (i.e. access controls, mal-ware protections, etc.).

Media Monitoring
Employing a media monitoring process can provide your organization with early warning regarding reputation issues, as well as other threats that could result in a near-term interruption.

Physical Security Controls
Keeping unauthorized persons out of restricted areas will reduce the potential for data loss or business process disruption due to vandalism, theft or other forms of sabotage.

Safety Stock
Storing an appropriate amount of finished product or raw materials in an off-site location will limit the impact of downtime resulting from a loss of the organizations primary storage or production capabilities.

Business case

Central to the notion of risk management is the idea of clearly describing impact. Without a clear and compelling tie to either business or mission consequences, technical risks, software defects, and the like are not often compelling enough on their own to spur action. The risks we focus on in this portal are all tied directly to software and all have clear security ramifications. However, unless these risks are described in terms that business people and decision makers understand, they will not likely be addressed. The ever-increasing integration of business processes and IT systems means that software risks can often be linked to serious and specific impacts on the mission of an organization or business. Since resources are rarely unlimited, mitigation of software risks can and should be prioritized according to the severity of the related business risks.

Hence, software risk management can only be successfully carried out in a business context. Risks are unavoidable and are a necessary part of software development. Management of risks, including the notion of risk aversion and technical tradeoff, is deeply impacted by business motivation. Thus, the first stage of software risk management involves assessing the business situation. Commonly, business goals are neither obvious nor explicitly stated. In some cases, you may even have difficulty expressing these goals clearly and consistently. During this stage, the analyst must extract and describe business goals, priorities, and circumstances in order to understand what kinds of software risks to care about and which business goals are paramount. Business goals include, but are not limited to, increasing revenue, meeting service level agreements, reducing development costs, and generating high return on investment.

The activities of identifying, tracking, storing, measuring, and reporting software risk information cannot be overemphasized. Successful use of the RMF depends on continuous and consistent identification and storage of risk information as it changes over time. A master list of risks should be maintained during all stages of RMF execution and continually revisited. Measurements regarding this master list make excellent reporting information. For example, the number of risks identified in various software artifacts and/or software life-cycle phases can be used to identify problematic areas in software process. Likewise, the number of software risks mitigated over time can be used to show concrete progress as risk mitigation activities unfold. Links to descriptions or measurements of the corresponding business risks mitigated can be used to clearly demonstrate the business value of the software risk mitigation process and the risk management framework.