Version 1.

Security Impact Analysis (SIA) Template

What is a Security Impact Analysis (SIA)?
 The Security Impact Analysis is a process to determine the effect(s) a proposed change can cause to
the security posture of a FISMA system.
 Conducting a SIA is a mandatory process for all changes. Per CMS Acceptable Risk Safeguards
(ARS) 3.1 control CM-4: The organization analyzes changes to the information system to determine
potential security and privacy impacts prior to change implementation.
 The depth and intensity of a SIA (along with associated documentation) varies directly with
the scope of a proposed change. The SIA may require little time, or it may entail a detailed
process, with security testing, scans, etc.
 The key “deliverable” of a SIA is to determine the impact the change can have on a system’s
security posture. Documentation provides a secondary, but useful purpose.
 Results from the SIA must be shared with and acknowledged by the system’s Business Owner and
System Maintainer.

SIA Purpose
 The SIA process articulates how changes to the system may affect the security posture of the system.
Documentation chronicling the SIA provides insight to the development team, ISSO, Business
Owner, and other key stakeholders.
 The SIA and associated documentation may highlight the need for future actions including:
o Communication with the Technical Review Board (TRB);
o Updates to Security Artifacts (SSP, ISRA, CP, PIA, etc);
o Determination if Third Party security testing will be required;
o The potential requirement for a new Authority to Operate (ATO).
 SIA documentation may serve as a “to-do” list for ISSOs to make sure that documentation is updated
appropriately, tests performed for identified controls, etc. It may also help justify further testing and
potentially expensive processes to the Business Owner.
 SIA documentation, if properly tailored, is particularly useful for a DevSecOps environment where
multiple changes may occur within a relatively short time-frame and the ISSO can reuse existing
documentation to quickly make any updates necessary.
 SIA documentation may serve as evidence of system compliance.

Examples of Changes Where an SIA is Appropriate

 Changes to existing architecture, system, network, application, security boundary, or environment..
 Changes made to environments below the production environment (PROD) that will eventually be
implemented in PROD.
 New data types, or new connection to data source, system, service, or association.
 Software or service solutions that are new to the system; especially those that are new to CMS and
have yet to be approved under any CMS ATO or FedRAMP.

SIA 1
 Version 1.0

Note: NIST Special Publication 800-128 “Guide for Security-Focused Configuration Management of
Information Systems” indicates that the change management process (and by extension, security impact
analysis) is not required for changes that are specifically noted as being excluded in each organization’s
Configuration Management Plan (CMP). If there is an anticipated change not so noted in your
organization’s CMP, perform a SIA.

Event-Driven Triggers and Significant Changes

NIST Special Publication 800-37 Rev 2 “Risk Management Framework for Information Systems and
Organizations” defines a significant change as a change that is likely to substantively affect the security
or privacy posture of a system. Significant changes to a system that may trigger an event-driven
authorization action may include, but are not limited to:
 Installation of a new or upgraded operating system, middleware component, or application;
 Modifications to system ports, protocols, or services;
 Installation of a new or upgraded hardware platform
 Modifications to how information, including PII, is processed;
 Modifications to cryptographic modules or services;
 Changes in information types processed, stored, or transmitted by the system; or
 Modifications to security and privacy controls. (e.g. identity and access management).

Significant changes to the environment of operation that may trigger an event-driven authorization
action may include, but are not limited to:
 Moving to a new facility;
 Adding new core missions or business functions;
 Acquiring specific and credible threat information that the organization is being targeted by a
threat source; or
 Establishing new/modified laws, directives, policies, or regulations.

Note: The examples of changes listed above are only significant when they represent a change that is
likely to affect the security and privacy posture of the system.

References
NIST SP 800-37 Rev. 1 under Security Impact Analysis
CNSSI 4009-2015 (NIST SP 800-37 Rev. 1)
NIST SP 800-137 under Security Impact Analysis (NIST SP 800-53)
NIST SP 800-30 Rev. 1 under Security Impact Analysis (NIST SP 800-37)
NIST SP 800-39 under Security Impact Analysis (NIST SP 800-37)
NIST SP 800-53 Rev. 4 under Security Impact Analysis (CNSSI 4009)
NIST SP 800-18 Rev. 1 under Security Impact Analysis (NIST SP 800-37)
NIST SP 800-53A Rev. 4 under Security Impact Analysis (NIST SP 800-37)
NIST SP 800-128 under Security Impact Analysis (CNSSI 4009 - Adapted)

SIA 2
 Version 1.0

SIA Template Instructions

