Information Security Risk Assessment Guidelines

Introduction and Overview

Information security risk assessment is an on-going process of discovering, correcting and preventing security problems.  The risk assessment is an integral part of a risk management process designed to provide appropriate levels of security for information systems. Information security risk assessments are part of sound security practices and are required by the Commonwealth Enterprise Information Security Policy. Risk assessments and related documentation are also an integral part of compliance with HIPAA security standards (see below).

The risk assessment will help each agency determine the acceptable level of risk and the resulting security requirements for each system. The agency must then devise, implement and monitor a set of security measures to address the level of identified risk.  For a new system the risk assessment is typically conducted at the beginning of the System Development Life Cycle (SDLC). For an existing system, risk assessments may be conducted on a regular basis throughout the SDLC and/or on an ad-hoc basis in response to specific events such as when major modifications are made to the system’s environment or in response to a security incident or audit.

This risk assessment methodology is based on the CMS Information Security RA Methodology, developed by the federal Department of Health and Human Services, Centers for Medicare and Medicaid Services (CMS), which is available at www.cms.hhs.gov/it/security/docs/RA_meth.pdf.  It is presented in three phases:

• System Documentation Phase
• Risk Determination Phase
• Safeguard Determination Phase

The risk assessment report:

• Summarizes the system architecture and components, and its overall level of security;
• Includes a list of threats and vulnerabilities, the system’s current security controls, and its risk levels; 
• Recommends safeguards, and describes the expected level of risk that would remain if these safeguards were put in place;
• Shows where an organization needs to concentrate its remedial work;
• Can be used as input to the agency’s business continuity plan;
• Presents these findings to management.

Note on HIPAA Security

Commonwealth agencies defined as Covered Entities (CE’s), and those who are Business Associates of CE’s, must comply with the HIPAA security rule, 45 CFR parts 160, 162 and 164.  The HIPAA security framework calls for due diligence based on good business practices, for systems handling electronic protected health information (EPHI).  Creating an Information Risk Assessment Report satisfies the Rule’s requirements to analyze risks, formulate appropriate safeguards, and document the risk management decision-making process (45 CFR part 164.308(a)(1)(ii)(A)(B)) and informs the agency’s actions in complying with other parts of the rule. 

Team Members

A sample representative risk assessment team may include the functions listed below.  Each team member may perform more than one function.  HIPAA-affected agencies should secure the involvement of their HIPAA security officer.  Some functions overlap, for functions where team members review each other’s work.  See Appendix C for more detail on these roles.

Risk assessment manager

System or network administrator

Technical reviewer

System business owner

System technical owner

Executive sponsor

Information security officer

 

The Risk Assessment Report

A Risk Assessment (RA) Report applies to a selected information system.  An information system is a group of computing and network components that share a business function, under common ownership and management.  The Report will include:

• A documented system inventory, listing all system components and establishing the system boundary for the purposes of the Report;
• Documentation of the system’s policies and procedures, and details of its operation;
• List of threat / vulnerability pairs, with severity of impact and likelihood of occurrence;
• List of safeguards for controlling these threats and vulnerabilities;
• List of recommended changes, with approximate levels of effort for each;
• For each recommended change, the resulting reduction in risk;
• The level of residual risk that would remain after the recommended changes are implemented.

The Report will reflect the security policies and objectives of the agency’s information technology management.  It will be presented in a face-to-face meeting with the system business and technical owners, the risk assessment manager, and other project team members.

A Risk Assessment Report is not intended to create or include the following, however it should be used as input for:

• A system security plan, new security architecture, audit report, or system accreditation;
• System security policies, or assignment of staff responsibility for system security;
• Detailed dataflows;
• Exact dollar cost estimates or justifications;
• Assignment or acceptance of legal responsibility for the security of the system;
• In-depth analysis or resolution of specific security incidents or violations;
• Contract review.

Appendix D provides a template for the documentation of the Risk Assessment report.

Tasks

This chart shows the sequence of high-level tasks.  The complete list of tasks and durations will be created, estimated and scheduled by the team.

 

System Documentation Phase

• Document system identification;
• Document system purpose and description;
• Document the system security level.

The team must make a decision about where to draw the boundaries of the system to be assessed.

Risk Determination Phase

• Identify threats;
• Identify vulnerabilities;
• Describe risks;
• Identify existing controls;
• Determine likelihood of occurrence;
• Determine severity of impact;
• Determine risk level.

