Risk Assessment Reports

---

Risk assessment reports should be drafted in common business language. It is not unusual for several levels of employees to review narratives, accompanying charts, and the work papers. Other report reviewers may include internal and external auditors, bank examiners, legislatures, stockholders, lawyers, law enforcement agents, prosecutors, judges, and possibly juries.

The risk team is drafting a report that many people will review and, depending on their experience, training, and background, might draw conclusions differing significantly from those intended. Use explanatory narratives if necessary for each abbreviation and acronym to avoid misunderstandings.

In Exhibit 8 is a proposed format for the risk assessment team's report. Of course, this example is a model that can be modified to suit your particular circumstances.

Exhibit 8: Risk Assessment Report

To: (Intended audience at the "C" level)

From: (Risk Assessment Team)

Subject: Risk Assessment for XYZ Corporation

• Introduction: Predication of the project, participants, and methodology

• Scope: Detail the scope and purpose of the risk assessment project

• Summary: Include a brief synopsis of the project with particular emphasis on asset criticality and protection strategies

• Details: Narrative describing the risk assessment in detail emphasizing critical assets, threats and their frequency, vulnerabilities, and safeguards with their accompanying effectiveness and cost/benefit

• Disaster Recovery Steps: Describe in substantial detail the necessary steps to disaster recovery and business resumption. A logical organization would be to address recovery steps in terms of business units, critical assets, and their timeline for restoration

• Recommendations: List recommendations, their estimated costs, and a reasonable time for implementation

• Observations: This is the location of any candid or confidential information

• Attachments: Inventory of attached work papers

Simple Risk Management Advice

In many circumstances, risk management exists in business units isolated from one another. Here are some considerations when developing a risk management program:

• In terms of a calendar month, if you are right 95 percent of the time, you are wrong one day per month. So, no matter how confident senior managers might be, rely on the experience of the risk team.

• No senior manager knows it all. Do not fall into the trench of "if I didn't think of it, it isn't any good."

• Do not ignore historical data to predict future events; however, you should include possible catastrophic events in your risk management models.

• Most often a simple spreadsheet will do. Do not fall into the quagmire of overly complex models.

• Integrate all business units and avoid isolating critical business functions.

Just when You Thought You Were Done

After the report is done, and it has been presented and adopted by anxious executive committee members, the teams enjoy a celebratory lunch and you think you are done. No, you are not.

Organizations are not static entities; they have to change to meet daily challenges. As organizations change, so must their critical incident management program. Risk management planning is not a two-month project, and it is definitely not a project that once completed can be filed and forgotten. Depending on the size and structure of the organization; changing legal and regulatory requirements; FUD factors (fear, uncertainty, and doubt), the organization needs to determine when to conduct risk management assessments.

---