How to use this document. This template provides a suggested methodology to help
ISSOs assess the potential security impact of a change or changes to FISMA systems.
Individual ISSOs may find it necessary to alter the template to meet their organizational
needs. Workflow associated with this template is also dependent on organizational
requirements.
This template consists of four sections. They are:

1. Section 1 – An overview of the proposed change. If this document is maintained for record
keeping/compliance, the completion of this section will make identification easier in the future.

2. Section 2 – Information on who is performing the SIA if a technical representative of the ISSO is
performing the assessment on behalf of the ISSO. If a technical representative of the ISSO has
performed this assessment, they will forward it to the ISSO for discussion and review. It remains
the ISSO’s responsibility to complete all appropriate actions.

3. Section 3 – An extensive list of “Trigger Events”, most of which are a decomposition of the
boxes checked in Section 2. This section is the heart of the assessment. To complete this
section:
1. The assessor examines each event under “Scope of Change” (column 2).
2. If an event is part of the potential change, enter a “Y” under “Impact Y/N” (column 1).
At this point, elaboration of the events noted is included in the section “Summary of
Security Impact/ Technical Overview/ Risks Identified”. This includes detailing the
technical overview of the item and a description of the potential impact and risk. Where
other data associated with the change is available such as scan information, reference
should also be included in this area.

4. Section 4 – The ISSO recommendation to the Business Owner on the overall status of the change
and what actions necessary. This section should function as a high-level summarization of the
necessary activities determined in Section 3 “Mitigation or Necessary Updates” and “Summary
of Security Impact/Technical Overview/Risks Identified”.
a. Note that the “Mitigation or Necessary Updates” area within Section 3 provides
recommended actions. Actions may individually or as a group indicate the requirement
for a new ATO. At this point, the ISSO may choose to consult with their Cyber Risk
Advisor or Privacy Advisor prior to providing the recommendation of activities to the
Business Owner and System Maintainer.

Though every change requires a SIA, organizations may utilize their own internal methods or processes
that can automate or streamline the security analysis rather than using a formal SIA form. These types
of changes may include processes for configuration control such as vendor-provided security patches,
updated antivirus signatures, creation, or deletion of users, replacement of defective peripherals,

SIA 3
 Version 1.0

motherboard or hard drives, etc. Processes associated with similar functions, may have built-in security
components or controls that may not require a formal SIA form. Any of these processes whether
automated or manual, must capture the elements needed to properly analyze the security impacts of the
particular change and the ISSO may at any time require a formal SIA for any change.

Post change. This document, when completed and shared with the Business Owner can be used as a
checklist to make sure that any work such as documentation changes are performed.

SIA 4
 Version 1.0

<FISMA SYSTEM NAME> <

PRODUCT/FEATURE NAME> <DATE OF
RELEASE TO PROD>

Section 1: Change Information

Element
CR Number
CR Submitter (Contact Information)
System/Application/Tool
Description of System Change
(This must be a detailed description that
includes the Drivers for the change)
Description
Click here to enter text.
Click here to enter text.
Click here to enter text.
Click here to enter text.

If applicable, provide the details of the change if the SIA is dependent on a Change Request (CR).

Element Description
CR Number Click here to enter text.
CR Submitter (Contact Information) Click here to enter text.

Section 2: Technical Representative Information

If a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your
contact information.

Element Description
Representative performing the SIA Click here to enter text.
Title of Representative performing the SIA Click here to enter text.
Date Click here to enter text.
Phone Click here to enter text.
Email Click here to enter text.

SIA 5
 Version 1.0

Section 3: Trigger Actions and Events Evaluation

Directions: Please complete the table below by indicating Y/N if a particular security event occurs and entering a description of the summary of security
impacts/technical overview/risks identified. Highlight any rows where a possible significant change is detected. The ARS Controls impacted column is not all-
inclusive. Note: this list is not all-inclusive.

Impact? Category Scope of Change Mitigation or Necessary Updates ARS Controls Summary of Security Impact/ Technical
(Y/N) Impacted Overview/ Risks Identified
Mission/ New Users or ISRA updates, potential PIA AC-2, AC-6
Business New User Roles update, CFACTS system
requirements Added description updates.

Mission/ Change in data PIA update. AC-21, AP-1,

Business collection, storage, Potential SORN updates. AR-2, AR-8,
requirements sharing DM-2, SE-1, TR-
1, UL-1

Mission/ Cessation of mission Potential update to SSP, CFACTS Potential impact