The team must decide whether to include only controls that are currently implemented, or to include controls that are budgeted and scheduled for implementation.

Safeguard Determination Phase

-          Recommend controls and safeguards;

-          Determine residual (remaining) likelihood of occurrence if controls and safeguards are implemented;

-          Determine residual severity of impact if candidate controls and safeguards are implemented;

-          Determine residual risk levels.

Risk Assessment Process

1.0  System Documentation Phase

The System Documentation Phase provides a description of the system and the data it handles, as computing assets used to fulfill the organization’s business mission. This phase establishes a framework for subsequent risk assessment phases.

The system owner provides the system identification, including the system description, business

function and assets. For new systems, these are defined when the system is first conceived and developed during the SDLC’s design and implementation phases (see Appendix B).

Phase 1:	Set the boundaries for the set of components that constitute the information system.  An information system is a group of computing and supporting components that share a business function, under common ownership and management.
Key Team Members:	System administrator Technical reviewer System technical owner
Output:	High-level documentation and network diagram showing the system and adjacent systems, with a line showing the cut-off for the scope of this risk assessment.

1.1    System Identification

List the system name, other related information, and the responsible organization.  See the System Identification table in Appendix D.

Task 1.1:	Complete and verify system identification and responsible contacts.
Key Team Members:	System administrator Technical reviewer System technical owner Risk assessment manager
Output:	Complete 1.1 System Identification table in Appendix D.

1.2    System Purpose and Description

To identify the assets covered by the RA, provide a brief description of the function and purpose of the system and the organizational business processes it supports, including functions and processing of data.

Technical Description and Environmental Factors

• General description of function and purpose the system
• General functional requirements
• Business processes supported
• Applications supported, services running
• General information flow
• Network diagram with system boundaries
• Description of physical components
• Physical component asset and tag numbers
• Physical location, environmental controls in place
• Environmental factors that give rise to security concerns
• Technical and business users, list of system user accounts
• System ownership:  Shared or dedicated

System Connections and Information Sharing

• Connected components
• LAN and WAN connections and topology, firewall configurations
• Software dependencies
• Interfaces

Task 1.2:	Document the system’s business function, components, environment, connections.
Key Team Members:	System administrator Technical reviewer System technical owner System business owner Information security officer
Output:	Complete 1.2 System Purpose and Description table in Appendix D.

1.3     System Security Level

Describe and document the information handled by the system, and identify the overall system security level. The classification levels and the categories assigned to different types of information should correspond to the agency’s information classification designations. Information security levels and designations should be part of the agency’s information security policy. Appendix A, Information Security Levels, provides examples of security levels and how they can be assigned to different categories of information.

For this step, the team will document the sensitivity of the information handled by the system, then classify the resulting level of security requirements for the system itself.

This element includes a general description of the information, the information’s sensitivity, and system criticality.  It includes requirements for confidentiality, integrity, availability, auditability and accountability as dictated by the agency’s information security policy.

Task 1.3:	Document the criticality and sensitivity of the information the system handles, with brief references to the agency’s information security policy, and the overall system security requirements.
Key Team Members:	Technical reviewer System business owner System technical owner
Output:	Complete 1.3 Information Security Levels and Overall System Security Level table in Appendix D.

2.0  Risk Determination Phase

The goal of the Risk Determination Phase is to calculate the level of risk for each threat / vulnerability pair based on the likelihood of a threat exploiting a vulnerability, and the severity of impact that the exploited vulnerability would have on the system, its data and its business function.  Consider the impact in terms of loss of confidentiality, integrity or availability of the data classified in Task 1.3.

Information will be collected in the form of questionnaires, interviews, documentation review, and automated scanning tools. 

The Risk Determination Phase is comprised of six steps:

1. Identify potential dangers to information and system (threats).
2. Identify the system weakness that could be exploited (vulnerabilities) associated to generate the threat / vulnerability pair.
3. Identify existing controls to reduce the risk of the threat exploiting the vulnerability.
4. Determine the likelihood of occurrence for a threat exploiting a related vulnerability given the existing controls.
5. Determine the severity of impact on the system by an exploited vulnerability.
6. Determine the risk level for a threat/vulnerability pair given the existing controls.

This six-step process for Risk Determination is conducted for each identified threat / vulnerability pair. Use the Risk Determination Table in Appendix D to document the analysis performed in this phase.

 

