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

IT Investment
Management
Road Map

System Security in the SDLC

Security
Deliverables
(rectangle) &
Resources (oval)

Pre-Development
1. Express need for system
2. Assess/determine data sensitivity
3. Define initial security requirements

Business Case Analysis
10.5 - Information
Sensitivity

Acquisitions
- BCA 10.5 – Information
Sensitivity Assessment

Development
1. Identify detailed system security requirements during system design. 
2. Develop appropriate security controls with evaluation & test procedures prior procurement actions
3. Develop solicitation documents to include security requirements & evaluation/test procedures
4. Update security requirements as technologies are implemented
5. Identify security requirements for procurement of COTS applications components
6. Perform design review to ensure security controls are considered prior to production
7. Ensure security features are configured, enables, tested, and documented during development
8. Update, design, perform and document newly developed security controls
9. Document system security tests and risk assessment
10. Ensure compliance with Federal laws, regulations, policies and standards
11. Certify system and obtain system accreditation
12. Provide security training

Requirements Definition
- Define System Requirements
- Information Security Risk
Assessment

Minimum
Security
Standards

Design and Engineering
- Security Test Plan/Cases

System
Requirements
Document (includes
security)

Development
- Software Test Plan
- Program Software Unit and
Integration
- Test Case Scenarios
- Test Data

Threat
Identification
Resource

Testing and Implementation
- Perform System Acceptance Testing
- Test or Validation Result Report
- Security Test Results

Post-Development
1. Document all security activities
2. Perform security operations and administration
a. Perform backups
b. Provide security training
c. Maintain & review user admin & access privileges
d. Update security software as required
e. Update security procedures as required
3. Perform operational assurance
a. Perform & document periodic security audits
b. Perform & document monitoring of system security
c. Evaluate & document results of security monitoring
d. Perform & document corrective actions
e. Test contingency plans on a regular basis
f. Perform Risk Assessment and update Security Plan, as needed, with each configuration change or every year
4. Document disposal of information
5. Use controls to ensure confidentiality of information

Identify Vulnerabilities

Risk Assessment
(Risk Determination
and Safeguard
Evaluation)

Implementation
- System Security Risk Assessment
- System Security Plan

System Security
Plan

Risk Assessment
and System Security
Plan

Operations & Maintenance
- Updated Risk Assessment
- Updated System Security Plan

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]