Business or function. system description updates. to multiple
requirements controls
depending on
nature of
mission/function.
Policy/ New revisions of Updates to FISMA artifacts Potential impact
Standards ARS and CMS including SSP. to multiple
policy; or Issue or controls
Update of NIST depending on
documents nature of the
policy/
standards.
Laws, New or Changed Updates to FISMA artifacts Potential impact
Regulations, including SSP. to multiple
Directives controls
depending on
nature of laws,
regulations,
SIA 6
 Version 1.0

Impact? Category Scope of Change Mitigation or Necessary Updates ARS Controls Summary of Security Impact/ Technical
(Y/N) Impacted Overview/ Risks Identified
directives.
System Interconnections and Updates to ISA and MOU must AC-4, CA-3,
boundary New connection to occur. If not standard connection CA-9, PL-2, AC-
FISMA system or service/inheritance from another 3, AC-20, AU-2,
Service accredited FISMA system, SCA AU-12, AU-16,
will be required. CA-7, IA-3, SA-
9, SC-7, SI-4
Updates to FISMA artifacts must
be made, including SSP, XLC/TLC
System Slides, CFACTS Boundary
information, etc
System Architecture, Zone changes CM-2, PL-2, PL-
boundary Topology, Implementation or inheritance of 8, SA-3, CM-6,
Port/Protocol/Service new services CM-8, CM-9,
change Updates to FISMA artifacts must SA-10, PM-5,
be made, including SSP, XLC PM-7
System Slides, CFACTS Boundary
information, etc
Security Identification, New and modified control IA (all)
components Authentication, implementations must be tested.
Authorization SCA required unless inheriting
from existing FISMA system.
New methods for
authentication Updates to all FISMA artifacts
and/or identifiers must be made, including SSP,
added XLC/TLC System Slides, CFACTS
Boundary information, etc
Migrations between
Single Factor and
MFA
Security Security Controls – New and modified control List specific
Components Change in implementations must be tested via controls changed
implementation existing security processes. All
standard or status changes must be documented PL-2 (SSP)
within the SSP and the Controls tab

SIA 7
 Version 1.0

Impact? Category Scope of Change Mitigation or Necessary Updates ARS Controls Summary of Security Impact/ Technical
(Y/N) Impacted Overview/ Risks Identified
within CFACTS. Changes in
controls that cause controls to no
longer be “Satisfied” must be
submitted as a POA&M and
documented within the ISRA.
User Interface Updates to GUI New pages must go through 508 CM-2, CM-3,
including addition of testing, Static and Dynamic code CM-4
new pages, new analysis to determine no additional
inputs threats from XSS or other new SI-10
vulnerabilities.
New or Servers, If the equipment is updated with CM-2, CM-3,
Updated Communication similar vendor and models, then CM-4, CM-6,
Hardware Devices minimal testing may be needed. CM-7
However, if they are new models or
vendors, with different PL-2 (SSP)
configurations and settings, then it
is considered a significant change. HW/SW List
Equipment will need to be
hardened, and at minimum, have AC-19, SI-4
vulnerability and configuration
scans performed on them. CP-2
New or Change in Operating If the software is updated with CM-2, CM-3,
Updated System similar vendor and versions, then CM-4, CM-6,
Operating minimal testing may be needed. CM-7
System However, if they are significantly
different versions (i.e.., not an RA-5
“incremental version update”) or Vulnerability
different vendors, with different Scanning
configurations and settings, then it
is considered a significant change. CA-9(1)
Affected systems will need to be Compliance
hardened and, at minimum, have Checks
vulnerability and configuration
scans performed on them. PL-2 (SSP)

SIA 8
 Version 1.0

Impact? Category Scope of Change Mitigation or Necessary Updates ARS Controls Summary of Security Impact/ Technical
(Y/N) Impacted Overview/ Risks Identified
HW/SW List

CP-2
New or New Security If the software is updated with CM-2, CM-3,
Updated Software or similar vendor and versions, then CM-4, CM-6,
Security Perimeter Security minimal testing may be needed. CM-7
Software Change However, if they are significantly
different versions (i.e.., not an RA-5
“incremental version update”) or Vulnerability
different vendors, with different Scanning
configurations and settings, then it
is considered a significant change. CA-9(1)
Affected systems will need to be Compliance
hardened and, at minimum, have Checks
vulnerability and configuration
scans performed on them. PL-2 (SSP)

HW/SW List

Potential impact
to multiple
controls
depending on
nature of
software
Support New Support If the software is updated with CM-2, CM-3,
Software Software similar vendor and versions, then CM-4, CM-6,
minimal testing may be needed. CM-7
However, if they are significantly
different versions (i.e.., not an RA-5
“incremental version update”) or
different vendors, with different PL-2 (SSP)
configurations and settings, then it
is considered a significant change. HW/SW List