2.1 Identify Threats and Vulnerabilities

First, identify threats that could exploit system vulnerabilities. Refer to the CMS Threat Identification Resource (www.cms.hhs.gov/it/security/docs/Threat_ID_resource.pdf) for possible environmental, physical, human, natural, and technical threats. Using the output of task 1.2, consider the system’s connections, dependencies with other systems, inherited risks and controls, risks from software faults and staff errors and malicious intent, and such factors as proximity to the Internet, incorrect file permissions, risks from maintenance procedures and personnel changes. 

Next, consider the potential vulnerabilities associated with each threat, to produce a pair.  A vulnerability can be associated with one or more threats.  Collect input from previous risk assessments, audits, system deficiency reports, security advisories, scanning tools, security test results, system development testing, industry and government listings, such as sans.org, securityfocus.com, vendor advisories, and the NIST vulnerability database at icat.nist.gov.

Task 2.1:	Descriptions of threat/vulnerability pairs.
Key Team Members:	System administrator Technical reviewer System technical owner
Output:	Complete the “Item No.”, “Threat Name” and “Vulnerability Name” columns in 2.0 Risk Determination table in Appendix D.

2.2    Describe Risks

Describe how each vulnerability creates a risk to the system in terms of confidentiality, integrity, availability, auditability or accountability elements that may result in a compromise of the system.

Task 2.2:	Describe risks in relation to threat/vulnerability pairs.
Key Team Members:	System administrator Technical reviewer System technical owner
Output:	Complete the “Risk Description” column of the 2.0 Risk Determination table in Appendix D.

2.3 Identify Existing Controls

Identify existing controls that reduce the likelihood or probability of a threat exploiting a system vulnerability, and/or reduce the magnitude of impact of the exploited vulnerability on the system. Existing controls may be management, operational or technical controls depending on the threat / vulnerability and the risk to the system.

Task 2.3:	Description of system controls, cross-referenced with threat / vulnerability pairs.
Key Team Members:	System administrator Technical reviewer System technical owner
Output:	Complete the “Existing Controls” column of 2.0 Risk Determination table in Appendix D.

 

2.4 Determine Likelihood of Occurrence

Estimate the likelihood that a threat will exploit a vulnerability.  Likelihood of occurrence is based on a number of factors that include system architecture, system environment, information system access and existing controls; the presence, motivation, tenacity, strength and nature of the threat; the presence of vulnerabilities; and the effectiveness of existing controls.

Refer to this table to when estimating the likelihood that the threat will be realized and exploit the vulnerability on the system.

Likelihood of Occurrence Levels
Likelihood	Description
Negligible	Unlikely ever to occur
Very Low	Likely to occur two/three times every five years
Low	Likely to occur once every year or less
Medium	Likely to occur once every six months or less
High	Likely to occur once per month or less
Very High	Likely to occur multiple times per month
Extreme	Likely to occur multiple times per day

Task 2.4:	Threat / vulnerability pairs with likelihood of successful exploitation.
Key Team Members:	System administrator Technical reviewer System technical owner
Output:	Categorize threat / vulnerability pairs by likelihood of occurrence, complete the “Likelihood of Occurrence” column of 2.0 Risk Determination table in Appendix D.

2.5    Determine Severity of Impact

Determine the magnitude or severity of impact on the system’s operational capabilities and the information it handles, if the threat is realized and exploits the associated vulnerability. Determine the severity of impact for each threat / vulnerability pair by evaluating the potential loss in each security category (confidentiality, integrity, availability, auditability, accountability) based on the system’s information security level as explained in Appendix A.

Impact Severity Levels
Insignificant	Little or no impact
Minor	Minimal effort to repair, restore or reconfigure
Significant	Small but tangible harm, maybe noticeable by a limited audience, some embarrassment, some effort to repair
Damaging	Damage to reputation, loss of confidence, significant effort to repair
Serious	Considerable system outage, loss of connected customers, business confidence, compromise of large amount information
Critical	Extended outage, permanent loss of resource, triggering business continuity procedures, complete compromise of information

Task 2.5:	Threat / vulnerability pairs with severity of successful exploitation.
Key Team Members:	System administrator Technical reviewer System technical owner System business owner
Output:	Categorize threat / vulnerability pairs by severity or magnitude of impact, and complete the “Impact Severity” column of 2.0 Risk Determination table in Appendix D.

