Information Security Risk Assessment

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.

Page 1
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.

Page 2
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.

Mar 2003
ID Risk Assessment Project
5 6 7 8 9 10 11 12 13 14 15

1 1 System Documentation Phase

2 1.0 Set boundary for selected system
3 1.1 Record system identification information
4 1.2 Document system purpose and desc.
5 1.3 Document the system security level
6 2 System Risk Determination Phase
7 2.1 Identify threats and vulnerabilities
8 2.2 Describe risks
9 2.3 Identify existing controls
10 2.4 Determine likelihood of occurrence
11 2.5 Determine severity of impact
12 2.6 Determine risk levels
13 3 Safeguard Determination Phase
14 3.1 Recommend controls and safeguards
15 3.2 Determine residual likelihood of occurrence
16 3.3 Determine residual severity of impact
17 3.4 Determine residual risk level
18 4 Report presentation, archiving and sign-off

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.

Page 3
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 System administrator
Members: 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 System administrator
Members: Technical reviewer
System technical owner
Risk assessment manager
Output: Complete 1.1 System Identification table in Appendix D.

Page 4
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 System administrator
Members: 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.

Page 5
 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 Technical reviewer
Members: 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.

Page 6
 Task 2.1: Descriptions of threat/vulnerability pairs.
Key Team System administrator
Members: 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 System administrator
Members: 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 System administrator
Members: 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

Page 7
 Task 2.4: Threat / vulnerability pairs with likelihood of successful exploitation.
Key Team System administrator
Members: 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 System administrator
Members: 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.

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

Risk Levels
Likelihood Impact Severity
of
Occurrence 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 System administrator
Members: 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.

Page 9
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 System administrator
Members: 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 System administrator
Members: 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 System administrator
Members: Technical reviewer
System technical owner
System business owner
Output: Complete the “Residual Impact Severity” column of 3.0 Safeguard Determination
table in Appendix D.

Page 10
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 System administrator
Members: Technical reviewer
System technical owner
System business owner
Output: Complete the “Residual Risk Level” column of 3.0 Safeguard Determination table in
Appendix D.

Page 11
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.

Information Security Levels

Security Level Description Explanation
Low Moderately Noticeable impact on an agency’s missions, functions, or
serious 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.

Information Security Levels by Information Category

Information Explanation and Examples System
Category Security
Level*
Law enforcement Information related to investigations for law enforcement High
and state security purposes; security plans, contingency plans, emergency
information operations plans, incident reports, reports of investigations, risk
or vulnerability assessments certification reports; does not
include general plans, policies, or requirements.
Life-critical Information critical to life-support systems (i.e., information High
information where inaccuracy, loss, or alteration could result in loss of life).
Information about Information related to personnel, medical, and similar data (e.g., Moderate
persons 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).

Page 12
Information Explanation and Examples System
Category Security
Level*
Financial, budgetary, Information related to financial information and applications, Moderate
commercial, commercial information received in confidence, or trade secrets
proprietary and trade (i.e., proprietary, contract bidding information, sensitive
secret information 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.
Public information Any information that is declared for public consumption by official Low
authorities. This includes information contained in press
releases. It also includes information placed on public access
world-wide-web servers.

Page 13
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.

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

System Security in the SDLC Security IT Investment

Deliverables Management
(rectangle) & Road Map
Resources (oval)
Pre-Development
1. Express need for system
2. Assess/determine data sensitivity
3. Define initial security requirements Business Case Analysis Acquisitions
10.5 - Information - BCA 10.5 – Information
Sensitivity Sensitivity Assessment
Development
1. Identify detailed system security requirements
during system design. Requirements Definition
2. Develop appropriate security controls with - Define System Requirements
evaluation & test procedures prior procurement - Information Security Risk
actions Assessment
3. Develop solicitation documents to include security Minimum
requirements & evaluation/test procedures Security
4. Update security requirements as technologies are Standards
implemented Design and Engineering
5. Identify security requirements for procurement of - Security Test Plan/Cases
COTS applications components
6. Perform design review to ensure security controls
are considered prior to production System
7. Ensure security features are configured, enables, Requirements
tested, and documented during development Document (includes
8. Update, design, perform and document newly security)
developed security controls
9. Document system security tests and risk Development
assessment - Software Test Plan
10. Ensure compliance with Federal laws, - Program Software Unit and
regulations, policies and standards Integration
11. Certify system and obtain system - Test Case Scenarios
accreditation Threat - Test Data
12. Provide security training Identification
Resource

Post-Development Testing and Implementation

1. Document all security activities Identify - Perform System Acceptance
2. Perform security operations and administration Testing
Vulnerabilities
a. Perform backups - Test or Validation Result
b. Provide security training Report
c. Maintain & review user admin & access - Security Test Results
Risk Assessment
privileges
(Risk Determination
d. Update security software as required
and Safeguard
e. Update security procedures as required
Evaluation)
3. Perform operational assurance
a. Perform & document periodic security audits Implementation
b. Perform & document monitoring of system - System Security Risk
security Assessment
c. Evaluate & document results of security System Security - System Security Plan
monitoring Plan
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 Risk Assessment Operations & Maintenance
configuration change or every year and System Security - Updated Risk Assessment
4. Document disposal of information Plan - Updated System Security
5. Use controls to ensure confidentiality of Plan
information

Page 15
Appendix C: Assessment Team Members and Functions

Functional Role Background Organization Email Phone

Risk Assessment Drives the risk assessment
Manager process, coordinates tasks,
deliverables and schedule,
composes the report with input
from all team members.
System or network Operates and maintains the
administrator 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 Responsible for the system, or
owner 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 Has supervisory responsibility for
owner the operation of the system.
Executive sponsor Executive management-level
responsibility for the system.
Information security Responsible for the agency’s
officer security policies and objectives,
and its overall risk profile.

Page 16
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)

Page 17
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 Vulnera- Risk Existing Likeli- Impact Risk Level
Name bility Descrip- Controls hood of Severity
Name tion Occur-
rence

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

Signatures

Submitted by: Rofiq Fauzi_____________ Date: _________

Risk Assessment Manager

Reviewed by: _______________________ Date: _________

[Title]

Approved by: _______________________ Date: _________

[Title]

Page 19