SIA 9
 Version 1.0

Impact? Category Scope of Change Mitigation or Necessary Updates ARS Controls Summary of Security Impact/ Technical
(Y/N) Impacted Overview/ Risks Identified
Affected systems will need to be
hardened and, at minimum, have Potential TRB
vulnerability and configuration review/approval
scans performed on them.
Vendor Software, Servers Software patch updates that cause CM-2, CM-3,
Patches the baseline configuration, or CM-4
security controls implementations,
to change will need a re- PL-2 (SSP)
authorization. All Software
upgrades need to be tested pre- HW/SW List
launch to prevent any issues.
Affected systems will need to be
hardened and, at minimum, have
vulnerability and configuration
scans performed on them.
System Change to Logical Vulnerability Scan is required AC-17, AC-2,
Boundary Access Points AC-3, AC-18,
AC-19, AC-20,

CA-3, CA-7,

CM-8, IA-2, IA-

3, IA-8, MA-4,
PE-17, PL-4,
SC-10, SI-4
Vulnerability Attacks Developed Risk Assessment update, additional RA-2, RA-3,
(New or work as required. New and CM-8, MP-4,
Existing) modified control implementations SC-7, SI-2, CA-
must be tested as part of the 2, CA-7, CM-3,
Configuration (Change) CM-5, CM-8,
Management processes. MA-2, IR-4, RA-
5, SA-10, SA-11,
SI-11
Vulnerability Attacks Succeed Risk Assessment update, additional RA-2, RA-3,
(New or Elsewhere work as required. New and CM-8, MP-4,

SIA 10
 Version 1.0

Impact? Category Scope of Change Mitigation or Necessary Updates ARS Controls Summary of Security Impact/ Technical
(Y/N) Impacted Overview/ Risks Identified
Existing) modified control implementations SC-7, SI-2, CA-
must be tested as part of the 2, CA-7, CM-3,
Configuration (Change) CM-5, CM-8,
Management processes. MA-2, IR-4, RA-
5, SA-10, SA-11,
SI-11
Vulnerability Found (No Attacks Add to Risk Assessment. New and RA-2, RA-3,
(New or Known) modified control implementations CM-8, MP-4,
Existing) must be tested as part of the SC-7, SI-2, CA-
Configuration (Change) 2, CA-7, CM-3,
Management processes. CM-5, CM-8,
MA-2, IR-4, RA-
5, SA-10, SA-11,
SI-11
System New processing A new processing location will PE(family)
boundary location(s) need to go thru an re-authorization
to ensure the system is secure from CM-2, CM-3,
any issues or attacks CM-4, CM-6,
CM-7
System Change or Addition Full authorization of the GSS is PE(family)
boundary of Hosting required. New and modified control
(environment Infrastructure or Site implementations (for applicable CM-2, CM-3,
) applications) must be tested as part CM-4, CM-6,
of the Configuration (Change) CM-7
Management processes.
Application obtains a new/updated
ATO.

SIA 11
 Version 1.0

Section 3: Validation/Security Testing

Please provide validation/security testing process as they relate to the change or any additional testing being done pertaining to this specific change.

Tool/Scan Testing
(Y/N) Testing Performed by Testing /Method Test Result Location Notes
Type Frequency
Compliance
Scans
Vulnerability
Scans
Dynamic
WAPT
Testing
Static WPT
Testing
Optional
Optional

SIA 12
 Version 1.0

Section 4: Overall Recommendation for Business Owners

Using the information collected in Section 3: “Mitigation or Necessary Updates” and “Summary of Security
Impact/Technical Overview/Risks Identified”, please provide a recommendation to the Business Owner on
the status of the change.

ISSO recommendation(s):

Deploy to Production Environment without additional testing

Undergo Targeted Third Party Security Testing
Undergo SCA/ACT
Require Business Owner Risk Acceptance to field to Production
Apply for a new ATO
Other (e.g. update documentation. Specify on following page)

X
ISSO

Business Owner Acknowledgement:

X
Bu sin ess Ow n er

SIA 13
 Version 1.0

Optional Diagrams/Images/Information Highlighting the Changes/Notes

On this page provide diagrams/images of the changes or embed into document to assist with understanding
the scope of impacts. This can include updates versions of the XLC/TLC System Diagrams. This may also
include any results from validation/security testing or a description of other ISSO recommendations.
Recommendations not noted elsewhere can also be included here.

SIA 14