2.6 Determine Risk Levels

Risk level is the likelihood of occurrence multiplied by the severity of impact.  The final value is subject to the system business and technical owners’ discretion.

 

Risk determination

For each threat / vulnerability pair, assess the following:

-          Likelihood of the threat attempting to exercise the vulnerability;

-          Magnitude of impact if the threat / vulnerability exploit is successful;

-          Adequacy of planned or existing security controls for reducing or eliminating risk;
Note:  The project team must decide whether to use only currently implemented controls for this analysis, or to include controls that are budgeted and scheduled for installation, and document that decision in the Report.

-          Resulting risk to the information on the system from the threat and vulnerability.

This table shows the resulting risk level, for each degree of likelihood and each level of severity.

Risk Levels
Likelihood of Occurrence	Impact Severity
	Insignificant	Minor	Significant	Damaging	Serious	Critical
Negligible	Low	Low	Low	Low	Low	Low
Very Low	Low	Low	Low	Low	Moderate	Moderate
Low	Low	Low	Moderate	Moderate	High	High
Medium	Low	Low	Moderate	High	High	High
High	Low	Moderate	High	High	High	High
Very High	Low	Moderate	High	High	High	High
Extreme	Low	Moderate	High	High	High	High

Task 2.6:	Threat / vulnerability pairs with assigned risk levels.
Key Team Members:	System administrator Technical reviewer System technical owner System business owner
Output:	Combine the likelihood of occurrence with magnitude of impact to derive the risk level for each threat / vulnerability pair. Consider the risks to the information on the system, and complete the “Risk Level” column of 2.0 Risk Determination table in Appendix D.

3.0 Safeguard Determination Phase

The safeguard determination phase involves identification of additional controls, safeguards or corrective actions to minimize the threat exposure and vulnerability to exploitation for each threat/ vulnerability pair with a moderate or high risk level.  The residual risk level is the amount of risk that would remain if the recommended control or safeguard were implemented.

Safeguard determination steps:

1.     Identify controls and safeguards to reduce the risk level of each risk-threat pair, if the risk level is moderate or high.

2.     Determine the residual likelihood of occurrence of the threat if the recommended safeguard is implemented.

3.     Determine the residual impact severity of the exploited vulnerability once the recommended safeguard is implemented.

4.     Determine the residual risk level for the system.

Consider safeguards related to testing and maintenance, improved audit capability, and restricting physical access.

3.1 Recommend Controls and Safeguards

Identify controls and safeguards to reduce the risk presented by each threat / vulnerability pair with a moderate or high risk level as identified in the Risk Determination Phase.  When identifying a control or safeguard, consider:

1.     Security area where it belongs, such as management, operational, technical.

2.     Method it employs to reduce the opportunity for the threat to exploit the vulnerability.

3.     Its effectiveness in mitigating the risk to information.

4.     Policy and architectural parameters required for its implementation in the environment.

5.     Information security category (confidentiality, integrity, availability, access control, audit, etc.) to which the safeguard applies.

6.     Whether the cost of the safeguard is commensurate with its reduction in risk.

If more than one safeguard is identified for the same threat / vulnerability pair, list them in this column in separate rows and continue with the analysis steps.  The residual risk level must be evaluated during this phase of the assessment and may be further evaluated in risk management activities outside the scope of this project.

If the recommended safeguard cannot be completely implemented in the environment due to cost, management, operational or technical constraints, document the circumstances and continue with the analysis.

Consider control elements implemented as policies and procedures, training, and improved policy enforcement.

Task 3.1:	Create a list of current, planned or available safeguards and controls suitable for protecting the information
Key Team Members:	System administrator System technical owner Technical reviewer
Output:	List of safeguards and controls, with implementation considerations.  Complete the “Recommended Safeguard” column in 3.0 Safeguard Determination table in Appendix D.

3.2 Determine Residual Likelihood of Occurrence

Follow the directions in section 2.4 of the Risk Determination phase, while assuming the selected safeguard has been implemented. 

Task 3.2:	Categorize threat / vulnerability pairs by likelihood of occurrence, assuming the selected safeguard has been implemented.
Key Team Members:	System administrator Technical reviewer System technical owner
Output:	Complete the “Residual Likelihood of Occurrence” column of 3.0 Safeguard Determination table in Appendix D.

3.3 Determine Residual Severity of Impact

Follow the directions in section 2.5 of the Risk Determination phase while assuming the selected safeguard has been implemented. 

Task 3.3:	Categorize threat / vulnerability pairs by severity or magnitude of impact of a successful exploitation, assuming the selected safeguard has been implemented.
Key Team Members:	System administrator Technical reviewer System technical owner System business owner
Output:	Complete the “Residual Impact Severity” column of 3.0 Safeguard Determination table in Appendix D.

3.4 Determine Residual Risk Levels

Determine the residual risk level for the threat/vulnerability pair and its associated risk once the recommended safeguard is implemented. The residual risk level is determined by examining the likelihood of occurrence of the threat exploiting the vulnerability and the impact severity factors in categories of Confidentiality, Integrity and Availability.

Follow the directions in Section 2.6 of the Risk Determination phase to determine the residual risk level once the recommended safeguard is implemented.

Depending on the nature and circumstances of threats and vulnerabilities, a recommended safeguard may reduce the risk level to “Low.” Make a note of the situation with a description below the table, if needed, if such special conditions exist.

For new systems, the next steps would include creating a sensitivity assessment, system security requirements, risk assessment report, and system security plan in the SDLC.

Task 3.4:	Repeat the derivation the risk level for each threat / vulnerability pair from task 2.6, this time assuming the selected safeguard has been implemented.
Key Team Members:	System administrator Technical reviewer System technical owner System business owner
Output:	Complete the “Residual Risk Level” column of 3.0 Safeguard Determination table in Appendix D.

Appendix A:  Information Security Levels

System business and technical owners must determine the appropriate security levels based on the organization’s confidentiality, integrity and availability requirements for the information, as well as its criticality to the organization’s business mission. These requirements are usually contained in the agency’s statutory, regulatory and policy frameworks. This is the basis for assessing the risks to business operations and assets and in selecting appropriate security controls and techniques.

Below are sample information security levels that establish common criteria for security by information category. The first table defines the information security levels. The second table provides security level examples for the various information categories. In cases where information of varying security levels are combined in one system, the highest security level takes precedence.

It is each agency’s responsibility to determine information security levels for each information category based on its particular business and legal requirements. The examples below are provided for illustration purposes only.

 

Examples of Information Security Levels

Security Level	Description	Explanation
Low	Moderately serious	Noticeable impact on an agency’s missions, functions, or reputation. A breach of this security level would result in a negative outcome; or would result in damage, requiring repairs, to an asset or resource.
Moderate	Very serious	Severe impairment to an agency’s missions, functions, image, and reputation. The impact would place an agency at a significant disadvantage; or would result in major damage, requiring extensive repairs to assets or resources.
High	Catastrophic	Complete loss of mission capability for an extended period; or would result in the loss of major assets or resources and could pose a threat to human life.

 

 

Examples of Information Security Levels by Information Category

Information Category	Explanation and Examples	System Security Level*
Law enforcement and state security information	Information related to investigations for law enforcement purposes; security plans, contingency plans, emergency operations plans, incident reports, reports of investigations, risk or vulnerability assessments certification reports; does not include general plans, policies, or requirements.	High
Life-critical information	Information critical to life-support systems (i.e., information where inaccuracy, loss, or alteration could result in loss of life).	High
Information about persons	Information related to personnel, medical, and similar data (e.g., salary data, social security information, passwords, user identifiers (IDs), EEO, personnel profile (including home address and phone number), medical history, employment history (general and security clearance information), and arrest/criminal investigation history).	Moderate
Financial, budgetary, commercial, proprietary and trade secret information	Information related to financial information and applications, commercial information received in confidence, or trade secrets (i.e., proprietary, contract bidding information, sensitive information about employees or citizens). Also included is information about payroll, automated decision making, procurement, inventory, other financially related systems, and site operating and security expenditures.	Moderate
Public information	Any information that is declared for public consumption by official authorities. This includes information contained in press releases. It also includes information placed on public access world-wide-web servers.	Low

Appendix B: Security in the System Development Life Cycle

(from CMS Information Security RA Methodology)

Although information security must be considered in all phases of the life of a system, the System Development Life Cycle identifies four specific steps that are needed to ensure that information at CMS is properly protected. These include the Information Sensitivity Assessment (Section 10.5 of the Business Case Analysis), System Requirements Document, the RA Report and the System Security Plan.

Step 1 - The Information Sensitivity Assessment (ISA)

Prior to project initiation, the system owner prepares a Business Case Analysis (BCA), which includes the ISA (section 10.5 of the BCA). In this step, the system owner categorizes the data according to sensitivity and identifies high-level security requirements that apply to the system under consideration for development. Information from the ISA is one of the factors considered in determining if the system will go forward into development and what level of information security will be needed. Elements from the ISA provide the initial input to the RA.

Step 2 –System Requirements Document (specifically Security Requirements)

As an initial step of the development process, system requirements are documented for every system. The security requirements serve as a baseline for security within the system. The CMS Minimum Information Security Standards is a tool to assist in defining security requirements. Other requirements may be determined by business or functional requirements.

Step 3 – Risk Assessment Report

During the development process, a risk assessment is conducted and the result RA Report documents the vulnerabilities that have been identified in the system, the risks to the system resulting from the vulnerabilities and the efforts designed to reduce those risks, through the use of safeguards. The RA Report provides input to the System Security Plan and other risk management activities.

Step 4 – System Security Plan

The System Security Plan incorporates all of the elements required for the system owner to determine if the system should be certified as meeting both CMS policy and business requirements. Information from the RA Report is incorporated into the System Security Plan in Section 2 – Management Controls.

Security steps also correspond to phases in the Integrated IT Investment Management Road Map (ROADMAP) for system development. The ROADMAP is CMS’s implementation standard for SDLC and Investment Management and can be found at cms.hhs.gov/it/roadmap. In Figure B-1, the system development life cycle and ROADMAP are shown on the right and left sides with the information security deliverables and tools entered in the center section between them. This format illustrates the relationship of the information security tasks to both processes.

Figure B-1. Security in the System Development Life Cycle and CMS’s Roadmap

 

 

Appendix C:  Assessment Team Members and Functions

Functional Role	Background	Organization	Email	Phone
Risk Assessment Manager	Drives the risk assessment process, coordinates tasks, deliverables and schedule, composes the report with input from all team members.
System or network administrator	Operates and maintains the system from a technical, day-to-day standpoint; usually the “Primary System Contact” in the System Identification table.
Technical Reviewer	Understands the technical components of the system, but was not involved in designing, building or operating the system being assessed.
System business owner	Responsible for the system, or the services it provides, from a business or customer standpoint; understands the system’s purpose but not necessarily the details of its technical implementation.
System technical owner	Has supervisory responsibility for the operation of the system.
Executive sponsor	Executive management-level responsibility for the system.
Information security officer	Responsible for the agency’s security policies and objectives, and its overall risk profile.

Appendix D:  Information Security Risk Assessment Template

1.0 System Documentation

1.1 System Identification
Agency Name
Official System Name
System Acronym
System Business Owner
System Technical Owner
System Security Owner
Additional System Stakeholders
System Location Full Address
Contract Number, Contractor names, phone numbers and emails, if applicable
System type(s) (mainframe, application / database / network / file server, workstation)
Primary System Contact(s), Name and Title (usually the system administrator)
Organization Name
Full Address
Email Address
Phone and pager numbers

1.2 System Purpose and Description
Function and purpose of the system
General functional requirements
Business processes, applications and services supported
System components
Environmental factors
Network diagram with system boundaries (attach)
General information flow
Technical and business users (list)
System ownership (shared or dedicated)

1.3 Information Security Levels and Overall System Security Level
Information Category
Information Security Level
Information Category
Information Security Level
Information Category
Information Security Level
Overall System Security Level

2.0 Risk Determination

2.0 Risk Determination Table
Item No.	Threat Name	Vulnera-bility Name	Risk Descrip-tion	Existing Controls	Likeli-hood of Occur-rence	Impact Severity	Risk Level

3.0 Safeguard Determination

3.0 Safeguard Determination Table
Item No. (from Risk Determination Table)	Recommended Safeguard Description	Residual Likelihood of Occurrence	Residual Impact Severity	Residual Risk Level

Signatures

Submitted by:   _______________________  Date:   _________

                        Risk Assessment Manager

           

Reviewed by:    _______________________  Date:   _________

                        [Title]

Approved by:    _______________________  Date:   _________

                        [Title]

Share on FacebookPlus on Google+

SUBSCRIBE MORE CONTENTS